Culture Change with Pigs, not Chickens

Last month David Anderson wrote a two-part article on why agile transformation initiatives fail. David’s suggestion to concentrate on cultural change reminded me of one of my favorite bits on process initiatives. From Peter Coad’s book, Java Modeling in Color with UML, it starts with ‘We think most process initiatives are silly’. I particularly like the paragraph that says, “No amount of process specification will make up for bad people. Far better:  Staff your project with good people, do whatever it takes to keep them happy, and use simple, well-bounded processes to guide them. ”  In fact, I would go so far as to say process over-specification gives non-performing people something to hide behind. Agile processes strip away that cover exposing weaknesses in the ways individuals and teams work and communicate.

However, exposing dysfunctional teams and working practices is not the same as fixing them. In part one of his article, David talks about the problems with management-imposed change that does not win the hearts and minds of those on which it is being imposed. I certainly recognize these problems and not just with agile transformations, but with any major process improvement initiative including standardizing on a new toolset.

In fact, there are some facets of such programs that I have come to recognize as patterns:

1. The ‘Sheep-dip training’ pattern:

   Most process improvement teams realize that staff will need training in the new process or tool set. However, with one eye on the budget, they opt for a training program that introduces everyone to basic the mechanics of the process or toolset.

   Unfortunately, this is a little like giving soldiers basic training in a new type of warfare or equipment and sending them into battle without trained NCO’s and field officers.

2. The ‘If we build it, they will come’ pattern:

   Some people seem to believe that if the process improvement team create the perfect  description of the new way of working on a intranet site (or worse, in a single large MS Word or PDF document), everyone will read it and follow it. I have even known one client that, on deciding to adopt agile, disappeared for a couple of months to write a large document to describe how to do agile in his department!!!

   This is like HQ addressing the lack of trained NCO’s and field officers by sending more detailed written orders to soldiers already under fire.

3. The ‘Centralized coaching team’ pattern:
   
   A team of experts, possibly external consultants, is set up to visit, assess and advise teams on issues they are encountering with the new way of working.
   
   To continue the military metaphor, at regular points in the battle, officers from HQ appear to advise briefly on the new tactics and then hurry back to the safety of the HQ.
   
4. The ‘The disappearing external consultant/coach’pattern

   End users of a new tool or process need expert guidance to get over the initial learning curve and to apply it within their particular project context. The easy solution is to parachute external expert consultants and coaches into these teams.  Unfortunately, again the budget often limits this to part-time or a few weeks only. 

Having your process documented on a website is not wrong. Giving users basic training is not wrong. Providing access to experts and coaching is not wrong … but it is not enough. The fundamental problem with the patterns above that turns them into anti-patterns, is one of pigs and chickens. 

Note: In the UK, we talk about ‘having skin in the game’. In other words, having grazes and bruises from being an actual player rather than supporting or coaching from the sidelines. It seems a more appropriate metaphor for a process called Scrum but the pigs and chickens thing has stuck. Pigs have 'skin in the game'. Chickens are well-intentioned, interested spectators willing the team on but not able to contribute in any concrete way to the final result.

In the patterns above, chickens, not pigs, are providing the expertise whether written or face-to-face.

Personally, I believe the key to effectively achieving a change in culture and a sustainable transformation is to:

1. Identify the technical leaders within projects; those that are “self-driven to produce quality results on time … combine technical ability with enough people skills …are trusted and respected by both their managers and fellow developers, are determined to make the team succeed, and usually live the work.” (Chief programmers, Chapter 2:  A Practical Guide to FDD).
   
2. Sell them the vision: if you cannot sell these people on the benefits to them, their colleagues and the organization of the new way of working then something is wrong.  Either these people are not the real technical leads, you are not communicating the advantages of the change well enough, or the new way of working is actually a pile of ‘emperors new clothes’.
   
3. Provide in-depth training and on-going coaching. It is better to have a single lead person trained in-depth who can coach his teammates through the basics than to have the whole team trained on the basics with no-one on the team to turn to when the basics are not enough. Providing initial training is simply not enough. When the pressure is on, the temptation to return to previous ways of doing things is often too strong to resist. If technical leads are to work for you, they need on-going support and coaching, and a means by which they can support each other.  Good external coaches (expert chickens?) can help here.
   
4. Let the technical leads continue working on their projects. Some fail at the final hurdle by doing 1-3 above and then assigning or scheduling the technical leads to coach other projects, effectively turning them from pigs into chickens.

To summarize, if you can produce a change in the behavior of the lead pigs, the other pigs will, by definition, follow. However, pigs will not follow chickens for long because chickens are simply not pigs.