As mentioned in the previous post, most of the agile transformations these days are “top-down”. According to Standish Group “Chaos Reports” we still have more project failures than successful projects. One of (many reasons) for this you can find in my previous blog post (how we got screwed in the first place), but there are many reasons for the failures, and to be frank plenty of books written about that.. As Tolstoy wrote once “Happy families are all alike; every unhappy family is unhappy in its own way.”
So, here we have unhappy stakeholders, and the first thing they have in mind by going agile is to get all their problems fixed. As your task is to get it done, be careful at the beginning, since before you know it, you can be dragged into endless meetings, mea culpa sessions and get nice list of issues that people expect you to clean up for them. That is reason why people prefer to have consultant for that job, first they are well paid to deal with all that mess, secondly they are seen as “deux ex machina”, someone that can with no fear say and execute on his plans (what most of the people inside company would do anyway but afraid to openly say), and finally if the guy is really good and have support from the high management – he can eventually make it. So, don’t get me wrong, good consultants with charisma can make it happen.
In order to succeed in any transformation, it is essential to have strong support from stakeholders. Therefore, after educating them on what agile actually is (you can find plenty of good books around), you should first split the transformation in 5 different segments:
- Management practices – Improve communication, efficiency and transparency (visibility, inspection and adaptation)
- Engineering practices – Improve quality of our products (early testing, continuous integration etc.)
- Tools – Implement the right tools that enable us to be effective in both engineering and management practices
- Process – “formalize” agile process across the organization.
- Project specific issues – (parking lot for things that need to be addressed per each project)
The usual transformation trap is that people start talking and mixing all things at once. Operational folks are very often process freaks and when they talk about process they somehow talk tools and when we start talking tools we start talking IBM/HP …. Stop it, stop it, this is endless !!!!
You need to go back and split the problem, and remind all folks that on each segment there will be separate meeting and that for different issues, you might need to consult different people.