Agile coaches often lament that the Transformations they are brought on to support are treated as a Project. I had one coach outright tell me recently, that because I suggested that we needed some dates to focus on that I was keeping the organization mired in Waterfall.
The reality is that an Agile Transformation is a change management project with many moving parts all of which need to work together. If you miss one area it will negatively impact another.
A typical set of Agile Transformation workstreams might include some of the following:
· Establishing your Guiding Coalition
· Establishing your Enablement team
· Forming your Communication team
· Developing your Product Capability Maps
· Identify new roles and responsibilities
· Develop a Training plan
· Identify tools needed to support Agile Delivery
· Changes to your funding model (moving from Project to Team-based funding)
· Creating Product Teams
Each one of these workstreams is significant in terms of breadth of work and importance to the success of your transformation plans.
For example,
· If you don’t define Product Capabilities then your ability to create Product teams that support those capabilities is at risk.
· If you don’t have clearly defined Product teams then you are at risk of not being able to move to a Product team-based funding approach.
· If you don’t have Product teams defined, then your roles and responsibilities defined for dedicated teams will be at risk.
· You get the picture. Dependencies and risk abound in a transformation.
The frameworks that we leverage for moving to Agile have a whole host of assumptions, the most basic of which is that all of the work above has been completed and you can adopt the framework in an ‘as-is’ state.
The reality for a majority of organizations is that they don’t put in place much of any of the foundations that will provide the real support for whatever framework you decide to use.
If you are approaching a Transformation from the perspective that it’s the framework that will make you Agile you are already at a failure point in your project.
If you are considering starting a transformation understand that you need to build a project around all of the areas of the organization that must change, hint that isn’t just Technology.
You must create a set of milestones that provide the tipping points to change and then organize around the inflection points where your new normal will take hold.