La deuxième présentation à la Conférence Agile France 2011 proposait six bases essentielles pour mettre en place un environnement de travail Lean ou Agile. Comme toujours il y a de bonnes nouvelles et de mauvaises nouvelles:

• La bonne nouvelle: Lean et Agile ne sont pas de la magie, entre temps on sait pourquoi, où et comment ça marche
• La mauvaise nouvelle: ce n’est pas compliqué, mais c’est vraiment dur de mettre en place les prérequis nécessaires.

La présentation ne donne qu’un aperçu de chaque élément. Voici des ressources pour les 3 premiers élements, qui peuvent vous aider dans vos recherches. Les 3 autres éléments seront décrit dans un billet suivant.

1. La Théorie des Contraintes

Originalement décrite par Eli Goldratt dans le roman “Le But”, cette théorie se résume très facilement:

• Le résultat de chaque système est déterminé ou limité par un de ces élements, le goulot d’étranglement
• La seule façon d’améliorer les résultats est de travailler sur le goulot.
• Améliorer les autres élements du système n’apportera pas de bénéfices, cela aura souvent un effet négatif!

Comme mon grand-père savait déjà: “pour rendre une chaine plus forte, il faut renforcer le maillon le plus faible”.

Le “Jeu du Goulot d’étranglement” vous fait vivre les conséquences qui vont souvent contre le “bon sens”.

2. Les Real Options

Au lieu de prendre des décisions difficiles le plus tôt possible, comme nous encourage toute la littérature sur l’architecture informatique, il faut

• attendre jusqu’au “bon” moment pour prendre chaque décision. On peut calculer exactement quand c’est le bon moment: la date de livraison – le temps d’implémentation de l’option
• jusq’au moment de la décision on garde toutes les options ouvertes
• on utilise le temps gagné pour rechercher plus d’informations ou pour créer d’autres options
• on essaie de réduire le temps d’implémentation de chaque option afin de repousser vers l’arrière le moment de la decision

L’heuristique que j’utilise:

• Une décision difficile à défaire doit être prise tard. J’essaie de réduire le temps d’implémentation pour avoir plus de temps de reflexion et évaluation.
• Une décision facile à défaire peut être prise tôt. J’essaie de convertir des décisions difficiles à défaire en décisions faciles à défaire.

Exemples concrets:

• Les User Stories nous donnent l’option de prendre des décisions difficiles de planning et contenu du produit plus tard que d’habitude
• Du code clair, facile à comprendre, bien factorisé avec des tests automatiques nous permet de défaire des décisions de design et architecture à faible coût qu’on a fait auparavant pour implementer de nouveaux besoins
• Le tableau Kanban permet à l’équipe de voir les goulots en temps réel et de réagir en conséquent.

L’article “Real Options Underlie Agile Practices” par Chris Matts (en anglais) explique les Real Options et le lien avec Agile et lean. Il y a un résumé des Real Options sur le site Agile Coach.

3. Gérer par la valeur, pas par les coûts

Au départ de nos projets on se met d’abord d’accord sur notre définition commune de “valeur”. Don Reinertsen appelle cela un “Project Economic Framework” dans The Principles of Product Development Flow: Second Generation Lean Product Development. Nous appellons cela un “Business Value Model” ou “Modèle de la Valeur Métier”.

Bien définir la Valeur avec toute l’équipe apporte beaucoup de bénéfices:

• Toute l’équipe est alignée
• Comme nous comprenons mieux le vrai but, il est plus facile de trouver des vraies solutions
• Il est très facile de prioriser
• Les projets deviennent plus petits parce qu’on élimine ce qui n’ajoute pas ou pas assez de valeur

La présentation

La semaine passée j’ai présenté comment résoudre les conflits avec le “Diagramme de Résolution des Conflits” à la Conférence Agile Paris. La présentation est disponible ci-dessous. Plus d’informations sont disponibles sur le site Agile Coach.

A la fin de la présentation il y a deux questions pour voir si vous avez compris la leçon:

1. Est-ce qu’il est possible de former un gouvernement belge avec cet outil? Si oui, pourquoi? Si non, pourquoi pas?
2. Est-ce que vous pouvez résoudre ce conflit récurrent entre Product Manager et Développeurs:
   • Le Product Manager a besoin d’estimations et de planning très détaillé et fiable pour publier une roadmap qui dit quand quel fonctionnalité sera livrée quand ET livrer ces fonctionnalités comme promis
   • Les clients, qui souvent sont des grandes entreprises avec plusieures filiales dans les monde et beaucoup d’utilisateurs, ont besoin de cette roadmap pour planifier quand ils vont implémenter une nouvelle version
   • Les Développeurs sont “passés au Kanban”: ils ont arrêté de faire des estimations ou des plans. Cela prenait beaucoup de temps et ce n’était jamais correct.
   • Les Développeurs “éliminent le gachis” parce qu’ils doivent aller de plus en plus vite pour satisfaire les requêtes d’un nombre de clients qui toujours croissant.
   • Tout le monde veut livrer les fonctionnalités au client au moment où les clients attendent ces fonctionnalités.

Vos réponses et questions dans les commentaires…

D’abord essayez de clarifier le conflit.

Puis, découvrez les suppositions derrière chaque étape du raisonnement.

Translation

I presented an interactive tutorial on how to apply the “Conflict Resolution Diagram” at the French Agile conference in Paris. You can see the English version of the presentation at the Agile Coach site.

At the end of the French version of the presentation there are two tests to see if participants understood the tool:

1. Can you use this tool to form a Belgian Governement. If yes, why? If not, why not?
2. Can you resolve this common conflict between Product Manager and Developers:
   • The Product Manager needs detailed estimates and accurate planning because she has to create a long-term roadmap which spells out which features will be delivered when AND deliver those features when promised to keep customers’ trust
   • Customers, who are typically large multi-site companies with many users of the product, need the roadmap because they need to plan when they will roll out which version throughout the enterprise
   • Developers have “gone Kanban” and have stopped estimating and planning because the estimates took too much time and were incorrect anyway
   • Developers stopped estimating and planning to decrease waste so that they can keep up with the increased demand for features from the increasing user base
   • The whole company wants to deliver the features customers ask for when customers expect them.

Answers on a postcard or a comment…

First, try to clarify the conflict.

Then try to find the assumptions behind each step of the reasoning.

The “Bottleneck Game” is a simple game that illustrates many Agile, Lean and Theory of Constraints topics. It’s available for free with a Creative Commons license so that everybody can play it. And people do play it all over the world. For example:

• Thierry Cros played the game in Morocco.
• Kevin Rutherford played the game in Manchester.

Great productivity improvements for both teams! But we all know software development isn’t manufacturing, right?

Try the game. Try some of the ideas. Just like in the game, your team can create more value with less effort and a lot less stress.

XP Day session tryout: Agreeing on Business Value with Systems Thinking

Cap Gemini will host the next Agile/XP Belgium usergroup meeting. This session is a tryout for XP Days Benelux.

We talk a lot about “maximizing business value”. We ask business people and product managers to prioritise by estimating the business value of user stories. But what exactly do we mean by business value?

Over the past few years we’ve worked with many teams to define their “Business Value Model”, a clear definition of the value a project will bring to the organisation. The exercise hasn’t always been easy but it has always brought significant benefits:

• Measurable business value in units that impact the organization (such as revenue €€€, customer satisfaction, staff retention)
• Everybody involved was more motivated because there was a clear reason for the project and they finally understood what it was
• The whole team was aligned around one vision because we had clear criteria to define success
• We came up with more innovative solutions because everybody on the team, not only “the business” or “product managers/owners” could take product-related decisions based on the model
• We could deliver a lot faster than anybody expected because the Business Value Model allowed us to easily distinguish between value-adding and non-value-adding features
• We spent a lot less time writing and prioritising user stories because we were able to derive the user stories from the value definitions
• The Business Value Model guided us to explore new product ideas: the business value model was a hypothesis that we could test and refine each time we released or performed user testing.

In this interactive tutorial you’ll apply some Systems Thinking techniques, such as the Diagram of Effects and Intermediate Objectives Map) to define the business value model of an example project. We’ll show you the techniques we used and discuss how you can apply those techniques in you context so that you’ll be ready to start building a business value model with your team.

Agenda:

• 18:00 – 19:00 – Welcome with snacks and drinks
• 19:00 – 21:00 – Session

Address: Bessenveldstraat 19, B-1831 Diegem, Belgium

Register here for this free event

Last Thursday and Friday I participated in the Lean and Kanban Belgium 2010 conference. I was scheduled to present a session on Friday morning, so I could go to many sessions on Thursday.

Every session that I attended on Thursday said many things I wanted to say:

• Sandrine Olivencia talked about challenging the team for continuous improvement
• Dave Nicolette talked about the dysfunctions around budgeting and the need for IT to integrate, not align, with the value stream
• Anthony Marcano and Andy Palmer explained how analysis can be implemented as a pull system
• Ryan Shriver essentially said all I wanted to say about finding the real goals of our users and quantifying their needs
• John Seddon told tales about really understanding value demand and taking a systems thinking approach to the design of work in his usual, inimitable style

What was left to say? At the end of the day I could scrap about 3/4 of my talk. The good news is that many people are independently reporting that these techniques and approaches work. And they can show results.

In the end, there was more than enough to fill an hour. After the presentation several people asked questions and discussed what I presented.

p.s. I followed Dave Nicolette‘s advice to grow a profitable consultancy: coin a new acronym. I give you “IDD”. You’ll have to watch the presentation to know what it means. And you’ll have to pay me big bucks to come implement it in your organisation

Portia and I presented a tutorial on how to use the “Conflict Resolution Diagram” systems thinking tool at the Mini SPA conference in London on September 10th 2010.

The slides of the presentation and summaries of the systems thinking tools are available on the agilecoach site.

Let us know if these tools gave you ideas to resolve some conflicts in your life.

Portia and I have been invited to re-run the “Solve Conflicts without Compromise” session from SPA 2010 at Mini SPA 2010 on Friday September 10th. In the SPA session, participants used the Conflict Resolution Diagram to explore four real-world conflicts brought by the participants. I really liked doing the session, because the participants could really try out the tool and four participants got some ideas to solve some important conflict in their work and life.

Two features of the session were crucial to its success: we had plenty of time (3 hours) and a limited number of participants (20). Neither of those conditions will be true at Mini SPA. Therefore, we’ve had to apply some systems thinking tools to ensure that the session still delivers the benefits.

Check out the programme of Mini SPA: it features 6 of the most liked sessions of the SPA conference in two tracks. The conference is free, but you need to register. Don’t wait too long, places are limited.

See you in London!

Portia Tung and I will co-present “Solve Conflicts Without Compromise with the Conflict Resolution Diagram” at the SPA 2010 conference in London on May 19th 2010.

Come and play with us to sharpen your problem-solving skills and come up with real solutions to a difficult choice you’re facing.

The Systems Thinking materials for this session are available on the Agile Coach site.

This year, I participated in two stops of the Agile Tour in France: Besançon and Lille.

In Besançon I presented the “Résoudre les Conflits sans Compromis“. In Lille I presented the “A l’aide! Mon processus m’étrangle“. The participants of the Conflict Resolution in Besançon did a session retrospective.

This is my conference retrospective

What Went Well

• Both conferences were relatively small (fewer than 100 participants) with three tracks, so that it was possible to meet many of the participants and the audience sizes weren’t too large.
• A mixture of foreign and local presenters. Although, in Lille the presenter from Toulouse was more foreign than the one from Belgium
• Participants to both workshops happily played along and told me they had learned some useful techniques.
• Going to lunch and dinner with local agilistas and hearing about their challenges and successes.
• I’ll be back soon in Besançon.
• I hope I’ll be back soon in Lille, and this time not just as a train stop between London and Brussels.
• Participating in Christophe Thibaut’s well-rehearsed and interactive Haskell kata and going off the cliff with him as we “implemented just one more small feature” because we took too big a step and failed to really let the tests drive the code.
• Participating in Olivier Albiez and André Dhondt’s Pomodoro simulation.
• 15 participants for the Conflict Resolution session.
• 8 participants for the Theory of Constraints session is just enough to run the simulation.

What Went Wrong

• My French could be better. It’s sometimes hard to switch between Dutch, English and French from one day to the next. “Today is Friday, this must be France.”
• Not being able to talk with all the participants I wanted to talk with.
• Only 8 participants for the Bottleneck session.
• Forgot to bring Belgian Chocolate to Besançon, so got lots of “What Went Wrong” feedback.
• My eyes hurt during the Haskell kata session in Lille, probably because of the lighting in the low-ceilinged meeting room.

Puzzles

• What’s the real state of agility in France? It seems that there’s less uptake than in the “Anglo-Saxon-oriented” countries (UK, the Flemish part of Belgium, Netherlands, Scandinavia, Finland). Why? Is the language a factor?
• Where are the French-speaking Belgian Agilists hiding? I know only three, but there must be more.

Lessons Learnt

• It’s not an Agile Coach session if it doesn’t contain chocolates and sweets.
• The “Resolve Conflicts without Compromise” session works in French too. That means I’ll have to translate the materials in French.

Merci aux organisateurs, orateurs et participants. Et, qui sait, à l’année prochaine?

When presenters propose sessions for XP Days Benelux, we always recommend they try out their session, as many times as possible. We should all know the power of iteration and feedback. You need some time to get it right. If you’re slow like me, you might need years to get it right.

The first tryout of the “Solve Conflicts without Compromise” session was run as a “Birds of a Feather” session several years ago at the SPA conference. The session (and the technique) worked, but only barely. Then, two breakthroughs happened at the same time:

• I attended Christoph Steindl and Christian Federspiel‘s Conflict Resolution session at Agile 2008 in Toronto
• I read Bill Dettmer’s “The Logical Thinking Process“

Suddenly, the technique became a lot clearer. Bill Dettmer’s explanation is very clear and practical; the session at Agile 2008 showed that it worked and could be fun.

Solve Conflicts without Compromise

So, after a few more iterations, an updated session was created. It’s now been run twice:

• At  Agile Tour Besançon, in French. The participants gave a lot of useful feedback at the retrospective.
• At the Scandinavian Agile open space, in English. The pictures show the three groups analysing a conflict for their “customers”. There was no time for a retrospective, because the conference was closing. I hope the three clients will blog or email me about their experience.

The next two runs will be at the Belgium Agile/XP User Group meeting on November 5th 2009 and at the XP Days Benelux conference on November 24th.

So, what are the 7 steps?

1. Create a blank Conflict Resolution Diagram (CRD) like in the image below. 5 boxes connected with arrows. Easy.
2. Articulate the conflict. State the problem in one of two forms, both impossible choices between conflicting prerequisites:
   • One chain of reasoning says “DO THIS”; another chain of reasoning says “DON’T DO THIS”. Now I have to choose: DO THIS OR DON’T DO THIS? I can’t have both.
   • I need two things, A and B, but they’re mutually exclusive. Now I have to choose: HAVE A OR HAVE B? I can’t have both.
3. Determine the goal and requirements on each side? Why do we need those two conflicting things? Because of two requirements. Why do we need those two requirements? Because we need them to reach a common goal.
4. Evaluate the reasoning. Throughout the whole exercise we must ensure we maintain clarity: is each step in the reasoning crystal clear and well-understood by everyone? Is the reasoning clear?
5. Develop underlying assumptions. If the CRD says “To achieve X we need Y”, ask “Why do we need Y to achieve X?”. All the answers are the underlying assumptions of the reasoning. Use “extreme wording” to make the assumptions stand out and almost beg to be invalidated. For example: “Why do we need to introduce Test Driven Development to achieve better quality?” Because…
   1. TDD is the only way to improve quality
   2. TDD is the most fun way to develop software
   3. TDD catches all errors
6. Evaluate the assumptions. Which assumptions are valid? Which assumptions are invalid? Which assumptions could be challenged. If there are no valid assumptions behind a step in the reasoning, the reasoning is invalid. At this point, the whole conflict may have “evaporated”.
7. Hard: Create injections. This is the creative bit where we find ideas to invalidate those assumptions that hold us back from creating a win-win situation, one where we achieve our goal in a way that satisfies everyone involved.

Why is this difficult?

When I see the participants in action, there are some difficulties that appear every time:

• It’s hard to maintain the consultant’s stance and only ask questions. That’s why we have strict rules about what the consultants can do: they can only ask a limited set of questions.
• We want to jump to the solution immediately without taking the time to understand the real problem. That’s why the session doesn’t allow talking about solutions, only about problems.
• We censor our assumptions. Instead of brainstorming all our assumptions, we only talk about those that seem reasonable. That’s why there’s a lot of pressure in the session: you have to come up with at least 25 assumptions in 5 minutes. That’s just not possible if you think about the assumptions.
• The most interesting assumptions are those that we no longer think about, the things that are “common sense”. That’s why we have people external to the problem questioning the client and why we bring in some “fresh blood” with a fresh perspective halfway through the session.
• It hurts when we really think about a problem. It’s easier to just settle for a compromise. That’s why we can’t accept any solution where one of the involved parties is not completely satisfied with the outcome.

What’s in it for me?

• The CRD provides a structured method to investigate a difficult conflict and channel our creativity.
• You don’t have to settle for compromise and mediocrity. You can get what you really need.
• It’s a lot easier to bring about changes if everyone affected benefits. As Machiavelli noted: “You will only get lukewarm support from those who will benefit from the change and strong resistance from those who stand to lose”. What if there were no losers?
• Your projects can deliver more business value per cost if you can find the breakthrough ideas that make those painful tradeoffs (or more correctly: horse trading) between stakeholder goals unnecessary?
• You can get more sales if your competitors offer “EITHER/OR” solutions and you can offer “AND” solutions. But first the customer has to regain hope that a solution is possible. Going through a CRD exercise with a customer and offering to invalidate all the assumptions that cause their conflict is an offer they can’t refuse.

What do I need?

• A bit of time. Most participants got several ideas to resolve their conflict within the 90 minutes of the session.
• Some simple materials: pen, paper and plenty of Post-Its
• The willingness to think hard
• The openness to share all assumptions
• The courage to challenge every assumption, even those that are “holy” or common sense. Especially those.

It’s simple, but not easy. The question is: do you want an easy life or a meaningful life? That’s the choice you have to make.

Oh! “Easy OR meaningful”? That sounds like a conflict! Why can’t I have both?

How would you evaporate this conflict?

Bring a conflict to the session and come out of the session with several ideas to turn this conflict into a win-win situation. If you don’t have any conflicts, you can learn how to help others solve their conflicts as a Systems Thinking consultant.

Come and play to discover the Theory of Constraints and the “Five Focusing Steps” to really improve processes. Experience how and why Agile, Lean and Real Options work.

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.

One of the great ideas Agile has incorporated from Lean is the use of Visual Control.

• Release burndown charts tell me if we’re going to deliver on our promises. If we’re significantly behind the plan, we can take action: update the plan or take action to come back to plan. If we’re significantly ahead of plan we can update the plan, by adding more value to the release or by releasing earlier.
• Kanban boards tell me what’s happening with each of the stories in the iteration. If there are too many stories in any column that might be a sign of a bottleneck ahead or we might be starting too many stories. If there aren’t enough stories in a column that might indicate a bottleneck in front or we might not be focusing on the right type of work.
• Different type of items tell me at a glance what’s happening. If there are many red issue/impediment/bug cards on the board, they’ll stand out like a sore thumb. We can “stop the line” and investigate why there are so many blockers.
• Different card colours for different types of features or customers might tell us if our feature mix is good. In one case, a lot of different colours might indicate that we’re not focused. In another case, too many cards of the same colour might mean we’re not giving enough attention to other types of customers.

It’s always fun to walk into a team space, look at the visualisations and ask questions. The most important question is “WHY?” Why do you update this graph? Why do you track these cards? Why is that column there? Why do you put red Post-it’s in that box? Why is there a green dot on this card? “Because the coach or the book told us to do it” is not an acceptable answer.

Why do you visualise these things?

The goal is to take action

This picture shows about half of the information that this team visualises. This team knows what each of the columns means and what it means to move a story or task to another column. They know what to do when one of the columns gets too full. They know what to do when columns are empty. They know that red Post-its are dealt with differently than yellow Post-its. They know who should deal with impediments and questions (the red Post-its on the left) in each of the three impediment boxes (technical issues, business/feature issues, project issues).

They know that a story or task needs to be peer-reviewed before it can move in the “To Validate” column. If the review isn’t satisfactory, the card moves back to the “To Do” column. They know that the stakeholders in the context diagram need to be notified and consulted when something happens to the processes they participate in.

• A visualisation provides the up-to-date information to trigger actions
• These actions are defined upfront
• The whole team knows and agrees with the actions

A visualisation without actions is just a pretty picture.

Stop visualising if you can’t or won’t take action

I walked into a team room and saw that there were five burndown charts, one for each project the team was working on. One of the burndowns indicated that, if things continued to go as they had, this project was going to be released as planned. The four other burndowns indicated that these projects wouldn’t deliver as planned: the rate of descent was too low or they had levelled off (or ‘flatlined’): no progress was being made. I asked the team what they were going to do about those four projects.

Team: What do you mean?
Coach: Well, are you going to inform the customers or account managers of those four projects to tell them their project won’t be delivered as planned? Are you going to negotiate a new release date? Are you going to re-negotiate the scope of these projects if they have a fixed deadline? Can you drop or put some of these projects on hold so that you can stop context-switching and focus on one or a few projects? Are you going to look at the reasons for not delivering as planned? Are you going to see why you accepted more work than you could deliver?
Team: No. We’ll just continue working on the one big, important project and we’ll see what happens with the four others.
Coach: Then I’d advise you to stop updating those burndown charts, you’re just wasting time. You could even stop estimating those projects, because they seem to be of the “it’ll be ready when it’s ready” type.

If you’re not going to do anything with the information provided by your visualisation you might as well stop updating those visualisations.You’re just wasting your time. You’re obscuring the information that is used to trigger action.

If you’ve created a visualisation to take action to solve a problem and to verify if the problem is solved, you might take the visualisation down once the problem is completely solved. For example, you need to visualise the state and performance of a bottleneck while you’re dealing with it. Once the performance of the bottleneck has improved so much that the constraint moves somewhere else, you can stop monitoring. You now need to find a way to visualise the new bottleneck.

You need to refactor your visualisations. That’s why I like low-fidelity and easy to change visualisations. I think Xavier’s kanban boards are beautiful, clear and neat, but I prefer to use a whiteboard as a kanban board, so that we can quickly erase and redraw columns, rows and boxes. And I prefer to put up (story) cards with magnets, rather than stick up task Post-its.

Visualise to show the need for action

A manager came up to me with a worried look on his face.

Manager: That chart over there, is that project XYZ release 6.3?
Coach: Yes, that’s the burndown chart for project XYZ release 6.3.
Manager: Why hasn’t there been any progress in the past three iterations? This way we’re never going to be able to release by the end of the year!
Coach: The team has been waiting for a decision from you. They can’t mark any story as DONE until the acceptance criteria are agreed upon. Your decision affects about three quarters of all stories in this release. The team has tried to raise this impediment with you several times. See that red card on the board there? The lack of that decision is now the #1 risk for the project.
Manager: Oh.

That same day the decision was taken.

Making the consequences of inaction visible can be a way to try and trigger some action, when everything else has been tried.

This is not information for the team, so it shouldn’t be in the team space. It should be where the people who need to take action, are. Some companies put their build status up on a monitor at the entrance where all employees and visitors see it. In this case, the burndown chart was in the corridor that led up to the executives’ offices. A coffee corner can also be a very effective information radiator.

This small internal IT team implemented small projects for about ten internal customers. The internal customers didn’t set overall priorities, they all thought their project had the highest priority. In some companies the customer who shouts loudest gets highest priority. In this company, the customer who shouted most recently got highest priority. As a result, the team trashed: frequent context-switches and priority changes made it impossible to get things done.

During one lunch break a team member bought some packs of multi-coloured index cards and magnets. The team wrote the customer requests on the cards and affixed them to the side of a big iron cupboard next to the coffee machine. Each customer got different coloured cards. The cards were ordered top to bottom in the order in which they had been received.

As the customers got their coffee, they asked about the colourful display. The team explained that this was all the work they had to do, displayed in the order in which they would do it.

Customer: Wow, that’s a lot of work! So, where are my projects?
Team: There, do you see that green card? And there, near the bottom, is another one.
Customer: But that project is very urgent!
Team: Then you’ll have to talk to the customers of the projects above yours.

For the first time, these customers saw why their “simple projects” took several months to deliver: they weren’t the only customer of the team. For the first time they realised that they would have to talk to the other customers to set priorities, because “if you let those programmers set priorities there was no knowing when your project would be ready”.

It’s not a very effective way of triggering actions: you’re essentially “sending signals” in the hope that someone will pick them up. But sometimes it’s your last hope. You can only try this fo a short while: teams won’t keep updating the visualisation if there’s no reaction.

What can I do?

Have a look at all the visualisations your team uses.

If your team has none, ask yourself:

• What is the one piece of information I would absolutely need to see to do my job well? Of what upcoming problem(s) do I need to be aware?
• How could you visualise this information by spending no more than five minutes per day and using nothing more complicated than paper, pens, Post-its, magnets, pieces of string and a whiteboard?
• What different actions can you take based on that visualisation? How do you know things are going well? What kinds of problems can you see? What action will you take for each kind of problem?

If your team has visualisations, ask yourself:

• What is the one visualisation I wouldn’t want to miss? Why?
• For each of the elements (each row, column, box, card colour, writing on the card, number of cards in a box/row/column…): what action do I intend to take based on it?
• Is there any way to simplify this? If there are elements that don’t lead to an action, could I take them away?

Now have this same conversation with your team and refactor your visualisations.

The laws of Visual Management

Just make sure that you obey the two laws of Visual Management:

Before you can take action you must make the problems and goals visible.

If you make something visible you must be prepared to take action based upon the information shown.

Where do you start?

I don’t know about your situation, but I’d start by defining the goal of your team and finding the bottleneck.

Solve conflicts without compromise

I’ll be hosting the “Solve conflicts without compromise” session at Agile Tour Besançon on October 6th, 2009. The session will be in French, so it’s called “Résolution des Conflits”.

In this tutorial participants learn to apply the “Evaporating Cloud” or “Conflict Resolution Diagram” on conflicts they bring to the session. We’re not going to bring about world peace or solve hunger. Not in 90 minutes, anyway. As it’s an Agile conference, the conflicts will be about bringing about change in teams and companies.

This session will also be run at XP Days Benelux on November 23-24. More about that later.

If people are interested, I can run this session at the Open Space of Scandinavian Agile on November 16th.

If you want to know more about the Theory of Constraints’ “Thinking Processes”, have a look at these books. I recommend “The Logical Thinking Process” by William H. Dettmer. It’s not a thin or light book, but the techniques are clearly explained and demonstrated.

Or you could come to one these sessions and solve a conflict.

Next week Portia and I will present two sessions at Agile 2009 in Chicago. And we’ll be attending lots of other agile sessions, if we manage to choose from the massive program.

Besides that I hope to meet agilists from all over the world, see a bit of Chicago and finally see Edward Hopper‘s “Nighthawks“. Incidentally, I discovered Nighthawks after listening to Tom Waits’ “Nighthawks at the Diner“. I wanted to find out more about the inspiration for the album. Tom’s diner is warm and cosy, filled with misfits with tall tales; Hopper’s diner feels as cold as outside and is  filled with people who don’t have anything more to say or a place they want to go to.

Both Hopper and Waits are worth checking out if you want to know more about Americana.

I’m not a Bottleneck! I’m a Free Man!

In this game we apply theTheory of Constraints’ “Five Focusing Steps” to improve a simple simulation process. Step by step, we apply Agile, Lean and Real Options techniques to improve the work and its results.

Portia describes some Bottleneck Games we played recently. The techniques we present are really simple and broadly applicable, not just in manufacturing, where the techniques were developed, or in IT organisations, where we apply them most of the time.

After this session you can use the game materials to teach these concepts in your company. After this session you will be able to apply the techniques in your company. After the session, you will see bottlenecks and opportunities for improvement everywhere. You will look at the world differently.

The number of participants is limited to 60, so come to the session on Wednesday 26th of August at 9:00 sharp.

The Business Value Game

The Business Value Game pits 6 teams against each other to achieve the highest possible income by planning effectively. Each team has a limited development capacity and several customers who want their project implemented NOW. By creating a “Business Value Model”, an agreement on the way to value projects, teams can optimise their income without much time. Portfolio and program management doesn’t have to be complex if you’re value-driven.

After this session you can use the game materials to teach these concepts in your company. After this session you will be able to apply the techniques in your company. After this session, you will look at “business value” and project prioritisation differently.

The number of participants is limited to about 50, so come to the session on Wednesday 26th of August at 16:00 sharp.

Ask for help: will you help lead the Business Value Game?

The teams in the game need coaching from someone who’s familiar with the game and its concepts. If you’ve led or played the Business Value Game before and want to help us run the game, contact us.

See you in Chicago!

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.

Operational Excellence AND Customer Intimacy, but not at once

In the previous blog entry, we saw how one company resolved the conflict between operational excellence and customer intimacy. They found a way to have both. But we didn’t implement both at the same time.

We first went for Operational Excellence. First we standardised, made things reliable, made work repeatable, not only in production but also in IT. The existing product definitions were inconsistent and complex. This made our code complex because we had to treat every product as a special case. Over a period of about one year all the product definitions and the code were refactored to new standardised forms. All of this happened while the system was in production and new features were released every two months. We got very good at refactoring and migrating without disrupting because we did it so often, in small steps.

A similar ‘refactoring’ happened on the production floor. Product line by product line was tackled: work cells clearly labeled, clear flow lines from input to output established, work in process limited… When I first went to see the production floor I nearly got lost between the piles of work in process and it was hard to see what was going on. After the changes, the area looked a lot more spacious and it was clear at a glance what was going on.

Once we had the production and development system under control, we started to think about customisation and getting more intimate with our customers.

Effectiveness AND Alignment, but not at once

This reminded of Alan Kelly’s blog entry about the “Alignment Trap“. In summary: we want our IT organisations to be effective (do things right) and aligned with business objectives (do the right things). Unfortunately, most organisations do neither.

If we want an organisation that does the right things and does them right, what strategy should we follow? Based on a study, Alan conjectures that it’s best to focus on effectiveness first, alignment second. First learn to do things right, then do the right things.

Managed and Agile, but not at once

I encounter a similar situation in many coaching and consulting engagements. Organisations want IT teams that are reliable, predictable and can be trusted to deliver as promised. And they also want them to be agile, deliver faster and respond to change. Lean and Agile can get you there.

What’s the first step? Usually, we need to bring things under control, clear away the clutter, reduce chaos, limit task switching, limit work in process and make things visible. This often involves “anti-agile” or “anti-lean” measures such as batching support, analysis and design work to avoid task switching and installing strict change management and issue prioritising to keep focus. I always get lots of complaints and get accused of “not being agile” from people who are used to the chaos and suddenly find that the team no longer asks “How High?” when they yell “JUMP!” Those who stop jumping find that they get a lot more done and that the results are better. They are less stressed.

Once we have the process under control, we can start improving the flow.We know how to do things, we can start to go a bit faster, in smaller steps; we can disrupt the stability to improve a bit. And then we find a new stability and so on.

Heijunka

Heijunka is one of the often forgotten Toyota Way principles. It means “levelling the load”, working at a steady, regular, sustained and sustainable pace. It means planning the work so that there’s a good balance between flow and the load on people and machines.

Large companies who impose just-in-time deliveries to their suppliers without levelling their orders abuse their suppliers. Teams who randomly request clarifications for stories burn out their Product Owner. Teams who push out releases faster than their customers and users can accept them throw away value.

Heijunka means making and keeping work humane.

Which small step can you take to make your work more humane?

One of the Toyota Way principles is « Nemawashi », take decisions by consensus.

Building consensus is a slow process, but it’s necessary to get everybody on board before taking a decision. Otherwise, the implementation will be delayed and (unconsciously) sabotaged by those who didn’t agree or weren’t involved.

It’s not just about building support for your ideas. The consensus-building process solicits ideas and review from everyone involved so that the final idea is usually a lot stronger than the original.

But there’s one big misunderstanding about consensus.

Consensus doesn’t require Compromise

It’s tempting to dilute our idea to reach consensus, ensure that everyone gets a bit of what they want, so that they’ll agree to go along.

It doesn’t have to be this way. In “Extreme Toyota” the authors show how Toyota embraces conflicts and doesn’t settle for compromises. They identify six contradictions that are central to Toyota’s way of working:

• Moving gradually and taking big leaps
• Cultivating frugality while spending huge sums
• Operating efficiently as well as redundantly
• Cultivating stability and a paranoid mindset
• Respecting bureaucratic hierarchy and allowing freedom to dissent
• Maintaining simplified and complex communication

“This AND that” sounds better than “This OVER that”… I want to have my cake and eat it too

Enter the business consultants

A few years ago I worked on a project that automated the whole value stream of a business unit. The main challenge was that the different departments had conflicting needs. No surprise there.

One of the conflicts was between the production department that did the work on customer demand and the sales department that sold contracts for doing the work to the customer . The production department needed standardised products with little variation so that they could work efficiently, predictably and hit their Service Level Agreements; the sales team needed customised products so that they could tailor their offering precisely to what the customer needed.

This is a classical conflict. The business consultants on the project called this “Operational Excellence” versus “Customer Intimacy“. And the consultants said we had to choose. It’s one or the other, you can’t have both. It’s like Henry Ford’s saying: “You can have any color car, as long as that color is black.”

Examining the conflict

It’s clear, you can’t have both standardised and customised at the same time. There’s a clear conflict. But we have a tool to deal with conflicts: the Conflict Resolution Diagram. Let’s apply the tool:

The diagram says:

• To have a growing, profitable business unit (A) we need to sell what the customer needs (C) and deliver it reliably and cheaply (B).
• To produce reliably, predictably at low cost and to hit the Service Level Agreements (B) we need products with little variety (D).
• To create an offer that responds to the customer’s need and to grow our market (C) we need to vary our products per customer (D’).
• Conflict: we can’t have little variation (D) and a lot of variation (D’) at the same time, but we need both.

Questioning assumptions

We deal with the conflict by questioning the underlying assumptions. Can we find fault with our logic? Bill Dettmer recommends to restate the relationships in “extreme wording”. For example:

• There’s absolutely no way to have both low and high variability at the same time! Well, duh!
• The only way to be profitable and reliable is to have low variability! Well, it was hard to fault this reasoning as this company operated on large volumes with low margins and tight competition.
• Customers always need special cases! Not always, but customers were no longer satisfied with one-size-fits-all offers. If this company couldn’t offer customised products, the competitors would be more than willing to get a new customer.
• We could have low variability and yet vary per customer if only we didn’t have so many customers! Going niche wasn’t an option for economical and legal reasons.

We looked at it every way possible and couldn’t find a fault with the reasoning until…

Finally, some clarity

The Logical Thinking Processes have a set of “Legitimate Reservations”, a set of critical questions we should ask. The first one is simply called “Clarity“: is the meaning of every word and sentence clear to everybody?

Now, we had already noticed that the different departments seemed to have different definitions for the same word. There were even differences in the way they described the different products to us. Were we talking about the same thing?

The breakthrough came when we asked “What do you mean by ‘Product’?” A product for the Production department wasn’t the same thing as a product for the Sales department. And the accounting & finance department had another definition of product. But… That’s not a bug; it’s a feature: if a Production-Product is different from a Sales-Product, can we have Production-Products with low variation and Sales-Products with high variation?

After a lot more work we came up with a way to standardise Production-Products on a small set of “building blocks” and let Sales create Sales-Products by mixing and matching the building blocks according to customer need. Then we mapped Production-Products onto Accounting-Products. And everybody got what they wanted: Operational Excellence AND Customer Intimacy.

Embrace conflict

We didn’t settle for a compromise, but spent the time to really think through our conflicts and come up with a solution that satisfied all needs. A conflict can be an opportunity to come up with an innovative solution.

You don’t have to settle for compromises if you think about it.

When we first start to improve processes, the situation is daunting: we can see so much that can be improved. Where do we start? What will have the biggest effect? And when we’ve done that, what do we do next?

The “Theory of Constraints” gives us a simple and powerful framework to guide our process improvement: “The Five Focusing Steps”.

Step 0: What is the goal?

The first and most difficult step is to determine (and agree on) the goal of the “System”.

Before we can do that we must determine what the System is. As a rule of thumb the System equals the “Sphere of Influence” of our Client: everything that our Client has the authority change.

To determine the goal of the System, we must ask ourselves “Who uses the results the output of the System and what do they value?”. We try to find metrics that measure the amount of valuable output we produce. The Theory of Constraints calls this the “Throughput” of the System.

On the “B” project, our goal was to release valuable features that were actively used by our users. Our measurement was the “Business Value” estimate that our onsite customer put on each User Story.

What is your system? What is its goal?

Step 1: Where is the bottleneck?

The fundamental insight of the Theory of Constraints is this: “the output of any system is determined by one bottleneck.” A chain is as strong as its weakest link. If we want to make the chain stronger, we need to work on the weakest link.

At the start of an improvement process, the bottleneck is easy to spot. A bottleneck resource is:

• Always busy. But busyness isn’t the only (or even a good) criterion by which to recognise bottlenecks. Many systems are mistakenly optimised to get high utilisation (or rather busyness) out of all resources.
• Work piles up in front of them.
• Downstream resources are regularly idle.

The development team was the bottleneck. We had a list of features that was piling up in front of us. It would take us several releases to implement our backlog. Users were getting impatient for features to be implemented and deployed.

Where is your bottleneck?

Step 2: Exploit the bottleneck

If the output of the system is constrained by the output of the bottleneck, we must first try to increase the output of the bottleneck. Any idle time of the bottleneck reduces output of the system. What can we do?

• Remove any non-value adding work.
• Remove or limit interruptions. Remove impediments.
• Let the bottleneck resource work at a steady pace.
• Provide high quality tools and materials.
• Carefully prioritise the bottleneck’s work so that they always work on the most important tasks.
• Ensure that there’s always enough work to do for the team (the backlog), so that they don’t become idle through lack of input.

As team lead, I received and prioritised all incoming requests and questions. As I could deal with most of them, the team wasn’t interrupted.

Production issues needed to be handled quickly. All issues were handled by me and one developer. The bugfixer role rotated after every bug. This provided a nice balance between keeping the team focused on developing the current iteration and ‘feeling the pain’ of production issues.

I made sure that everyone worked at a sustainable pace. No more overtime!

Warning: don’t shield the team from useful information like input from the customer, production issues, installations and feedback from users.

We start by fully exploiting the bottleneck because this type of improvement is relatively easy:

• It requires no extra cost or investment.
• Only one resource is involved.

How can you exploit your bottleneck?

Step 3: Subordinate every other decision to the bottleneck

When we’ve fully exploited the bottleneck, we must subordinate every other decision to our decision to exploit the bottleneck. All the resources that aren’t bottlenecks have, by definition, some slack. Use that slack to support the bottleneck. We can subordinate by:

• Letting the non-bottlenecks help the bottleneck or take over some required but low value adding work.
• Everybody works at the pace of the bottleneck, no faster no slower, to avoid overloading the bottleneck with work in progress.
• Those in front of the bottleneck ensure that the buffer of work for the bottleneck is always filled, but not too much.
• Those after the bottleneck ensure that they have some slack to deal with variations in output of the bottleneck.
• Non-bottlenecks ensure that only high quality work in progress handed to the bottleneck.

As team lead, I subordinated all my work to the team: whenever there was a request for the team, a production issue or an impediment, I dropped all my work and supported the team. I quickly learned that I shouldn’t commit to delivering stories. My contribution to the team was less in contributing to its throughput and more in protecting the throughput of the rest of the team.

The onsite customer performed acceptance testing on completed stories every week, so that the developers got rapid feedback on the quality and fit of their development.

The onsite customer and I prepared stories for the next iteration and release, so that the team always had something to work on.

Subordinating is still relatively easy:

• It requires no extra cost or investment.
• Only a few resources, typically those that interact directly with the bottleneck, are involved.

However, there is one aspect of subordinating that won’t be accepted easily: whereas the bottleneck resources should be fully loaded, non-bottleneck resources must have slack time to be able to support the bottleneck and deal with variations. Most managers are evaluated on the efficiency and not the effectiveness of their people. Deliberately making people work below their capacity goes against their goals. We can solve this problem by fully loading the non-bottlenecks but ensuring that a part of their work is ‘discardable’, “nice if it gets done, but not essential or time-critical”. Whenever the non-bottlenecks need to support the bottleneck, they can drop the non-essential work to free up time.

Which decisions do you need to subordinate to the bottleneck?

Step 4: Elevate the bottleneck

This is the step most people will intuitively apply first: add more people, more machines, more training, more tools, more of everything. We only take this step when all the ‘free’ improvements have been performed. We can elevate by:

• Adding more people or machines
• Training and mentoring
• Better tools, faster machines
• Switching to a different technology

My manager asked me about every week if I wanted some more developers, if I “wanted to elevate my team by adding more people”. I declined, because we had plenty of room for improvement left with exploit and subordinate improvements. I asked if we could get faster computers instead. He told me we couldn’t because the hardware budget was exhausted. But there was budget for extra developers if I needed any…

Elevation improvements are more difficult because they require an investment. Elevation improvements are dangerous because most of these improvements take some time to produce results. Results might even worsen until the improvements start to have a positive effect. For example, when we add people to a team we lower the team’s velocity and accept less work while the team members help the newcomer get up to speed.

Don’t elevate yet. I know you can apply so many more exploit and subordinate improvements.

Step 5: And again!

When we’ve applied one improvement and have seen a positive effect, we go back to the beginning:

• Is our goal still valid? Is our measurement of throughput still correct?
• Where’s the bottleneck? After some improvements we may have solved our worst problem. As there’s always a bottleneck, our second-worst problem gets a promotion. We now need to focus our attention on the new bottleneck.

And the result was…

The team got better and better by repeatedly going through the five focusing steps. After a while, they started to develop stories faster than customers could write them. That’s when we needed to apply focusing steps six and seven.

I want to know more

Read the Goldratt books about the Theory of Constraints.

Download and play the “I’m not a Bottleneck! I’m a free man!” simulation from http://www.agilecoach.net

Read more about the Theory of Constraints on this blog.