“Stand in the circle”

While catching up on my reading of lean blogs today I stumbled on a post by Jon Miller at Gemba Panta Rei, called Give Me 60 Minutes and I’ll Give You a Lean Transformation, in which Jon describes a very simple — and quite theatrical — means of driving improvement:

“This exercise starts with picking a spot in your gemba and standing in that one place for 30 minutes. Find 30 things to improve in 30 minutes. Write them down. Take the next 30 minutes and make at least one of the improvements you wrote down.”

5278916281_6e11555f1f_b

Cornell University Library

Taiichi Ohno, the architect of lean manufacturing in Toyota, would teach his staff how to see waste by telling them to “Draw a circle and stand in it!” Could that work in a software development organisation?

First, I would note that a software development organisation doesn’t consist solely of programmers at work – all of the usual office activities will also be happening too. The developers may not be the bottleneck, and standing in various different spots around the organisation will thus likely bring different parts of the overall value stream into view.

Second, and as the commenters on Jon’s post point out, a lot of what goes on in an office is “invisible” because it is conducted in the virtual workplace “inside” computers. This is doubly true of software development. But as Jon suggests, the list of 30 problems could include the fact that status or progress aren’t visible, and from there its only a small step to the introduction of things like burndown charts or traffic lights for the build.

So I think the approach is feasible from a purely practical point of view; but what of the psychological / cultural angle? How might a roomful of developers react to someone with a clipboard watching them for 30 minutes every couple of weeks? I feel the person standing in the circle must have the team’s permission to be there – perhaps being a member of the team, one of the developers, most of the time. There’s no harm in the team asking someone else to do the job occasionally, to provide a fresh look and see things the team might miss themselves. But the idea that improvements can be imposed, or that one’s performance and behaviour are being monitored, is anathema. The team must decide it wants to improve, and must decide to adopt the lean kaizen approach; then the team can “appoint” one or more observers to help it find waste in the team’s activities.

On balance I think “standing in the circle” is worth a try, given sufficient introductory training to ensure that appropriate permission is granted by everyone. I’m interested to find out what kind of things appear on the list – particularly after a few weeks of running the technique. Please let me know what happens when you try it!

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.