Agile Transformation and the Chasm

Ignore this article at your own peril!  Failing to understand the depth of the challenge created by the chasm is a common cause of failed Agile Transformations!  Over and over I have seen organizations enter this stage of their Agile transformation and become discouraged with the (admittedly) poor business results when struggling with this stage.  It’s possible and reasonable to get past this stage, but it takes systematic approaches and persistence!  Many managers and executives aren’t willing to stick it out because of the apparent risk.

In his book “Crossing the Chasm“, Geoffrey Moore describes the difficulty of creating a popular new product due to a conceptual “chasm” between the first people who adopt a new product and those who come later.  He describes five types of people in relation to how they adopt new products:

• Innovators – always actively seeking out and trying cutting edge new products.
• Early Adopters – excited to try new things, but after the worst “bugs” have been removed.
• Then there is the Chasm – many products fail here.
• Early Majority – willing to try new things but need strong testimonials or real-world proof.
• Late Majority – require time-tested proof before they will adopt a product.
• Laggards – resistant to change and hesitant to adopt anything without strong personal incentives.

This product adoption behaviour also applies to new ideas in general, and of course, to Agile Transformation in particular.

Implications of the “Chasm” Model

An organization attempting to do an Agile Transformation, for example using our Real Agility Program or another system such as the Scaled Agile Framework (SAFe) should understand how to use this model to ensure long-term success.

This diagram illustrates the concepts:

First, the organization should start the transformation by finding the innovators and early adopters.  These people can then be recruited to run the initial pilot projects.  They will be enthusiastic and will typically adapt themselves to the new behaviors and thinking patterns required by Agility.  If they are properly supported by managers, they will also be successful – at least within the bounds of a limited pilot environment.  Success here will mean that the pilot projects deliver value, use feedback effectively, and the participants (team members and stakeholders) will be happy with the results.

In this stage, it is best to avoid putting people on the teams who are from the early majority, late majority or laggards groups.  These people will tend to drag on the results of the pilot projects.  This is a common mistake in running a pilot program and leads to discouraging results.  One way to help filter between these two groups is simply to ask for volunteers for the pilot projects.  Innovators and early adopters will be much more likely to volunteer for a new initiative.

After the pilot projects have shown some good results, the next step is to go the general roll-out.  In this step, you are now working with the early and late majority.  These people need much more substantial support for a change of this nature.  They will require intensive training, and hand-holding in the form of coaching and mentoring.  This hand-holding can come partially from your innovators and early adopters.  Some of the participants in the pilot projects will have the desire to share their success.  From these, you need to carefully select and prepare a few who will act as internal coaches.  If you are a small organization or if you wish to do your transformation quickly, you will likely need to hire coaches from outside your organization as well.

The early and late majority require evidence of benefits and reassurance that risks are minimal or can be mitigated.  This evidence partially comes from your pilot projects.  However, this may not be sufficient.  There are two other important sources of evidence for this group: the leadership team and external experts.

The leadership team must be committed to the change to agility and can demonstrate this commitment by doing their own management work as an Agile team.  The exact details of the Agile process do not need to be identical to that of the staff teams, but it should be recognizably similar.  As well, this “Agile Transformation Team” must make itself very visible during the general roll-out.  This can be done with communication and by taking up visible residence in a central conference room or bullpen.  As well, this Agile Transformation Team must work diligently to remove obstacles that are raised by staff teams during the general roll-out.

The second source of evidence comes from external sources.  Published case studies are one valuable source.  However, there is a huge value in a visible management investment in external support from recognized experts.  This can be in the form of training, coaching, consulting as well as informal “lunch-and-learn” meetings, town hall meetings and the like.  When engaging experts, it is imperative that the Agile Transformation Team act on their advice otherwise the early and late majority will take that as a sign of hypocrisy.

The final stage of a roll-out is to deal with the laggards.  For the most part this is a do-or-die proposition for these people.  Either get with the program and engage like a committed employee or leave the organization.  If your organization is large enough, you will likely have observed some of these people leaving the organization in the general roll-out.

For some organizations, this transformation process can take many years.  An organization with thousands of people should expect to be working on the pilot projects for at least a year, the general roll-out for at least three years.  Often it will be longer.  Good luck on your Agile transformation effort!

[This article was originally published on Agile Advice on 24-Nov-2011]