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 desperately 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 disappointed.
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 evangelist 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 across.
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 start up, and collectively be open to pivoting a time or two before settling into our one right approach.
Related Whitepaper:

The Retrospective Handbook

A FREE guide for agile teams.

Are you running retrospectives regularly? Perhaps you run retrospectives once a week, or fortnightly. Do you feel like you could be getting more out of your retrospectives and fuelling continuous improvement in your teams? You may already find retrospectives valuable, but suspect there are ways of making them better.

Get it Now!  

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

  1. I couldn’t agree more, I like the idea of a Buddhist approach, which focuses on the underlying philosophy and does not seek to dictate or judge the way the philosophy is expressed. There is no wrong way to live and work mindfully.

Leave a Reply


three − 1 =



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use | Privacy Policy
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.

Sign up for our Newsletter

20,709 insiders are already enjoying weekly updates and complimentary whitepapers! Join them now to gain exclusive access to the latest news in the Java world, as well as insights about Android, Scala, Groovy and other related technologies.

As an extra bonus, by joining you will get our brand new e-books, published by Java Code Geeks and their JCG partners for your reading pleasure! Enter your info and stay on top of things,

  • Fresh trends
  • Cases and examples
  • Research and insights
  • Two complimentary e-books