|
|
We will organize the second Agile Open conference on 27 and 28 April 2006 in Mechelen, Belgium.
Agile Open is an open space conference about Agile topics. The idea is simple:
- participants can submit ideas for sessions
- at the start fo each day, we perform a quick planning game to select the sessions that will run in the two tracks
To get an idea of the range of session, take a look at the output of last year’s sessions.
Registration is now open! Don’t wait too long to register, as there are only 40 places.
Tags: agile, Agile Open, Open Space
Kevin Rutherford responded to the People vs Process entry and asked the following questions:
- Could it be that Toyota can afford to say “it’s always a process problem” because of the cultural values of their people?
- Does Weinberg’s soundbite sound plausible purely because blame and ego are so deeply ingrained in Western culture?
- Where Hansei is never associated with blaming, can there ever be a “people problem”?
Very good questions. But how do you get and sustain such a blame-free culture? Consistently seeing each problem as “a process problem, not a people problem” is part of that, I think. Of course, there’s a lot more to “The Toyota Way”.
Another example of this approach is Norm Kerth’s Prime directive of retrospectives: “Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.” If we really want to have Hansei in the culture of most of our companies, we must first defuse all the blaming that we’ve come to expect.
The problem for many of us is that failing is generally not an option.
Marc Evers responded to the Lean vs Theory of Constraints entry and asked the following questions:
- If you always optimize everything, don’t you run the risk of optimizing something that will never be used?
- Isn’t the Theory of Constraints something like YAGNI for process optimization?
- If you keep on optimizing bottlenecks, the bottleneck will move. Is this also true when you continuously optimize everything? Is the bottleneck dynamic the same?
The Toyota Way fieldbook says that every improvement opportunity will be used. Even if it concerns a process that will disappear in a few months. Apparently, Toyota feels it more important to keep the Kaizen (“continuous improvement”) spirit alive, than to save some optimization effort. As we’ve seen in the evaporating cloud, having a “Pull” system avoids most of the problems that the Theory of Constraints warns us of.
The X vs Y blog entries seem to generate some interest. Let’s see if I can find (or create) some more conflicts…
Tags: Systems Thinking, Theory of Constraints, Lean, Toyota Way
At the XP.BE user group meeting hosted by ERG Transit Systems, we ran a workshop on “Management metrics”.
The people at ERG wanted to introduce some metrics to get feedback on their process improvement efforts. However, metrics can be dangerous. “You get what you measure”, but what you measure may not be what you intended.
We used a workshop format designed by Jason Gorman and Duncan Pierce to design, break and improve metrics. The session went like this:
- we formed 4 teams
- 3 people from ERG presented 4 requirements for metrics, one for each team. For the rest of the session, they acted as “onsite customer”
- each team designed and presented a metric to satisfy the requirement
- each team received another team’s metric and tried to “game it”, to subvert it to reach the opposite of the desired effect, or to score as high as possible with the least amount of effort. This was the fun part.
- each team then improved their metric, taking into account the possible “misuse”
- our customers performed the acceptance test. Each metric had to pass two tests:
- Would our customers be able and willing to implement this metric tomorrow?
- Would the developers want to work in a team that used this metric?
3 out of the 4 metrics passed the user acceptance tests. The fourth might too, with a bit of work. Not bad for 90 minutes of work!
Some things I learned about metrics:
- No metric is fraud or misuse-proof, therefore people have to want to use the metric correctly. If people want to game the system, they can be very creative.
- Metrics that take a noticeable amount of time and work to collect will not last long
- It’s better to aggregate data, because errors in the individual items tend to cancel each other out. E.g. it’s easier to track the estimates of a whole release, rather than the estimates of each individual feature
- It’s better to look at team results, rather than individuals, because of the aggregating and because that motivates people to work as a team. This is related to the “Reward one level up” rule I first heard from Mary Poppendieck.
I ‘d like to align metrics with the “Throughput Accounting” measures. I’ve added an “Idea for Session” about this topic on the Agile Open site. How about you?
More useful info and books on the wiki.
Jason and Duncan will host this session at SPA2006. Highly recommended!
Update 20/02/2006 Nico Mommaerts has blogged about this event too.
Tags: SPA 2006, Agile Open 2006, metrics, XP
We will organize the second Agile Open conference on 27 and 28 April 2006 in Mechelen, Belgium.
Agile Open is an open space conference about Agile topics. The idea is simple:
- participants can submit ideas for sessions
- at the start fo each day, we perform a quick planning game to select the sessions that will run in the two tracks
To get an idea of the range of session, take a look at the output of last year’s sessions.
Tags: agile, Agile Open, Open Space
Looking for a conflict
Lately, I’ve been studying the “Thinking Processes“. As usually happens when I discover a new solution, I want to apply it to everything. I want to play some more with the “Evaporating Cloud” (see my first attempt), a tool to resolve conflicts. Hmmm… Which conflict can I resolve today?
To optimize non-bottlenecks, or not?
There is a question that’s been puzzling me for a long time: the Theory of Constraints and Lean have conflicting advice about optimization.
The Theory of Constraints tells us that we should only optimize the bottleneck. Because the throughput of the system is constrained by the bottleneck, the only way to improve the performance of the system is to improve the bottleneck. The theory also tells us not to optimize non bottlenecks. In the best case, the optimization won’t improve the system, but it’s probable that this improvement will actually worsen the system’s performance (by increasing work in progress, inventory…). It’s quite easy to see in the “drum-buffer-rope” example.
Lean tells us to mercilessly remove waste and improve every part of the system. Toyota encourages everyone to continuously search for ways to improve ways of working. Even if it’s only a small improvement. Even if that part of the system will replaced in the near future. No improvement opportunity is lost.
This is the dilemma: “Optimize everything” conflicts with “Only optimize the bottleneck”. I like both approaches and have used them both successfully. How is it possible that two of my favourite techniques disagree? Or do they…
The evaporating cloud
Let’s draw an evaporating cloud for this conflict:
Reading the diagram from right to left:
- We don’t optimize non-bottlenecks IN ORDER TO avoid creating waste
- We avoid creating waste IN ORDER TO have an efficient system
- We optimize everything IN ORDER TO remove waste
- We remove waste IN ORDER TO have an efficient system
- Optimize everything CONFLICTS WITH don’t optimize non-bottlenecks
Examining the diagram critically
Let’s apply the legitimate reservations:
- Clearly, “remove waste” and “don’t create waste” contribute to having an “efficient system”
- Evidently, Toyota optimizes everything all the time and their system has very little waste.
- Clearly, optimizing a non-bottleneck has no effect on the system’s throughput and increases work in progress and inventory. If we look at the diagram below, what happens if we optimize Supplier 2 to have a capacity of 12? The system still has a capacity of 8. And we’re now overproducing 4 items, which end up in inventory. Overproduction is the worst kind of waste in the Lean philosophy.
A conflict. Unless…
Optimizing a non-bottleneck results in overproduction. Unless… If we use a “Pull” system, the consumer determines the output rate of the producer. In that case, the optimized Supplier 2 still produces 8 units, but now has 4 units of spare capacity. We could use that capacity to subordinate to the constraint or exploit the constraint. By doing that, we keep inventory low and increase the bottleneck’s (and the system’s) throughput.
Restating the system
In this system we see that optimizing both the bottleneck and the non-bottleneck resources removes waste. BUT: unless we have a “Pull” system, optimizing non-bottlenecks will introduce waste. Therefore, use the ToC approach in a less mature system, with a “Push” scheduling model; use the Lean approach in a system with a “Pull” scheduling model.
I feel a lot better, now that this is settled…
Tags: Systems Thinking, theory of constraints, thinking processes, Toyota Way
|
|
