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:
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.
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.
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:
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.
conventions or training classes, but not always. Books remain a low-cost (and my favorite!) way of obtaining information, especially when coupled with a discussion group. Blogs, listservs, and podcasts are all excellent methods of finding new viewpoints and new voices in the community. A more social way of getting exposed to new ideas is to join a local organization such as a user group or technology incubator. Attending a BarCamp gathering is another great community learning opportunity. After all, meeting new people can be just as rewarding as understanding a new concept!Watching my kids rejoice in their summer vacation I'm struck by the irony of our situations: as children we all disliked school; as adults we crave new learning opportunities. In the workforce, this usually means either
While my boys are excited they don't have any more homework for a few months, I look forward to my next opportunity to learn. What do you do to acquire new knowledge?
I recently had the pleasure of seeing David Douglas and Raj Vaidyanathan presenting "Integrating into the whole...embedding agile processes into all aspects of S1's business model" at Agile Austin. During that presentation, David was lamenting the fact that agile is fragile. He related several experiences where, despite visible indicators of success, agile adoptions had ultimately failed to be sustainable. This lack-of-sustainability pattern is certainly a familiar one, and we should look hard to find root causes so we can address them.
I think the lack of sustainable agility can be traced—in large part—to a loss of trust. "The first thing to build is TRUST!", as Brad Appleton says. Trust is critical to the proper functioning of an agile organization. Where there is less trust, we see more dysfunction. On the surface it can appear that everything is going well. We all have a lot of real-world experience with putting on a façade of trust. Ultimately the actions of the team will reveal how much, or how little, trust actually exists.
Trust is slow to build, and quick to destroy. Since trust is a foundational element of agility, the fragile nature of trust makes agile fragile. However, there is hope here as well. Trust relationships exhibit a plateau behavior. Once established, they achieve a degree of stability that allows trust to survive sort-term attacks. A slow erosion of trust, or a catastrophic trust-breaking event, will still lead to dysfunction. If you are feeling a loss of agility, it may be a good time to check on the level of trust in your organization.
A couple of weeks ago, I was peer reviewing some work by a colleague. I was struggling to communicate what was and what was not covered by the popular agile processes - what I call the scope of the process. For example, Scrum and eXtreme Programming essentially focus on a single small, cross-functional, development team. At a fundamental level, they do not cover larger teams or projects or organizations consisting of many small dependent teams. They say little about how customers or product owners decide on the business value and priority of the user stories or backlog items they create. Neither do they say much about working with a formal testing organization.
While there are plenty of suggestions and some popular approaches to extending Scrum and eXtreme Programming to cover multiple dependent teams, they are just that; extensions to the original core set of rules or practices.
Anyway rather than try and explain this by waving my hands around I resorted to drawing a picture to communicate what was in my head. Although very simplistic, it seemed to help so I thought I'd share it. If I have done it correctly, you should be able to click on the image below to see it full-size (legibly in other words) in a separate, pop-up window.