In a previous blog post I discussed the fallacy of believing that organizations can execute a significant team restructuring at the start of their agile adoption. In this blog post I will broaden the discussion to include the fallacy that an organization transitioning to agile can somehow develop a detailed, correct, and unchanging plan for its transition at the very start of its journey.
My Dilemma
I am often the recipient of RFPs (Request for Proposals) from companies that are looking to “adopt/transition/transform” to agile. Almost always these RFPs ask for a detailed plan and budget of all of the work that would be required for a company to successfully “become agile.” When I get such RFPs I usually get on the phone with people at the issuing company and explain that I can’t provide exactly what they are requesting. The rest of this blog explains why.
They Want a Traditional Transition Plan
Agile transition RFPs almost always assume that the transition will follow a traditional pattern, as shown in this picture.
In this pattern, someone comes on-site for a couple of days to perform an “as-is” analysis (Current Assessment) of how the company develops software, and also defines the target (“to be”) of where the company should end up (Target Definition) when the agile transition effort is complete.
The pattern next calls for that person to perform a gap analysis between the as-is and to-be models and then develop a detailed plan (Transition Planning) along with all costs for how the company will move from its current as-is situation to its desired to-be state. Finally, the pattern assumes the person will be involved in some or all of the Change Execution, usually by providing agile training and coaching at various levels within the company.
Does this sound familiar?
Agile is a Journey
There are many problems with this approach. First, it assumes that agile is a destination that somehow one day you can reach and declare: “We are agile!” The reality is that agile is not a destination; it is a journey.
Companies that want to start their agile journey should endeavor to be a little bit more agile each day, without the expectation that they will somehow arrive at a final destination where they can no longer improve.
You Know the Least about the Journey at the Start
Most RFPs also assume that someone could develop a complete transition plan on the first day of the transition, the day when everyone involved has the worst possible knowledge and insight in to the journey. This is the equivalent of asking a team to produce a complete, correct, and unchanging requirements document along with a complete project plan on the first day of a new development project before they have had the opportunity to do any work and get any feedback. We laugh at how ridiculous this would be, and yet companies ask for this approach in their RFPs!
An Agile Journey is Iterative and Incremental
I am in no way implying that anyone should start a transition to agile without performing upfront work! In fact, before any company begins the journey, they should do some amount of upfront planning. It would be fiscally irresponsible and dangerous to start a meaningful agile transition having no details (not doing any upfront planning).
However, as I wrote earlier, trying to have complete details (i.e., a complete, accurate, and unchanging transition plan) on the first day is a fallacy. Like everything else in agile we do some upfront work with a healthy dose of just-in-time work.
Basically, we chose a reasonable place on the continuum of details to get the transition started. Then, we inspect and adapt. An agile journey is best experienced in an iterative and incremental fashion.
An Example
Let me end with an example. I was recently training and coaching a well-known company at the start of its agile journey. The engagement began with an RFP that was well crafted and very much in-line with the traditional transition approach shown earlier.
After several engaging discussions, we agreed that it would not be practical to define an end state where the 1,100-person organization should be after it “completed” its agile transformation. To be sure, we were able to articulate clearly the current issues that motivated a desire to transition to agile and a target focus for the transition (initially only the IT department). We also determined that the rest of the organization could be a future focus (there wasn’t 100% certainty within the company on that topic).
To get started, we defined an initial training and coaching plan for the 600 IT folks (product people, technical people, and managers). It was a completely sensible plan, similar to initial plans I had used successfully with other companies, but customized to the current company.
As we started to execute on the initial training and coaching plan we began to uncover issues that no one had predicted. This resulted in us making changes to the training plan after the third class (the original plan had called for up to 15 classes).
Also, very shortly into the journey, it became clear that it would be sensible for non-IT personnel to get their own form of specialized training during this phase of the transition. This training was not something that was originally contemplated to happen in the immediate or even the middle terms. However as the journey unfolded, it became clear that expanding the training beyond IT was the proper thing to do sooner. So, as you can imagine, we inspected and adapted our plans to accommodate these now higher-priority issues. This same scenario (unpredictable things that needed to be accounted for sooner) unfolded over the entire initial transition phase.
So, if you looked at what we actually did during the first five months, versus what we planned do to, you would definitely see some similarities. However, you would also see some very notable and important differences that no one had predicted up front during the RFP stage.
Conclusion
To reinforce the core message of this posting, if I had worked diligently to develop a long-term, detailed transition plan in response to this company’s RFP, then the requesting company and I would have invested substantial effort at the very start of the journey to create a detailed plan that would have been wrong.
Not only would this approach have generated considerable waste, it likely would have made everyone involved in the transition feel like they were failing because they were not adhering a plan that was put together when we all had the least possible knowledge of the journey ahead. In the case study example I described, we set the expectations up front that we would need to adjust often depending on how the journey unfolded. So when those changes started to happen, nobody was surprised!