blame

This week I’ve come across a few articles that clicked together as I read them, and in so doing they reinforced one of my deepest beliefs about software development – or any other profession, for that matter. The articles were:

  • Train Wreck Management by Mary Poppendieck, in which Mary chronicles the origins of “management” and “accountability”. It seems that hierarchical management structures were first applied in the mistaken belief that it was one person’s dereliction that caused a train crash, and that in future such things could be prevented by management and accountability. Lean thinking says the opposite – that the train crash was an inevitable consequence of the structure of the system, and that specific individuals should not be blamed.
  • Survey Blames Blame for Lean Struggles by Mark Graban, in which Mark notices that a recent survey seems to indicate that employees blame each other for their business failing to adopt lean thinking. Mark’s subsequent analysis of the survey shows, however, that it seems to lead the participants to ask “who is responsible for…?” – so it should be no surprise that the top answers mostly involve job titles! Mark’s response is to design a new survey in “5-whys” style – an effort I applaud, even though I disliked the example embedded in the survey.
  • Risk Aversity by Henrik MÃ¥rtensson, in which Henrik uses the Theory of Constraints thinking tools to dig into why many organisations are immune to change. One of the root causes, according to Henrik, is that “mistakes” are punished in the average workplace – and so after a while everyone becomes afraid to innovate, or even to change the status quo. A truly lean organisation will reward even the person who makes a change that leads to lower throughput, because at least they contributed, and knowledge about the whole system has been improved as a result. But even the use of the word “mistake” shows how deep-seated is our culture’s desire to blame, and hence to discourage.
  • The Secret Sauce of Highly Productive Software Development by Amr Elssamadisy and Deb Hartmann, in which the authors propose that inability to learn is the bottleneck (in the Goldratt / TOC sense) in most software teams. I need to think about their “bottleneck” claim, but I do agree that learning is the key to agile success, and that a learning organisation will out-perform any other in the longer term.
  • The QnEK Horse has left the Barn by Hal Macomber, in which Hal opens the lid on a community for sharing QnEK (Quick-n-Easy Kaizen) ideas. QnEK can only succeed in an organisation where “mistakes” don’t exist, where blame is replaced by systemic learning.

For me, these articles all dovetail:

  • learning is the key to long-term success
  • the system can always be improved
  • systemic learning requires a constant flow of improvement suggestions
  • blame discourages innovation

It seems clear to me that blame itself lies at the root of many organisations’ problems. The system can always be improved, and is always the source of problems. People should be rewarded for discovering those problems and trying to fix them, especially when they “only” create new knowledge about how to perform less well.

TOC mini-conference – UK and EU

If you’re interested in the Theory of Constraints and you’re based in the UK or EU, Clarke Ching’s proposal could be right up your street:

“If there is enough interest then I will kickoff a low-cost TOC mini-conference in the UK later this year. It will probably be held in Edinburgh during late-september or october and last one or two days. The goal will be to meet people and learn.”

I think this is a great idea, but it will only happen if enough people join in. If you’re interested, please hop over to Clarke’s blog and add your support.

how to start organic change

Through bitter experience I’ve come to recognise that change works best when it isn’t imposed, and when it is allowed to occur over a period of time. So when you or I recognise that an organisation’s performance is below par, how are we supposed to get it to change. These days I try to foster change, rather than to impose it. Here are some great ways to start the ball rolling:

Current Reality Tree (CRT)
This is a great way to bring the whole organisation together in recognising and understanding current problems and the links between them. Develop a CRT together as a group to understand the very small number of root causes that lie behind today’s poor performance. Hopefully at the end of the process the whole group will feel they “own” those root causes, and everyone will be motivated to seek and implement solutions.
Simulations
Help everyone gain some experience they wouldn’t otherwise get, by running simulations. These “games” can show some specific aspect of current or future life, but isolated from the other daily crud and also speeded up. Games give the participants rapid feedback on decisions such as they make every day, and insights into their impact on other aspects of their organisation. These insights often “click” some days later (link via Keith Ray), causing folks to spontaneously begin instigating change themselves.
Hansei-kaizen
Run frequent (eg. weekly) retrospectives, and encourage participants to take ownership of the problems they observed in the previous week. Create a culture in which the “way we do things here” gradually evolves, and in which everyone sees this evolution as natural.

I’ve worked almost exclusively with the last of these, usually preceded by some root-cause analysis using CRTs. I’ll definitely be adding more simulations to the mix in future. Do you have more techniques to add to this list? And how do you mix them when asked to initiate an agile transition?

thinking at SPA2006

This year my stay at SPA2006 is limited to only one and a half days. Nonetheless I plan to attend some interesting sessions, and in the next few posts I’ll describe my impressions of them. The first of these was Thinking for a Change:

In this 3-hour workshop Pascal van Cauwenberghe and Marc Evers led us through the construction of two of the five Theory of Constraints Thinking Tools. We divided into groups, such that each table comprised one “customer” – someone who had a problem to be solved – and a number of “consultants”. The objective was for each group to build a Current Reality Tree for their customer’s problem, and then to build a Future Reality Tree for a possible solution. The problem on our table was set by Emmanuel Gaillot, who wanted to understand some specific behaviour of the managers in an organisation he had worked with.

Now, I had already read the book Thinking for a Change, and frankly found it quite disorganised. Pascal and Marc had also found the same, so for this workshop they had picked through the book and defined a step-by-step process for building CRTs and FRTs. They took us through this process just-in-time, at each stage showing us the next step using their worked example, and then giving us 5 minutes to perform the step on our own problem. This made for an absorbing three hours, in which we actually got to try the whole process from end to end on a real-life situation.

Unfortunately our group got a little bogged down at various times, mostly due to our particular problem being way too large to solve in a dozen 5-minute chunks. Nevertheless we had fun, and we gained practical experience of building a CRT and a FRT.

5-whys versus current reality trees

A while back I tried running Toyota’s full 5-whys process on every problem that came up on a particular project. Each time through, we found that the fourth and fifth levels regularly came up with the same old reasons – to such an extent that the process became somewhat devalued for us. Don’t get me wrong, we did find valuable insights some of the time, and consequently we were able to permanently eliminate some classes of problem. But usually those insights and fixes came from our values (ie. automate everything, test everything etc), and not really from the process itself. I have only rarely used full-on 5-whys since, preferring an informal team workshop approach to fixing root causes.

But recently I’ve been looking at Current Reality Trees (CRTs) from the Theory of Constraints. The main difference, it seems to me, is that a CRT begins with around ten undesirable effects (UDEs), whereas 5-whys begins with only one. So in a CRT, the interplay between the numerous problems seems likely to get to the common core of the problem more quickly. And that core problem is instantly validated, because we’ve derived it in such a way that we know it is relevant to many problems.

If you’ve used both techniques, did you find one more successful than the other? Did one generate more convincing results? Or are they answering different questions, and should they therefore be used in different contexts?