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.
I was asked last year to do agile transformation in my organization. Before you continue reading, I would like you to read the following:
The 11 Laws (from the Fifth Discipline)
- Today’s problems come from yesterday’s “solutions.”
- The harder you push, the harder the system pushes back.
- Behavior will grow worse before it grows better.
- The easy way out usually leads back in.
- The cure can be worse than the disease.
- Faster is slower.
- Cause and effect are not closely related in time and space.
- Small changes can produce big results…but the areas of highest leverage are often the least obvious.
- You can have your cake and eat it too —but not all at once.
- Dividing an elephant in half does not produce two small elephants.
- There is no blame.
When we talk about agile transformation these days, that often comes as the top down initiative. In very beginning of agile, back in early years (2001-3), agile was either started by teams in small start up companies or by folks that are early adopters and innovators by their nature. Therefore, challenges that you face these days are different:
- Since agile has become de-facto mainstream methodology, agile transformation is normally lead by people that are not agile by their nature (but are assigned to execute it)
- People that should practice agile are not necessarily convinced that agile is a good idea
- Stakeholders expect agile to fix all their problems (and that often has little to do with the development process).
To complicate story further, you should also remember that you will also be facing other problems that are related to the change management process. These forces are always there:
People who are currently in management positions will tend to resist the change as they can only potentially loose in that process and people who are going to be on your side are the ones who can potentially benefit from the change – so they don’t hold strong position in the organization. And if that was not enough, there is one problem more, which comes with agile. Agile is very transparent methodology, and it doesn’t bring excellence per se, but is very effective in pointing out to the incompetence in development. So even if you like to think that developers – people who should benefit from the change will be on your side, this is not necessarily true. This will also depend on their engineering skills. Therefore, you do need the strong support from stakeholders, otherwise you will never make it. You constantly need to work bottom up and provide training to dev. and PO organization, work on their skills and check the training needs, work with middle management and train them on agile and soft skills and finally provide honest and effective reporting to the stakeholders. Since reporting alone is another issue for stakeholders (“responding to change over following a plan”), you will have a lot of fun there too, guaranteed.
So, here it how normally goes with agile transformation:
The 7 Phases of a Change Management Project and how it relates to agile transformation:
- Wild enthusiasm (everybody goes to scrum course, read few books about agile, looks that simple and obvious)
- Disillusionment (arguments and misunderstandings all over the place, people go loose and you start seeing real characters… it is about people before process – isn’t it?)
- Confusion (backlog is filled and flat, and folks just don’t know what to do first. Some people resist writing docs, other want them, PO is freaking, TPM hardly can keep things “under control”)
- Panic (stakeholders start hearing only problems, sales guys are coming back and asking for delivery date, and all that they can hear is epics, iterations, story points…)
- Search for the guilty (by now, agile coach is already either out, or like in my case, they still have trust that I know what I am doing)
- Punishment of the innocent (not there yet…)
- Promotion of non-participant (go back to waterfall, V model, or whatever existed before).
In my next blog post, I will be talking about how I tried to address all these challenges….