Do andons apply to software development?

Dear Gemba Coach,

I work in software development, and I really don’t see how andon applies – what am I missing?

Good point. Let me backtrack and try to give a bit of lean context to the question. In the broadest sense, lean is about discovering new ways to help customers solve their problems without generating waste – and being sustainably profitable in the process. I think we can agree this applies to software as much as manufacturing: software is usually written to solve a problem, and we’ve all felt the pain of poor code in the hassles it creates for users – waste.

I think we can agree this applies to software as much as manufacturing: software is usually written to solve a problem, and we’ve all felt the pain of poor code in the hassles it creates for users – waste.

The next specific thing about lean is that we strive to learn how to learn: we don’t jump in looking at the piece of software thinking, “Oh, this needs to be improved, and this – and that’s how we’re going to do it.” We look hard at how users interact with the software, use it to do solve their problems in their daily lives, and ask ourselves:

• Could it be safer?
• Could it fail less, or demand less rework?
• Could it be faster?
• Could it be cheaper?
• Could it feel better?
• Could it be greener?

Our aim is not to jump to conclusions about what we, as developers, don’t like about the software, but what challenges it presents to users – which is a rather different question. A lean vision of software, or anything else for that matter, is to be able to make a good guess on what needs:

• Value Analysis: which issues need to be resolved in the current release to add more value or generate less waste?
• Value Engineering: which problems we’ll have to solve in the next release, and in particular which innovations will we bring in, to continue to add more value and generate less waste?

Unless these two terms are clear in your mind, from a lean point of view, you haven’t got a clear, dynamic view of customer satisfaction – the first aim of lean.

Just the Facts

Now, the third point is that, in lean, we need the discipline not to figure out these challenges on our own, but to discover them with the developers themselves. Sure we’ll have our opinion, and it’s probably a good one. But that’s not the point – everyone has an opinion. The lean way is to create consensus on the problems that need to be solved through first-hand experiences – facts.

To do so, the lean trick is to start by reducing lead-time in everything you do: learn to turn around things faster. As I write this column, I can ask myself, how do I respond faster? Let’s look at this process:

1. You ask a question, somewhere at lean.org or directly through social medial.
2. After some time, this gets to me, and it goes on a “must think about it” pile.
3. When I have a chunk of free time, I sit down and start writing a couple of columns.
4. I then send them to Chet Marchwinski for editing, where they sit in his pile.
5. In a couple of days, Chet usually sends them back to me for a final look.
6. And then they go to a “supermarket” of columns ready to publish.
7. And the answer will be finally posted on the site.

Which means that through the normal process, you could get an answer to your question weeks (sometimes months) after you’ve asked it – and by that time it’s likely not very relevant anymore, which is poor quality.

Could we accelerate this process? Sure:

1. We could have a central place to ask questions (would that help?) that I could check daily.
2. I could answer questions immediately without first thinking about it (would that help?).
3. I could stop everything I’m doing and write the answer as soon as I get a question (would that help?).
4. Chet could stop everything he’s doing and edit the column right away (would that help?).
5. I completely trust Chet in his edits and very rarely have anything to say other than okay the piece so we could probably skip step 5 altogether (but what happens when I do have something to say?)
6. We wouldn’t really need a supermarket of columns and could publish it right away, which would make the column turnaround much faster.

Say we do this (we have tried it in the past, actually): is it better? Well it’s certainly faster, but we also hit a number of intractable issues, and some of them are big ones:

1. Topic issues: I can slip into writing mindless columns, on autopilot, and with quality, increased output doesn’t mean better outcomes.
2. Style issues: I start writing on the trains and planes as I go to the gemba in order to turn it around quickly.
3. Consistency issues: By taking away the final check, Chet and I no longer have a conversation about his opinion/judgment on the quality of the piece beyond typos and etc.

The speeding up exercise works, not because of turning around columns faster, but in discovering deep challenges in column writing that we can now think to improve:

1. What makes a column interesting? (After all, I’ve been writing these for seven years – when does it get stale?)
2. How can we make the columns easier to read? (I’ve been trying to write shorter pieces for years – I swear!)
3. Do we cover all topics of lean or get caught in a rut? (Do I sound like a broken record? It’s happened to better bloggers than me!)

None of these challenges are easy to solve. None of these challenges have immediate solutions either.

Pulling the Code Cord

Which is, if you forgive my long-winded answer, where andon comes in. As we accelerate the process and reduce the lead-time (more carefully than I’ve suggested) we need the other part of the mechanism, something to highlight the challenge as and when it occurs. I need something to tell me as I write that:

• I’m being boring.
• I’m being confusing.
• I’m harping again on something I’ve said again and again.

If I don’t see the problem as I write – I’ll never learn to do it differently.

If I don’t accelerate the process – I’ll never see the problem appear.

Which is where andon comes in. First, you need to be trying to reduce the lead-time, mostly by increasing flexibility in reducing batches (rather than by accelerating operations themselves) and second, you need to be able to highlight issues as they appear – if not the acceleration completely misses the point of learning to create more value to generate less waste.

How does this apply to coding?

In an IT context, for instance, I know a software development startup that asks of its customers to rank the project on a zero to ten scale every week. Every mark of eight and under immediately triggers an internal review with the project manager to figure out what is happening with the customer relationship and why – that’s an andon.

In a different context, building automated tests in the software will work as an andon as well, by showing where the software is doing something unexpected. Here’s a great description from Google.

Andon goes beyond testing because it also implies immediate investigation to learn by catching the fact in its context:    

1. Alert at every drift from the standard process,
2. Go and see immediately,
3. Help to return on the normal conditions,
4. Ask why? And analyze the cause of drift.

The purpose of andon is not just to stop defects from progressing in the work, or even to go back to standards quickly (although, of course, this helps). The purpose of andon is greater mastery of the job by examining the context where something went wrong with someone else (two pairs of eyes are better than one) as close as possible to the moment it went wrong.

In software as in anything else, andon is any mechanism that stops you from pursuing when something is out of kilter (something we’d prefer to ignore and get on with the work most of the time), makes you look at it “hot,” correct it now and figure out later. Without a push to accelerate the process and reduce lead-time, andon will only reveal known issues, so it is not so interesting, but within the dynamic of continuous flow/stop for quality issues/continuous flow/stop for quality issues, andon becomes the most powerful learning-by-doing tool.