Saturday, July 21, 2012

What Scrum, Kanban, RUP, and ITIL All Have In Common (which causes them to fail)

Putting aside the considerable differences in these methods, RUP, CMMI, Scrum, etc are foremost all products, built using a traditional product development approach. 

This means they have users. Coaches, Managers, Developers, and other knowledge workers who  desparately want to achieve better outcomes delivering business technology solutions. 

These folks read the case studies that accompany these methods and dream of emulating the stories of fantastic accomplishment that come with them.

For the most part these earlyvangelists end up dissapointed.

The real issue with these methods is the product development approach used to build them.
Most of these methods were born out of the personal pain of a particular set knowledge workers. These folks then went on to build a solution to that pain.  This is a good thing, building a solution to your own problem guarantees that you will have at least one customer, and makes it likely that you are addressing a need that someone else has.

For the most part that's where the good news ends. Most delivery methods seem to be developed using traditional product development techniques, and at worst are defended like religions against any forces that might tamper with the "purity" of the product.

It seems to me that methods like RUP suffer from the former, the method is continually extended to support every kind of user and end we up with an incomprehensible mess.

Scrum seems like an example of the former, deliberately avoiding the needs of entire classes of users in an attempt to stay as true to its roots as possible. Users are left to discover the parts that actually matter, often through very expensive trial and error.

Even Kanban, my favorite improvement tool by far, suffers from owner bias, I have yet to personally witness a text book like case study of self directed evolutionary change outside of my own personal team.

Comments that people are not using these methods properly miss the point entirely.

If a product is used incorrectly it is because the product suffers from poor useability. Owners of the method have not put the right amount of effort to ensure that these methods are not only useful (they are) but that they are easily useable (they aren't).

Method owners and evangilist have their work cut out for them. The problem space is complex, the solutions complicated, and the emotional investment is often high. By their nature, improvement methods need to be both open and prescriptive, kind of like the best software language you ever came accross.

Customer Development, a technique invented by Steve Blank provides some insight on how to tread forward. As method designers we need to probe our users a little bit better than we have in the past.
  1. What have users done outside our community done solve technology delivery pain, and how can we integrate the work of these earlyvangelists into our own vision of performance improvement?
  2. Does our method actually address the problem, and how can we measure the applicability of our solution?
  3. Most importantly, what major pain is still not being addressed by the current collection of improvement methods out there, making them vulnerable to next disruptive innovation?
Despite all the work to date, the business of trying to get technology knowledge workers to raise their game is still way more of an art than a science. All of us change agents are operating in a highly uncertain market, time to start thinking like a startup, and collectively be open to pivoting a time or two before settling into our one right approach.


  1. I mostly agree with your post and thank you for sharing.

    Here is my take on it: Software development is hard to master. Most won't master it.
    The usability of these processes is something that I accept for the "at large" community.
    For me, I prefer adaptive models that are frameworks for change, be it top-down, team driven, or both.
    Some will not be able to use these methods because software development is hard!

    We need good leaders and participants. They are out there, but not enough of them.
    The 3 questions you pose I think should be asked in any of the frameworks you listed.
    When I ask myself why they are not, I am left again with some people being unable to think in that manner (they can be coached... maybe). When I think of a framework that is usable for people that haven't made a mental shift, it's scary to me. Maybe I need to open my mind to the idea, but I see that today as a responsibility of coaching and mentoring. I could imagine a more targeted guidance in a safe maturity model for these frameworks as valuable.

    Thanks for the post. It's a good challenge.

    1. Tim,

      you make some excellent points.

      I think the real challenge is to get better at helping folks make the mental shift necessary for better, more transparant performance, amd I think we have made some great progress over the lt decade. I think we could accelerate.

  2. Hi,
    Thanks for this post.Keep up the scepticism!

  3. Using customer development strategy to examine process control and best practices?


    Nice article. If you look at the problem, validate it against expected results, and it comes up wanting why would anyone NOT want to change it?

    My guess is the investment in time and social capital that is expended in becoming and expert is lost, real or not, when you shift away from your tribe.

    Using lean start up as a discovery framework lead me to use Kanban because it better matched the MVP process, which by definition has irreducible value so why worry about time boxing (within reason) and I could argue that if it's too large it's probably not and MVP

    Scrum seems to be time constraint oriented where "value" is artificially broken up to meet the time criteria and keep producing something even if that something is too much or too little.

    There are practices in Scrum I appreciate though so I take what I need from each and keep testing.

    This makes me "Scrumbut" said in the tone of "Scrum-ass" ... deep sigh ...

  4. Excellent post. Thanks for sharing