Agile transformation: where does it hurt? I’ve seen a lot of people jump into Agile just because it’s the latest and coolest thing to do and there’s a lot of momentum behind it. It’s like the “Program du jour” for some companies – I can remember a similar phenomenon when Six Sigma was initially coming into vogue in the early 2000’s. At that time I worked with a number of companies on process improvement projects and I interviewed a number of companies for the first book I published, “From Quality to Business Excellence:
- I saw many companies that got wrapped up in the rituals and hoopla of Six Sigma (green belts, black belts, etc.) and, in many cases, their implementation was superficial and didn’t last.
- On the other hand, there were a small number of companies that took the time to understand Six Sigma at a deeper level, blend it together with other process improvement methodologies, and really integrate it into the way they did business. In many cases, it was such an integral part of their business that it was difficult to recognize it as Six Sigma. Naturally, those were the companies I thought were really excellent.
I met with a company recently who is considering adopting a more agile approach to help them determine if it made sense for them and a question I like to ask in that kind of situation is “Where does it hurt?” In other words, what are the aspects of your current process that are causing some amount of “pain” to the organization that you would like to improve on?
Many people skip that step of defining what problem they want to solve and just jump into Agile and I think it’s important to more clearly define what you want to get out of it. There are at least a couple of reasons why that is important:
- Agile is not a panacea for every problem, and
- Many businesses make the mistake of force-fitting their business to some methodology (Agile or whatever)…the right solution, in my opinion, is to fit the methodology (or combination of methodologies) to the business
An Agile transformation may also not get much momentum in a company if the problem it addresses and the goals to be accomplished aren’t defined. An Agile transformation typically involves some change management and I learned a long time ago that there are three very important elements for any significant change management effort to be successful:
- Burning Platform – There needs to be a “burning platform”…there needs to be a sufficient level of pain with the current situation to motivate people to make a change particularly a difficult change that has some risks associated with it. Specifically, with regard to an Agile transformation, if you don’t clearly identify what is wrong with the current state, the transformation may not gain too much momentum.
- Vision for the Future – There needs to be a vision for the future – what does the end state look like after the change? With regard to an Agile transformation, how will the overall enterprise-level model change as a result of implementing Agile? Will it be a pure Agile approach from top-to-bottom or is some other kind of framework more appropriate?
- Progress in That Direction – In any significant change, there are always naysayers who will stand on the sidelines and wait for it to fail, but it becomes increasingly difficult to do that if you demonstrate progress and benefits to the organization. With regard to an Agile transformation, a lot of people advocate “just start” without a lot of upfront planning – I’m not an advocate of that extreme, but there certainly is value in starting to make demonstrable progress as quickly as possible.
I think Agile is entering a new stage of maturity where it is no longer perceived as a fad, a lot of the hype religious zealotry about Agile is fading away, and a more pragmatic approach is emerging focused on doing what’s right for the organization. A good article I recently read called that “Post-Agilisim”: