An idea for retrospectives

I recently read 2 second Lean by Paul Akers. It’s a marvellous little book. It has re-ignited my deep-seated love for lean thinking, and in particular for continuous improvement via aggregation of marginal gains. I highly recommend you take the 2-3 hours to read it, and then look for ways to apply Akers’ ideas to your team.

Partly inspired by 2-second Lean, and partly by the mob programming practice of daily retrospectives, I’ve recently been experimenting with using daily retrospectives for continuous improvement. Imagine you ran a retrospective at the end of each day, using only the following question:

Let’s set aside the first 30 minutes of tomorrow to eliminate, forever, some of the waste we saw in our practices today. Let’s see if everyone in the team can remove at least 2 seconds of time we wasted today not delivering value. Which 2 seconds should we choose to eliminate? And what shall we do to achieve that?

What would you pick? Ideas from the teams I work with have included learning keyboard shortcuts, using Sublime Text instead of Visual Studio, deleting unused code, documenting setup steps in a wiki, and so on.

Perhaps you could also follow Paul Akers’ practice of making “before” and “after” videos of your improvement, to share with other teams? (Hopefully I’ll find the time to share some of my personal 2-second kaizen videos here soon.)



I’ve recently been doing some coaching at the BBC in Media City, Salford. During the first couple of weeks my commute home always took 90 minutes; then on maybe one day per week I got home in 65 minutes; now it usually takes 65 minutes, and only occasionally (maybe one day per week) takes 90 minutes. I have saved 25 minutes on my usual journey time, and I have done it without resorting to extreme measures such as (heaven forfend!) spending money or running. How? By developing a few “micro-habits” — little routines that each save a tiny amount of time, but which together add up to a huge saving of almost 30%. I believe this approach can be applied to everything we do, so I think it may be instructive to dig into that 25-minute saving to see how it is achieved…

First, let’s take a look at the typical 90-minute commute home:

  1. At 1600, pack away my things, leave the office and walk to the tram stop.
  2. Wait for the next tram, board it, and wait for it to move off.
  3. The tram journey takes 20-25 minutes to reach Piccadilly station, depending on traffic conditions in Manchester.
  4. Walk up to the main concourse in the station and to the departures board.
  5. Wait 20 seconds for the board to show trains to Macclesfield. The next train is the 1648, departing from platform 3.
  6. Walk to platform 3, stopping to find and show my ticket to the inspector at the gate.
  7. Wait for the train. The typical wait at this point is 10-12 minutes.
  8. Sit reading on the train until it arrives in Macclesfield at approximately 1718 (actually the usual arrival time is 1723).
  9. Walk 0.5km to my car, then drive 3km home. The drive takes 5-10 minutes, depending on traffic conditions.

I noticed that there is an express train leaving Manchester Piccadilly at 1635 and arriving in Macclesfield at 1655; I also noticed that I usually arrived in Piccadilly station at around 1638. So it would only require me to save 3-4 minutes in the first half of my journey in order to realise a 25-minute saving overall. Note that there are plenty of delays in this process. I have no control over some of these, such as random traffic hold-ups, or the actual arrival time of the next tram. But I do have control over some, and during the course of a couple of weeks I have developed the following micro-habits:

  1. During the afternoon, as I use things for the last time I put them away in my locker. This is a gamble, but most of the time it turns out to be okay. And it saves me upto 2 minutes of packing up time at 1600, which means I have slightly greater a chance of catching an earlier tram.
  2. Trams are scheduled every 12 minutes, so the expected mean wait time at any stop is 6 minutes. If there is no tram waiting (or imminently arriving) at Media City, I walk to the next stop down the line. That’s because Harbour City is on TWO tram lines, and so more trams pass through that stop. The walk takes 3 minutes, and always pays off: either I get the next tram out of Media City, thus saving nothing and losing nothing, or I get an earlier tram on the Eccles line, thus removing upto 3 minutes waiting from my journey.
  3. The rearmost door of the tram is always closest to the stairs when it pulls in to Piccadilly; so I always position myself close to that door, to minimise the time it takes to get up to the main concourse.
  4. I now ASSUME that I will be in time to catch the 1635, and I ASSUME that it will depart from platform 6 as usual. So I don’t go to the departure display and wait for it to show me current status; instead, I go directly to platform 6, a saving of 20-30 seconds.
  5. While walking to the tram I found my ticket and made sure it was in an easily accessible pocket. When I arrive on platform 6 I can now retrieve the ticket instantly and show it to the inspector without breaking step, thus saving 20 seconds.

As the departure of the 1635 is usually imminent at this point, these last two savings of upto 40 seconds can mean the difference between catching it and having to wait 13 minutes for the 1648. If there were no major delays on the tram I will now get on the 1635, which arrives in Macclesfield at 1655 (always). The remainder of my commute is unchanged, and so I arrive home at around 1705 — a total commute of 65 minutes instead of 90.

Most people will, I think, do similar things to these when faced with a regular commute such as mine. As I mentioned above, I believe this approach can be applied to everything we do, and in particular I think there are huge savings to be made in software development. I believe that many, if not most, software teams could significantly reduce cycle times — the time taken to pull a single product improvement through from “idea” to “in use” — by developing micro-habits to eliminate waste. I believe that the most productive teams, and the most productive developers, already do this; and I am sure that these micro-habits make the best upto ten times as productive as the rest.

So what are the micro-habits that will make this huge difference for software development? Some of them are universal and coarse-grained:

  • use a refactoring tool,
  • use a version-control tool,
  • become test-infected,
  • write black-box behavioural tests at all levels,
  • pair program,
  • refactor mercilessly,
  • work outside-in, etc.

But I suspect that there are more that are specific to the developer, or to the team, or to the codebase, or to the technology being used. Some of mine are:

  • learn the keyboard shortcuts for all of your tools,
  • drink a lot of water,
  • pick pieces of work that can be committed to trunk at least every hour,
  • re-run the tests after every distraction,
  • commit all work before going home or throw it away,
  • automate tmux set-up,
  • automate towards a single-click build,
  • automate towards a single-click deploy, etc etc.

Do you have any stories showing how a few micro-habits have transformed a team’s productivity? There seems to be no written repository collecting such developer micro-habits together, and nor is there any obvious forum in which they are explored, shared and discussed. That seems a shame, and a huge waste. What should we as a community do about it?

[Credit to Sean Blezard for coining the term “micro-habit” when I explained to him the idea for this blog post.]

the toyota ballet

Over at Evolving Excellence today Kevin Meyer describes his experiences of a visit to Toyota Kyushu. Kevin is struck dumb by every aspect of the plant’s operation — for example this:

“Every movement is choreographed and improved. You have to stand and watch each person for several cycles to see just how choreographed. Each movement has a purpose and is designed to minimize movement for the current and next operation. As he is exiting the front seat after installing four bolts a slight twist of the left hand will open the rear door so as he swings out of the front seat he swings right into the rear. As he exits the rear he leaves a tool that is required by the next operator. This is very hard to describe, but it is truly a manufacturing ballet.”

Whenever anyone spots a problem they pull a cord to sound a bell:

“How often does the chime sound? About once a minute throughout the factory. There is no problem reporting a problem. The intent is to find it and get it fixed, fast. As in within a minute. How long does it take you to identify, report, and fix a problem? I know what you’re thinking, I’m embarassed too.”

To get the full sense of Kevin’s amazement, I recommend you read the whole article for yourself. The brilliant and breathless description makes me want to go to gemba and see for myself.

is CruiseControl waste?

A few days ago I noted that Shigeo Shingo, one of the founders of lean manufacturing, once said that testing to find problems is waste, whereas testing to prevent problems is not. Today I’ve been helping out with configuring an instance of CruiseControl, one that runs three or four projects and checks that no-one has broken any of them. This is testing after the fact, after check-in, after the developer has written his unit tests and his code. So is it waste?

I think it’s quite a close call, but on balance I’ll differ with James Shore and answer “no”. There’s no getting away from the fact that CruiseControl is reviewing code after the fact. After commit. We have to break our project before CruiseControl helps us out. And I wonder whether the presence of a good, automated tester downstream can sometimes engender a little too much comfort. I know I’ve been guilty of saying “Oh let’s just check this in — CruiseControl will soon tell us if we’ve made a mistake.”

But in CruiseControl’s favour, it certainly does catch the most frequent problem I’ve seen with (developers’ use of) version control: forgetting to commit a new source file. And by running a complete, clean build, it can throw up environmental or portability problems not seen when developers work for long periods in stable, cosy workstation setups. So it’s a fresh pair of eyes, doing a quick review of the project’s latest state. Possibly akin to automated checks of a sub-assembly in a lean manufacturing plant, it catches some problems early in the flow.

Maybe in the end it’s about the team. Installing CruiseControl is a great first step on the road to being “always release ready”, and definitely helps teams transition to agile development. And then after a while, I wonder whether there’s a level of team maturity at which it may no longer be needed?

downstream testing implies a policy constraint

As usual, it takes me multiple attempts to figure out what I really want to say, and how to express myself. Here’s a bit more discussion of what I believe is implied by downstream testing:

The very fact that downstream testing occurs, and is heavily consuming resources, means that management haven’t understood that such activity is waste. (If management had understand that, then they would re-organise the process and put the testing up front — prevention of defects, instead of detection.) No amount of tinkering with analysis or development will alter that management perception, and therefore the process will always be wasteful and low in quality. So the constraint to progress is management’s belief that downstream testing has value.

no more iterations

This week Wayne Allen is starting an experiment: one of his teams is going to drop the “traditional” agile approach of iterations and velocity, in favour of a kanban-style pull system with capped work in progress. The team will do no estimation, and the only metric for the department will be the average number of days required for a story to make it through the whole process.

I hope Wayne will keep us informed on the experiment’s progress and results, because I believe this is the kind of practical research that the agile world desperately needs right now. I suspect this kind of move could only be made in an organisation that has built up a deep reservior of trust in agile (and in Wayne); I wonder what other pre-requisites ar enecessary for kanban development to be acceptable (not to mention successful). I’m particularly interested the reactions of those who want to know what features are coming in which release at what date: Will they have less visibility of progress and planning information than before? Will they get nervous as a result? Or will they adapt their behaviour to the new throughput metric?

Hats off the Wayne and colleagues for trying this, and for anouncing the experiment publicly.

“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.”


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!


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.

carnival of the agilists, 3-aug-07

John Brothers has posted the latest edition of the Carnival, entitled I’m running late. This is a perennial topic for all software development projects, and doubly so for those of us who take a lean or TOC view of productivity and change, so props to John for bringing that focus to the carnival this time around.

Speaking of TOC, one recent post that escaped John’s attention is Multi-Tasking: Why projects take so long and still go late by Kevin Fox. Every time I work in a large organisation I find myself writing about multi-tasking – and wondering why “common sense” is so rare…