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?

use spikes to manage technical risk

At the AgileNorth meeting on Monday of this week we recapped an old discussion about technical risk. Some months ago Phran Ryder had raised the question of how to prioritise stories during release planning. I have always held out for business value as the only factor to consider. Phran however insisted that his project was different, and that technical risk was more important. The topic came up again this week, and this time Phran was able to provide a very succinct explication of how we resolved the issue.

The dilemma is this: In order to deliver maximum value under all possible outcomes, we should prioritise our stories solely on the basis of their value as perceived by the Customer. But what if we can’t assess that value, or estimate the stories, in advance? What if we need to bring some stories forward to the front of the schedule, so that by doing them we gain further information to help us create the remainder of the plan?

Here’s a quick attempt at a conflict cloud:

spikes

(I’m not too pleased with this – please help if you can think of a better formulation of the dilemma.)

We resolved the dilemma by attacking the necessary condition at bottom-right in the diagram: we reminded ourselves that implementing a story isn’t the best way to obtain information about when to implement it! That’s the job of a spike (a throw-away prototype). We should do just enough work to obtain the information we need about the story. Just enough to put us in a position to correctly prioritise or estimate it and get on with planning the release. (At this point we must also throw away the spike code. Because the odds are very good that the world will be a different place when the spiked story comes to the top of the pile. If we kept the spike, it would likely require learning and re-work to fit into the new and growing system at that time. Best to just ditch it now and start afresh when the customer really needs it.)

using the TOC thinking tools

I recently had a conversation with Jim Bowles, a Theory of Constraints (TOC) consultant who has been helping out on the TOCSoftware Yahoo group. He was helping me to understand the conflicts within the cost-accounting culture in a large organisation I’m working with. I’ll report more on that conversation in due course. For the moment, I was impressed by how he was able to focus my rambling misgivings by using the TOC thinking tools.

In particular he encouraged me to try expressing my issues in terms of evaporating clouds and current reality trees. I’ve written a fair amount here about the contradictions in the organisation I mentioned, so I’m going to update those entries with evaporating clouds, as I develop them. So far I’ve done i only want a pencil and give him what he wants. More to follow as I find the time…

i only want a pencil

My pencil is blunt. And I know there are no pencil-sharpeners in this office. But I do know there’s a stationery store upstairs where I can get a new pencil. (I already have 7 blunt pencils in my bag, all provided by this stationery store. For some reason I always forget to sharpen them when I get home. So I have to treat pencils as a use-once resource.) The stationery store has gone. I ask, and it turns out that the stationery department were ‘let go’ last month.

I’m told the project office may have a secret stash of stationery, if I ask nicely. I have a contact there, so I ask her. “Ah – no, we have none; try Julia.” So I call Julia’s mobile. From wherever she is in the world, she tells me I need to see Pat. I look Pat up in the site directory and go to her end of the building. Yes, she has pencils. If you’re gasping at this rigmarole wait, it’s not over yet.

“Are you authorised to take our stationery?” I use the secret handshake and she’s happy. “Can’t be too careful these days. Not everyone is allowed access to stationery.” She walks over to a wall safe and keys in the numeric combination. From the safe she takes a set of keys. We walk over to an anonymous door, which she unlocks. We go in, and I get a pencil. “Devils!” she exclaims, “someone’s taken 8 lab-books since Thursday!” She locks everything again on the way out.

Total elapsed time from running out of lead: 30 minutes. Number of staff involved: 5. Total staff time: 60 minutes. Total cost of the exercise: around ¬£80, plus the phonecall, plus disruption to 5 people’s flow. How much do pencils cost?

Update:
Here’s an evaporating cloud showing the conflict within the organisation:

pencils