Thinking for a Change

My second visit to Helsinki. Last year’s Scandinavian Agile was great. This year’s was even better.

What Went Well

• Presenting the Toyota Way with Portia. I presented this session for the first time at XP Days Paris 2006. Since then, it has been changed and refined each time it’s run. Most importantly, it includes the stories and experiences we accumulated by applying these techniques over the past years.
• Meeting the other participants over coffee, lunch and dinner and at the pub.
• Running a “Conflict Resolution Diagram” systems thinking session with some 15 participants. More about the technique later.
• Helping Artem Marchenko to run the Business Value Game. It’s always interesting to see how other presenters run the game and “steal” their good ideas.
• The location: beautiful and cold autumn Helsinki. The conference center was ideal for the first day: two large presentation rooms and  three smaller workshop rooms, connected by a large open space with coffee and cakes.
• Getting tips for more books from Tom Poppendieck after the Toyota Way session.
• Visiting the Reaktor offices, getting a tour (including the “Russian” room) and discussing sauna’s, Steve Jobs’ management style and the difference between being able to do business analysis and teaching others to do it.
• Discussing Business Value modelling at the Open Space.
• The open space session announcements became more and more original and fun as each presenter tried to top the presenter before them.
• The conference went smoothly and everything was well-organised. Great job, conference organisers!

What Went Wrong

• I didn’t know the contents of the sessions. The schedule overview only contains session titles, with no way to click through to a detailed session description. There were no “session adverts” at the start of the conference, where session presenters could tell me why I should go to their session.
• The morning program was too cramped: what looked like two back-to-back 60 mins sessions were actually two 50 mins session with a 10 minute break. I prefer longer breaks. For example: at XP Days Benelux we have 30 minute breaks between sessions.
• Overrunning the timeslot for the Toyota Way session. We stayed in the timebox during rehearsals, so we need to ensure that we can do it live too.
• The Open Space didn’t make very good use of the room space: the working groups were too close to each other, so that it was difficult to understand each other with all the noise around us. All working groups stayed in their appointed place, while there was plenty of good space going unused in the middle of the room. That just shows how little we question arbitrary constraints.
• To avoid the noise and overcrowding problem, we ran the Conflict Resolution Diagram session downstairs in the coffee room. Unfortunately, we weren’t the only ones, so the session was still too noisy and cramped.
• A participant told me he walked out of the Toyota Way presentation shortly after the beginning because it  looked “too basic”.

Puzzles

• Why the need to make “controversial” statements and speeches? It seems to me that the Agile community prefers infighting over advancing the state of the art and delivering value. That is, while there is value in the items on the right, we value the item on the left more. Sectarianism (“Scrum vs Kanban”, “Agile vs Lean”) does not help me do my job.
• Why no Post-Its at the Open Space? How can you expect me to work without Post-Its? 🙂
• Why are so many sessions only about theory, even the one that told us to distrust presenters who present only theory without any concrete examples? Where did you do this? Who were the people who applied this? What were their results?
• What does a maniac with a power drill pointed at me have to do with involving people in Kanban? Karl, your Kanban presentation scared me 😉

Lessons Learned

• If you want to run an effective open space, you need the right kind of space. Ideally, separate spaces or rooms that are sufficiently private to allow for discussion and work AND sufficiently public so that it’s easy to go from one space to the other.
• The Conflict Resolution Diagram technique is very simple. It’s also incredibly difficult because you have to question openly, approach a problem with an open mind, take the time to understand the real problem before prescribing a solution and be willing to surface and question all your assumptions. But the reward is huge: you’re able to transform “either this OR that”, “this VERSUS that” and “this OVER that” statements into “this AND that” statements. We can have our cake AND eat it too, if we choose to live a meaningful life and learn to apply some systems thinking.
• The Toyota Way presentation can become better and can be delivered better. See for yourself at XP Days Benelux 2009.

Takt time

Takt time is the rate at which customers buy a product. Takt time determines the speed at which a Lean manufacturing runs. For example, say we sell 576 units of product A. If we have a 8 hour shift, we need to make 72 units per hour, or 1.2 units per minute. We have 50 seconds per unit.

Every step in the production process must now deliver their contribution to the product in 50 seconds.

What if there’s a step that can’t deliver in 50 seconds? Then we have a bottleneck. We’ll produce and sell less than we could. We apply the 5 focusing steps to increase the bottleneck’s capacity so that they can deliver in 50 seconds or less.

What if there’s a step that can deliver in less than 50 seconds? They still deliver every 50 seconds, even if they have to slow down. If they delivered more frequently, we’d build up lots of work in process as other steps can’t use its output faster than once every 50 seconds. Or we might build unsold goods.

Slowing down? Isn’t that inefficient? Yes, but we’re not optimising the efficiency of a single step. We’re optimising the whole value stream. If a step has a lot of spare capacity, this could be used to work on another product, but only if it doesn’t endanger the delivery of the first product.

Using Visual Management, the value stream tracks actual production rate regularly. The steps won’t run perfectly as clockwork, there will always be some variation. The production rate displays allow everybody to react (speed up, slow down a bit) to keep to the takt time. The takt time works as a metronome that synchronizes musicians.

Takt time isn’t (always) the drum beat

In Theory of Constraints, the Drum-Buffer-Rope system synchronizes the speed at which each step in production runs. The “Drum Beat” is the rhythm, the steady pace at which the slowest step (the bottleneck) runs. The rest of the system works to that beat. Again, no use producing faster than the bottleneck because we’ll only create more work in process.

The two concepts are quite similar and I sometimes confuse them. There’s one clear difference:

• takt time is customer-focused, outward looking
• drum beat is bottleneck focused, inward looking

If the customer is the constraint, a base (if not outspoken) premise of Lean, takt time equals the drum beat and drum-buffer-rope implements customer pull.

Takt time in software development

What is the equivalent of takt time in software development? If you’re Microsoft, you know approximately how many copies of Microsoft Office are bought every day. You could run your disk duplication and packaging plant at this takt time. But that’s not what I want to talk about.

Takt time = the rate at which you release a new product (version) to users

How often do you put new, valuable features in the hands of your users? Every day? Every week? Every month? Every quarter? Every year?

The logic of slow takt times or how to kill all your Agile teams with one simple decision

Most teams I work with, including Agile teams, have long release cycles. Long by my standards. Some of this is under control of the development team, but the release cycle is often dictated by other concerns. Often, operational teams (systems engineers, DBAs, support) reduce the number of releases.

Operational teams are often stressed, in fire-fighting mode and jerked around as projects miss deadlines and make last-minute changes. To reduce the load and ease the pressure, they reduce the number of releases. Fewer releases means more complex and error-prone releases, as more features are batched up in one release. These releases require more effort and have more issues. Fixing and patching those issues requires more work. Business people, under pressure to generate more value faster push harder to get features out of the door. Corners get cut, features get released under the guise of fixes. More work. The logical reaction is to reduce the number of releases again. Which makes the problem even worse. And so on.

Reducing the number of releases, increasing the overhead of releasing is the perfect way to demoralise and ultimately kill any Agile team. Why should we define short iterations and releases, if it takes so long to get something in production? Why should we collaborate tightly with customers if the software is outdated by the time it gets into the hands of users? Why should we focus on business value if potentially valuable features gather dust in an endless release process? We might as well switch to waterfall.

It doesn’t have to be this way. The first step is to regain the trust of the operational teams: release on time, deliver great quality code, involve operational teams in planning and retrospectives, treat members of operational teams (who are often involved in many projects) as members of your team: listen to them and optimise the whole value stream.

Once we’ve established trust and created one team, we can start to talk about improving and going faster.