the lean startup

is an excellent book by Eric Ries (isbn 978-0-670-92160-7). As usual I'm going to quote from a few pages:

What if we found ourselves building something that nobody wanted? In that case what did it matter if we did it on time and on budget?

I've come to believe that learning is the essential unit of progress for startups.

If you cannot fail, you cannot learn.

Qualitative learning is a necessary companion to quantitative testing.

Pay no attention to the eight people behind the curtain.

When I could think of nothing else to do, I was finally ready to turn to the last resort: talking to customers.

That which optimizes one part of the system necessarily undermines the system as a whole.

Large batches tend to grow over time.

The paradoxical Toyota proverb "Stop production so production never had to stop."

We routinely asked new engineers to make a change to the production environment on their first day... They would ask, "What will happen to me if I accidentally disrupt or stop the production process?" ... We told new hires, "If our production process is so fragile that you can break it on your very first day of work, shame on us for making it so easy to do so." If they did manage to break it, we immediately would have them lead the effort to fix the problem as well as the effort to prevent the next person from repeating the mistake.

Switching to validated learning feels worse before it feels better... the problems caused by the old system tend to be intangible, whereas the problems of the new system are all too tangible.

The Toyota Way

is an excellent book by Jeffrey Liker (isbn 978-0-07-139231-0). As usual I'm going to quote from a few pages:

One day a Ford Taurus mysteriously disappeared. It had been in the factory so they could try fitting it with some prototype mirrors. When it vanished, they even filed a police report. Then it turned up months later. Guess where it was. In the back of the plant, surrounded by inventory.

Extra inventory hides problems... Ohno considered the fundamental waste to be overproduction, since it causes most of the other wastes… big buffers (inventory between processes) lead to other suboptimal behaviour, like reducing your motivation to continuously improve your operation.

…was that data was one step removed from the process, merely "indicators" of what was going on.

Building a culture takes years of applying a consistent approach with consistent principles.

It seems the typical U.S. company regularly alternates between the extremes of stunningly successful and borderline bankrupt.

Flow where you can, pull where you must.

When I interviewed [Fujio] Cho for this book, I asked him about differences in cultures between what he experienced starting up the Georgetown, Kentucky plant and managing Toyota plants in Japan. He did not hesitate to note that his number-one problem was getting group leaders and team members to stop the assembly line.

Every repair situation is unique.

The more inventory a company has,… the less likely they will have what they need [Taiichi Ohno]

I posit here that Toyota has evolved the most effective form of industrial organisation ever devised. At the heart of that organisation is a focus on its own survival. [John Shook]

You cannot measure an engineer's value-added productivity by looking at what he or she is doing. You have to follow the progress of an actual product the engineer is working on as it is being transformed into a final product (or service).

Everyone should tackle some great project at least once in their life. [Sakichi Toyoda]

Waiting work wall

One of the things I do a lot when visiting software groups is simply sit with individuals as they work. Sometimes the person I'm sitting next to is a really superb developer. They finish their work fast and to a high standard and hand the work on to the next person downstream. This next person may also be really skilled but their work might just inherently take longer. If the amount of work passed on exceeds the capacity of the next person then a growing batch of work-waiting-to-be-started-by-the-next-person will naturally form and grow.

This batch of work-waiting-to-be-started-by-the-next-person is waste. That's well known and well written about. What's not so obvious and not so well written about is how it encourages silos to form. It literally forms a barrier between the increasingly separated silos that form on either side of it.

Think of each waiting-work-item as a brick in a wall. But not a long, low, queue-shaped wall that's easy to see over. Rather, a short, high wall. One that you can't see over. One that hinders communication.

The amount of waiting-work between two silos is inversely proportional to the lack of communication between the two silos. The more waiting-work, the less the communication. The less communication the more waiting-work. Round and round it goes.

So, if you have some really superb developers then beware. They might be creating a downstream wall of waiting-work around which silos are forming.

ALE CyberDojo Ice Breaker

I ran a mass-participation CyberDojo "keynote" at the excellent ALE conference in Berlin recently. 10 laptops were setup with a Yahtzee refactoring exercise in Java. Over 200 people participated. The aim was not to write code - it was to mix people up and get lots of energy into the conference right at the start. I think it worked very well.

All I need to know about manufacturing I learned in Joe's garage

is an excellent book by William B. Miller and Vicki L. Schenk (isbn 0-9630439-3-5). As usual I'm going to quote from a few pages:

I mumbled back something equally unintelligible, the traditional response to somebody whom you aren't sure you've met and whose name you aren't certain of.

"Why is there such a conflict?" he asked. "Both departments are striving for the same thing, the good of the company. Why should they not work together?"

With all that volume flowing through his "factory," even the slightest unplanned act will ripple through everything else with a domino effect.

Fanatic: A person who redoubles his effort after having lost his direction.

If you double the amount of equipment and tools in use, you must halve the failure rate simply to stay even.

Planning can be perfect - it's all theoretical. Execution can never be perfect - it involves real people using real tools on real material.

People are expected to inspect their own work, both for function and to specification… Statistical and analytical charts are maintained on the production floor by workers, not by Quality Assurance people in a remote office.

Like most computer people would have, he had stayed close to his electronic toy rather than come to the garage to watch the production operation.

The finest carver does the least cutting.

Nobody ever tried harder under pressure.

"know'why" in addition to "know-how"

kanban 1's game

NB: Heres a more recent slide-deck

I ran my Kanban 1's Game as an open space session at both the xpday conference and also at the Lean, Agile eXchange conference. It proved quite popular so here is how to play it if you're interested. Kanban1sGameRules

Some notes on new game variations/updates

Thank you to Kevlin Henney and Liz Keogh who helped to improve the game.

Agile, Lean and Kanban eXchange cyber-dojo

Thank you to SkillsMatter for hosting the Agile, Lean and Kanban eXchange conference. It was a great event. And thank you to the ten or so people who participated. I got some great feedback and plan to make some tweaks to cyber-dojo, particularly giving the players the ability to control the rotation period in their dojo. It will be interesting to see what value future players will set the rotation period to when they have a free choice.
I also introduced a very simple mini kanban display for each laptop; three pieces of paper marked red (in red), green (in green), and refactor (in black). You then move your avatar badge (eg wolves) onto one of the pieces of paper to reflect your current intention.

A day of deliberate practice

A Day of Deliberate Practice is the name of the JAOO conference tutorial session that Kevlin Henney and I are looking forward to running on Thursday 7th October. We've done some detailed preparation for it and think it's going to be really great. We will be using deliberate practice to try and increase the personal and technical agility of the participants.

You can get a 20% discount on the three conference days. Simply follow either Kevlin or myself on Twitter and then use “JAOOspeakerfollower” as promotion code upon registration: https://secure.trifork.com/aarhus-2010/registration/

It's often a situation problem

In a previous blog post I commented on a recurring theme in several software classics - the idea that it's always a people problem. I was reminded of that sound-byte today while reading Switch - How to change things when change is hard by Chip and Dan Heath. Their surprising-thing-about-change number 1 (of 3) is

What looks like a people problem is often a situation problem.

I prefer this version, partly because it uses the word often rather than always and so it follows Bill Bailey's Law. But mostly I prefer it because saying "it's always a people problem" feels demotivating because we are all people and you get drawn into thinking you're the problem. As Deming made clear, the root cause of most problems is not the people but the system. But the word "situation" is simpler and somehow easier to grasp than "system". It's clear your always in the situation that you're in.

A related quote from Switch is

to change someone's behavior you've got to change their situation.

I like this a lot and it reminds me of the various quotes about acting your way into thinking differently being easier than thinking your way into acting differently...

Sometimes it’s easier to act your self into a new way of thinking, than it is to think your self into a new way of acting. (Jo Berry)

You cannot change how someone thinks, but you can give them a tool, the use of which leads them to think differently. (R. Buckminster Fuller - quoted in The Fifth Discpline by Peter Senge)

Adults are much more likely to act their way into a new way of thinking than to think their way into a new way of acting. (Richard Pascale's in Surfing the Edge of Chaos)

Or, to say it in reverse

Knowledge does not change behavior.

So instead of saying "it's always a people problem" perhaps it is better to say "it's rarely a people problem"

Implementing Lean Software Development

is an excellent book by Mary and Tom Poppendieck. As usual I'm going to quote from a few pages:

If you focus on driving utilization up, things will slow down.

We've watched CMM and ISO 9000 as their focus changed from quality improvement to certification.

Toyota believes that consistent excellence in product development starts with "towering technical competence in all engineers". At Toyota "Developing people is fundamental to the managers job."

If you expect teams to meet aggressive deadlines you must limit work to capacity.

The behaviours that ranking systems encourage are competition, hiding information so as to look good, and hiding problems so as not to look bad.

There is at least as much knowledge created by experiments that fail as is created by finding a solution to the problem.

Western companies think of knowledge as something that is written down. Japanese companies think of written knowledge as only the tip of the iceberg; most knowledge is contained in subjective insights, intuitions, hunches, and mental models. This tacit knowledge does not come from studying, it comes from experience.

Probably the biggest mistake we can make is to regard refactoring as a failure to "Do it right the first time".

The mark of an excellent organization is not that they are without problems; it is that they are without systemic problems.

In The Living Company, Arie de Geus points out that the average life expectancy of a multinational corporation is between 40 and 50 years. People live for an average of 75 years, so they can expect to outlast perhaps three quarters of the companies that existed when they were born.

If the learner hasn't learned the teacher hasn't taught.

The velocity/wip game

While I was at Jerry Weinberg's Problem Solving Leadership workshop last week (which was truly fantastic) I showed a group of fellow attendees a very simple velocity/wip game I've invented. You simply create some cards and arrange them into columns. Each card has a number written on it which is it's estimate. The photo shows the setup for our game; the left column (eg Analysis) contained the numbers 1,8,2; the middle column (eg Design) contained the numbers 1,1,5; the right column (eg Testing) contained the numbers 8,1,2. We put one person on each column; Darrin on analysis, Ted on Design, and Tim on Testing. Play proceeds as follows:

• each player gets N (eg 3) dice which they each roll over and over again
• if a player rolls a 1 they add one to their running tally (which starts at zero)
• if their tally reaches a number on a card in their column they can move that card one column to the right and reduce their tally by that number
• that's it! (you can also add wip limits to the columns if you like)

Paul was on the timer and gave us one minute. After the minute was up we added up the...

• work-in-progress: the total of the cards still in the three columns
• velocity: the total of the cards that got moved out of the rightmost column (into an extra rightmost column called Done)

The first minute

The wip was 25 and the velocity was 11. This makes a total of 36 which is greater than the total we started with. This is because there is also an extra left-most column called Backlog which contains more numbered cards. Darrin was on the left Analysis column and after moving all three of his cards into Ted's middle Design column he pulled some more work into his column from the Backlog. Despite this Ted was starved of work for part of the minute.

The second minute

We reset the board back to it's initial position and decided to try and increase the velocity by smoothing the work. We split the high cards into multiple smaller cards. For example, the 8 was split into 3,3,2. Then we did another minute's worth of work. This time the wip was 18 and the velocity was 18. Once again this makes a total of 36 and once again Darrin pulled in more work from the Backlog after emptying his Analysis column. Because the work was less lumpy Ted wasn't starved and the velocity went up.

The third minute

We reset the board back to it's initial position from the second minute. This time we decided to try and lower the work-in-progress left over at the end. After all, if the project got canceled that wip would be waste. To do this we agreed not to introduce any new work from the backlog, and also that anyone's dice could contribute to the tally on anyone's column. Then we did another minute's worth of work. This time the wip was 9 and the velocity was 20.

Summary

Simply by smoothing the work and working together we increased velocity by a factor of ~2 (11 to 20) and reduced the wip by a factor of ~3 (25 to 9). Simple!

Craig Larman's Scrum Master course

I've just spent a thoroughly enjoyable 2 days attending Craig Larman's 2 day Scrum Master course at the invitation of Olve Maudal. If you're looking for a really superb Scrum Master course I don't think you'll find a better course or a better person to hold it for you than Craig.

The photo is of a game we (team 3) created in one of the many hands on exercises. We called it the Scrum Board Game. I played the role of Product Owner and I learned that I tend to interfere too much. Sorry team 3!

Push-bike pump adapter pattern

Bicycle inner tubes have two kinds of valves; the bronze kind on the left and the silver kind next to it. Rather than supplying each valve with its own flexible tube (to connect to the pump) this one cleverly uses only one - the silver valve also doubles as an adapter for its bronze partner. Neat.

Henrik Kniberg's name game

Update: Henrik has now written a detailed explanation of how he plays the game here.

Henrik designed the name game to show how the lean idea of limiting work in progress can have a dramatic effect. Here's how you play:
Split into groups of six. In each group there are 5 customers and 1 developer. Each customer has a project - they simply want the developer to write down their name. That's it. During both iterations the following times have to be recorded (to the second):

1. the overall start time
2. the time each customer's project starts (when the developer writes down the first letter of their name)
3. the time each customer's project is delivered (when the developer writes down the last letter of their name)
4. the overall finish time

In the first iteration each developer has to act under the principle of "never keep a customer waiting" and tries to write all the names simultaneously. Let's see how a developer's name-sheet changes during this iteration. It starts off empty:

1.        2.        3.        4.        5.

the developer asks their first customer for the first letter of their name and writes it down; the first customer's project has started so they write down their project's start time:

1.B       2.        3.        4.        5.

the developer asks their second customer for the first letter of their name and writes it down; the second customer's project has started so they write down their project's start time:

1.B       2.E       3.        4.        5.

the developer carries on until they have written down the first letter of all their customers names; every customer will have written down their project's start time:

1.B       2.E       3.P       4.T       5.J

the developer asks their first customer for the second letter of their name and writes it down; if this completes the customer's name the customer's project is delivered and the customer writes down their project's finish time (Be will become Bert so not yet):

1.Be      2.E       3.P       4.T       5.J

the developer asks their second customer for the second letter of their name and writes it down; again, if this completes the customer's name the customer writes down their project's finish time (El will become Ellie so not yet):

1.Be      2.El      3.P       4.T       5.J

the developer carries on until they have written down the second letter of every customer; Jo is Jo so Jo's project is delivered and Jo writes down her project's finish time:

1.Be      2.El      3.Pa      4.Te      5.Jo

the developer carries on round-robin, letter by letter, until they have written down the full name of all their customers; every customer now has a project finish time:

1.Bert    2.Ellie   3.Pat     4.Terry   5.Jo

Stop the clock and record the overall finish time.

Now the developers swap customers (so they don't know their customer's names once more).

In the second iteration the developers act under the principle of "limit work in progress to 1 customer at a time". So no multi-tasking. Let's see how a developer's name-sheet changes during this iteration. It starts off empty:

1.        2.        3.        4.        5.

the developer asks their first customer for their whole name and writes it down. When the developer starts writing their name the customer writes down their project's start time, when the developer finishes writing their name the customer writes down their project's finish time.

1.Sally   2.        3.        4.        5.

the developer asks their second customer for their whole name and writes it down. Again, the second customer writes down their project's start and finish time.

1.Sally   2.Russ    3.        4.        5.

the developer continues round-robin asking each customer in turn their full name. All customers now have a project start and finish time.

1.Sally   2.Russ    3.Ed      4.Larry   5.Clive

Henrik writes:

Then we chart the results and compare and discuss. Typically the lead time per customer is at least 5x shorter in the second round, and the total time to do all customers is 3x shorter (so the developer could handle 3x more customers within the same time, and each customer only needs to be engaged in the project for 5x shorter time than before). Most people intuitively believe that, if you start something earlier, you will finish earlier. This exercise brutally murders that misconception :o) A simple exercise, but the effect is astounding.

If you like software-related games you might also like

• Cyber-Dojo
• Kanban 1's Game
• Simplest Name Game

Tandberg product development

My good friend Olve Maudal of Tandberg did a talk about Product Development in TANDBERG for the Oslo Lean Meetup. His slides are online at http://bit.ly/cxNvjc and are well worth a look if you care about what it takes to make world class software.

Showers are lean-agile; baths are not

In the shower a few days ago I realized that showering vs bathing is a nice example of being lean-agile or not. Imagine 10 people bathing sequentially vs showering sequentially...

With a bath you have to wait (in a queue) while the bath fills up. Not so with a shower.

If you do something else while you wait for the bath to fill up you're likely to find the bathwater too hot or too cold.

Or the tap turns itself off (I have a hot tap that does that sometimes) and the bath is still virtually empty.

Or that might be the time you discover the overflow pipe is blocked.

Or that a fully-on tap releases water faster than an overflow pipe can drain it.

With a bath the water stays in the bath and gets dirty.

With a bath the water gets cold as you lie in it.

With a bath you have to drain the water before you can refill it so the next person can bath in clean water.

With a bath you use more water.

A bath takes up more floor space.

In a shower you stand up, you stay more awake.

A bath is less encapsulated.

Bath leaves a ring of scum that has to be cleaned.