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….