Thursday, December 15, 2005

Agile and Organizational Change Management

Agile System Delivery in itself is not the main problem when dealing with clients. They want the benefits: regular delivery every 30 days, high quality, ability to change their minds, etc. They understand it, they understand to an extent why it might work but there is always "resistance" to the adoption of Agile practices. This is because you are trying to get the people to change the way they behave and Agile by itself does not address this process.

The field of Organizational Change Management (OCM) addresses the issues arising when trying to change the behaviours in an organization, but on the whole whenever I talk to Agile coaches or consultants they seem to ignore the fundamentals of OCM and are often ignorant of them! Next time you meet an Agile consultant ask them who John P. Kotter is?

Agile consultants, or even those who wish to have Agile adopted in their teams, need to become more aware of OCM techniques and tools. Of course there is the issue of what is the useful stuff in OCM? There is such a huge volume of stuff out there and on the whole it is fluffy, touchy, feely and frankly useless.

There are one or two classic pieces on why Organizational Change fails, such as John P. Kotter's "Leading Change: Why Transformation Efforts Fail" in the March-April 1995 Harvard Business Review (a summary here). These are well worth reading as they contain real tools you can use to start thinking and structuring an approach to the changes required in your context for Agile to be adopted and used successfully.

Let me give an example:

Recently, the Harvard Business Review published the Boston Consulting Group's change assessment model called the DICE framework. The DICE framework has been around since the late 90s and is interesting because it is an easy metric that can assist you in understanding the likelihood of success in a change effort. It is based on "hard factors" as the authors describe them rather than the fluffier stuff you normally see in change models. More importantly the metric is derived from a statistically significant study of 225 change programmes and has been shown to be useful in 1000 or more since.

So why am I waffling on about the DICE model? I think it is useful for looking at the adoption of Agile and the change process associated with it - particularly because one of the hard-factors used in the metric is the "Duration" or rate of review of progress. Since a major behaviour in all Agile approaches is Small Iterations and regular reviews associated with them, you may start to see my point?

The DICE model consists of a score generated from a metric in 5 variables:
  • Duration - the amount of time between reviews (or duration of change program)
  • Integrity - the ability of the team to deliver what is required
  • Commitment - two variables here, C1=commitment to change of top management, and C2=commitment to change of employees effected by change
  • Effort = the perceived effort over and above normal workload that the change initiative demands

These variables are scored in a 1 to 4 point range and then plugged into a formula:

DICE = D + 2I + 2C1 + C2 + E

The score is then correlated on a distribution graph which shows you if the change effort is in a Win, Worry or Woe state (management consultants do like their alliteration!)

So what does this tell us about Agile Adoption? Given that the best score of 1pt in Duration is given for review points that are at least 2 months apart, you may see that Agile is already on a winning roll! In fact, I would suggest 30-day Scrum Sprints and XP iterations might be allowed a cheeky 0.5 pt score, but its not my model and that may be cheating.

So what of the other factors?

I asked about 20 people I know who are Agile people about what they thought teams perceived the effort of beginning to adopt Agile was. After getting through the "it depends" qualifications, I found that there was a average coming out of about 35-45% extra perceived effort! (generally all 20 said the reality was that Agile was actually less effort!). In the DICE model this is a big factor and would fall into the poor 4pt range.

The Integrity and Commitment factors are more complex, as they are so context dependent. To score low figures in the Integrity category you need good team leads and at least 50% of the team's time being spent on the project, so to me Agile projects would never score the poor 4 but would always exist between 1 and 3 pts. With commitment, neutrality will score about 2, 3 if people are being divisive.

So what does this mean? The DICE model with these figures means that Adopting Agile processes are hovering in the Win-Worry zone, but not the Woe zone. This implies if you can get a team to start adopting Agile you have a an above average chance of it succeeding compared to other approaches to improving software delivery.

But you're not out of the woods. This DICE model points at working on several factors to improve the success of Agile adoption:
  • Senior Management Commitment - the more clear, consistent and definite the senior management can be about why adopting Agile is important the better
  • Team commitment - ensure the team understands why it is worthwhile them changing their behaviour. Help them construct a "what's in it for me?" answer
  • Integrity - there is no substitute for a strong team lead who gets why the change is needed. Make sure there is a leader. And make sure the team members are committing more than 50% of there time to behaving in an Agile manner on the project
  • Effort - do not under-estimate the impact of the "perceived effort". A slow adoption approach may pay off better than an all-or-nothing. Break the perceived 40% overhead into 10% chunks - for example, adopt the Scrum practices and slowly feed in the XP practices as they are palatable to the team (but keep the vision of doing them all finally). According to the model and my numbers doing this alone would move you into the Win zone by itself


At Thursday, December 15, 2005 1:46:00 pm, Anonymous nat said...

"Illiteration"? I think you must be alliterate!

At Thursday, December 15, 2005 2:13:00 pm, Blogger John S Nolan said...

Good point. You will notice I've fixed it.

Never trust a ducking spelt chicken

At Sunday, December 18, 2005 4:43:00 pm, Blogger James McGovern said...

The one impediment pattern that is oft-repeated in Agile territory is only seeing consultants blog on SCRUM and Agility. Maybe they would serve the community better if they encouraged their end customer to talk publicly...

At Sunday, December 18, 2005 6:08:00 pm, Blogger John S Nolan said...

I agree - but I have found customers tend to be shy about this stuff. Usually because they are not comfortable exposing themselves and their companies.

However, you make a very good point. I've never asked a customer to blog qbout their experience. Its worth asking though. Trying to figure out a low-fear approach is probably key to this.


Post a Comment

<< Home