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.