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.)
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.
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.
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?
In these last few posts I’ve been trying to edge towards a deeper undestanding of what agile coaches do. These are thought experiments. My aim is to be able to give our clients a means to assess when and whether they are deriving value from the use of our services. And I believe that this will also give us greater means to implement successful improvements in the effectiveness of the software teams we meet.
Several times, both very recently and in the dim past, I’ve seen folks advocate running software process improvement exercises as if they were agile projects. What would that be like in practice? I imagine we would identify process changes we wish to make, creating a story card for each. There’d be a daily stand-up meeting, at which the change team discusses progress, obstacles and plans. There’d be iteration reviews and planning games, and a backlog of change stories, and the change team would chart the project’s velocity, presumably in some kind of “change points”.
What would that change project’s backlog look like? Well if we’re in the business of implementing change to a recipe, I guess it might have a series of stories, each of which puts in place a specific brick of the whole edifice. Sounds like we know where we’re heading already. We’re in danger of turning the software team into a local optimum within the organisation as a whole. We may even shift the bottleneck away from development altogether. Then what?
But if we’re in the business of improving effectiveness there will be no backlog. There can be no backlog. Each change (possibly a small suite of changes) will have been worked out as a response to the overall organisation’s current greatest need. By asking “where’s the bottleneck?”, “where’s the current constraint on throughput?”, “what is the common root cause of our major incidents?”
And after we’ve implemented this change, what next? We must measure, observe, inspect. We must let it settle in and then measure our new levels of throughput and expense. Then ask the questions again – looking for where the bottleneck has moved to now. This is hansei-kaizen, an endless cycle of inspect-adapt-inspect-adapt, as Scrum puts it. And at each cycle it is the overall organisation’s Goal pulling each change through the system.
Now, what about the individual change “stories”, what will they look like? Will each have acceptance tests? Can we assign each a monetary value? Questions for another day…
What’s the Right Way™ to carry out an agile transformation? Indeed, is an agile transformation always the Right Thing to do?
On the one hand, an agile coach may be hired to “implement” Scrum or XP, because that’s the way the organisation has decided to go. Alternatively, one may be engaged to help improve an organisation’s productivity, say, without regard to whether the resulting system behaviours will be recognisable as this or that agile method.
In the domain of lean manufacturing, productivity improvement itself can – and indeed must – be seen as a pull activity:
“Taiichi Ohno remarked that TPS is very much like the scientific method of experimentation. When this is not kept in mind, the result is “push” style Lean (Do as you are told), rather than “pull” Lean implementation (What is the biggest problem?)”
This is a very clear answer. “Lean” is the name given after the fact to a very effective type of system that was “grown” piecemeal by kaizen – continuous gradual change. (Ohno states elsewhere that all of the key aspects of the Toyota Production System arose individually as solutions to the root cause of some specific incident.) Lean was not the goal, it is simply a name for the resulting shape of the organisation.
Similarly in software development, we must not let the “agile” banner get in the way of our goal, which is the creation of an effective software department. The body of agile knowledge is invaluable as a source of ideas and experience when we are faced with effectiveness problems to solve. But it must not be used dogmatically. “Extreme at all costs” may well be better than we were before, but without the pull from the overall system’s Goal it is unlikely to be sustainable in the long term.
What interests me is effective software development; that is, software departments that contribute to the overall organisation’s Goal of present and future profitability. Such effectiveness must be achieved gradually, by repeatedly resolving the root cause of the biggest problem. The Goal will pull changes through the system, if we let it.
In A Kaizen Event for the Holidays Joe Ely gives us the nutshell version of (what sounds like) a very effective process improvement exercise in his plant. But his main point is much deeper:
“… our marketing team is central to achieving kaizen success. Why? By keeping a growing backlog of work for our team. […] If the business isn’t growing, kaizen won’t work.”
(Joe goes on to suggest that hugging a marketing person might be a good thing to do today. Can I pass…?)
The ‘pull’ from downstream is essential in so many ways. Without it, many upstream activities are simply guesses as to what might be needed. And when workers see their managers guessing, low morale and low productivity are going to follow. (I mused about the very same thing for software development in the product owner must pull and the product owner must pull (revisited) last Spring.)
Value flows quickly through a lean factory all of the time. This high throughput is sustained because faults in the product and process are continuously removed. But in order to achieve such continuous process maintenance, the plant must be over-staffed. A lean factory employs more than the bare minimum number of people required to support current flow rates. Because the preservation of tomorrow’s flow rates depends on eliminating systematic problems. And in a constantly changing world that requires effort.
I read somewhere that Toyota over-staffs by about 15%. That is, workers spend about 85% of their time adding value, and the other 15% ensuring that the current pace is sustainable. Note that value is being added 100% of the time, and product is flowing at the rate demanded by the market. It’s just that by adding one extra person in every six, there’s now a little slack in each team. So when Murphy strikes, the team’s process can be fixed without diverting effort from adding value.
Some Western organisations have taken this 15% slack time and cordoned it off. “Everyone spend 15% of your time improving our processes,” they say. This is undirected effort. Better to have that slack available, and to fix real problems as they occur. This contributes more directly to protecting the value stream.
So an agile software development team should only commit to delivering 85% of what it knows is possible each iteration. The remaining 15% should be used for kaizen activities, and for dealing with quality incidents as they occur. Without that slack, bad luck will either impact today’s schedule or tomorrow’s quality. Either way throughput will be compromised, and the project is on the road to failure.
Hal Macomber points out a rant from Tom Peters, in which Tom tries to claim that kaizen is “dangerous”. His reasoning is that continuous gradual improvement can get in the way of spotting the “next big thing”, and that gradual change isn’t enough in the modern world of short development cycles and rapid obsolescence.
I think Tom has confounded two different business cycles in his quest for a soundbite. As Hal notes, Toyota were able to introduce the new Matrix in one year from concept to customer – precisely because of their continued pursuit of perfection! Without a mature kaizen process Toyota could not have honed their product development process to the point that they could undercut the other manufacturers’ cycle times by upto two years. By even conceiving of the Matrix, Toyota showed that they can innovate; but by getting it into the marketplace in a year, they showed that they have a world-class development process. These are two different things, and it was kaizen that made the second one a reality. Without years of kaizen, the Matrix innovation would have been devalued by a long time-to-market delay.
In my opinion, kaizen frees the hands of the innovator. And to think that sloppy processes can support rapid innovation is dangerous advice, Tom.
Hear Mark Perry read out sections of this post by listening to the first couple of minutes of podcast #60 of his “PMO Podcasts for Executives and Managers”. Thanks for the mention Mark!