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.

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

• Pinocchio: On Becoming a Lean Leader
• Agreeing on Business Value with Systems Thinking
• Estimation Games

I hope you enjoyed the session or get some useful ideas from the session materials. Let us know how you’ve applied these tools.

The session will show how using business analysis and kanban techniques we can create a flow from business goals to implementable user stories with acceptance test, focus on value-delivering capabilities and involve the whole team in product development.

The “A3 report” is a standardized report format used within Toyota and other companies to make proposals and report. The standardized and constrained format helps the writer and readers to come to the point quickly, concentrate on the essentials and get the important information without wasting time.

However, when applying this technique we often only implement the superficial elements, the fact that the documents are limited in size and have a standardized format. Sometimes, the exact format of the Toyota reports is copied. And then we’re disappointed because this “cargo cult” application only delivers limited benefits.

In this session we’ll look at and let participants experiment with the social aspects of the A3 report:

• How we define the standardized format to support our goals
• How leaders and managers use A3 report writing by their team members are structured one-to-one coaching
• How to build in iteration and feedback from peers to improve the proposals
• How to use the review process as a consensus building tool
• How to present reports in such a way that they’re heard, understood and accepted

Come and play with us if you want to learn more about this powerful continuous improvement and learning tool.

If you want to know more…

I’m looking for useful and usable definitions of Business Value. Lean should have a lot to say about value (when they’re not talking about waste): Value Stream, (non-)value-adding work, Value Stream Manager.

And yet, a book like Creating a Lean Culture: Tools to Sustain Lean Conversions that describes Lean Management doesn’t define what Value is or how you define it. The Lean Manager’s job is to ensure that the right thing is done the right way. “The Right Thing” has been defined beforehand and the Lean Production Manager ensures that the value (as defined in the product to deliver) is delivered quickly and efficiently. In production, quality has been defined and is constant (except when the product changes). The emphasis of the production manager is on “the right way” and increasing flow by reducing waste because those are the only variables the production manager (and workers) can influence.

Implementing Lean Software Development: From Concept to Cash has a separate chapter on Value, which comes just before the chapter on Waste. The chapter doesn’t really define value. The closest to a definition of value comes from Lean Solutions: How Companies and Customers Can Create Value and Wealth Together. What do customers want?

• Solve my problem completely
• Don’t waste my time
• Provide exactly what I want
• Deliver value exactly where I want it
• Supply value exactly when I want it
• Reduce the number of decisions I must make to solve my problems

This gives us a good set of criteria to check, because each of these criteria reduces the customer’s value if done badly. How do we know what customers value? The advice is to understand the customer by:

• Living in the circumstances of the customer, for example when the chief engineer of the Siena minivan cruises from Canada to Mexico to understand how to improve the car.
• A similar technique is “apprenticing”, where we learn how to do the work from a user
• Observe real users at work
• Perform usability testing to ensure we haven’t reduced customer value

Toyota Way Value

If we look at the 14 Management Principles from the World’s Greatest Manufacturer from the Toyota Way (p. 37) we see that Customer and Value are only mentioned a few times:

• Generate value for the customer, society and the economy – Principle 1: Long Term Philosophy
• Quality for the customer drives your value proposition – Principle 5: Build a Culture of stopping to fix problems, to get quality right the first time

So, Value == Quality for the Customer.

Chapter 5 describes how Quality for the Customer was defined for the Lexus.

• Look at who the competitors are
• For each competitor, what do customers like and dislike about them?
• Rank order the quality attributes
• Select a small number of target qualities (in this case: top speed, fuel consumption, noise, aerodynamics and weight)
• Define constraints and basic needs (reliability, safety, resale value, interior…)
• Set targets for each of the quality attributes

Now, we know that if we ask potential customers and users what they like in existing products and want to see in the new product we’re not going to get a very exciting list. In “Kano model” terms, we’re going to get the “must have” basic needs and some performance needs (“It uses a bit less fuel than my current car? Nice.”). Where do we get the exciter features that make the difference?

In this case the exciter was the word AND. The new car had to beat its rivals in all of the target qualities: lighter AND faster AND more fuel-efficient AND quieter AND… than the leader in each quality.

Toyota Production System Value

The Toyota Production System (and all the material derived from it) doesn’t say much about value because value has already been defined and is a constant (or constraint) for production. The Toyota Product Development System has as its first principle “Establish Customer-Defined Value to Separate Value-Added from Waste“.

How is this done?

• Appoint program leaders who have the background and experience to establish an emotional connection with the target customer
• Perform Genchi Genbutsu (Go See the Actual Work) to see the customer in action in their environment
• Create a vision for the product which includes quantitative and qualitative goals (using “Value Targeting Process”, as described above)
• Create a concept paper based on thorough discussion, information gathering and consensus-building
• The leader and the concept paper guide development throughout the project
• The project is broken down into functional teams, each with their own leader who applies the same process recursively, so that each team has a customer perspective
• Value targets are set
• Cross-functional teams work together to find ways to achieve all the value targets

Business Value is a Model

At Agile 2008, Chris Matts and Andy Pols had a session about Business Analysis. They made one statement which clarified what I was looking for and what I was doing:

Business Value is not a value. Business Value is a model.

There’s not just one value or one quality: different stakeholders all value lots of (conflicting) things. Moreover, value is not static. For example: whether I deliver a car (or a software project) next week or in six months can have enormous effects on your valuation of that exact same product.

As with all models, much of the value comes from the thinking about value and the modeling, not the final model. When I come onto a project, I will always ask about the Business Value Model. If you have an explicit and agreed model, decision-making will be much more effective. If you don’t have an explicit model, that tells me a lot: we’re going to have constant discussion about goals and value. Even worse, some teams have an explicit model (“espoused theory“), but use another model (“theory in use“) which leads to no end of conflicts and dysfunctional behaviour. I can usually deduce very quickly what the real model is from the actions of those involved. That’s why I like to add a third part to the statement:

Business Value is not a value. Business Value is a model. Business Value models what you value.

So… How can build a Business Value Model in our work?

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?

In 2003 I wrote a two part article on Agile Fixed Price projects: “The Price is Right” and “Do you want Agility with that?“. These two articles were combined into one chapter for the “Managing Agile Projects” book. The tips are divided into three sections, corresponding to three phases:

• Qualifying: do I want to take this project on and if so, how?
• Selling: how do I get the contract in such a way that we can succeed?
• Implementing: now that we’ve got it, how do we make this project a success?

What’s changed since then? What have I learned since then? What would I do differently. Let’s revisit each of those papers and look if the advice is still right. Then, we’ll see some new lessons.

In the previous blog entry I revisited “The Price is Right”. Today, we’ll have a look at “Do you want Agility with that?”

Qualifying Tip 1: Make sure you have a committed customer

Agile fixed price projects require greater effort and involvement from the customer. A hard release date is a good indicator of a motivated customer.

The customer will be more motivated, more willing to think about solutions if there’s the pressure of a hard  deadline.

In retrospect: this is clearly insufficient. A hard business deadline, not some invented meaningless deadline, is one positive factor in many successful projects. It’s also present in many tales of deathmarches. Necessary but not sufficient. A limited budget is always useful too; beware of customers who have too much money (they do exist). During the sales, we must test the customer to see if they’re really committed to this project. Ensure that you get to talk to everyone who will be involved in the project. If they don’t have time to see you during the sales process, they won’t have time to help you during implementation. Ensure that their goals are aligned with the project’s goals.

Qualifying Tip 2: Make sure you get timely feedback

We need timely and regular feedback from the customer. We put those customer commitments in the contract.

Customer collaboration AND contract negotiation. The customer has responsibilities too and those belong in the contract. If we don’t get the feedback in time, we can’t run the project. I’ve stopped several projects because the customer didn’t honor those agreements. We either resolve the problem (the customer ensures they make some people available) or we stop the project altogether. Maybe we’ll restart the project at a time that’s more convenient for the customer. See Selling Tip 2: It works both ways.

In retrospect: it’s about more than feedback. We need to agree on the way we’ll collaborate.

Sales Tip 1: Many small projects are better than one big project

Success rates are higher for small projects than for large projects. We reduce the size of the scope to only include a minimal feature set. As a result, the customer pays less, gets value sooner and can postpone decisions. I reduce my risk, get a chance to prove myself with the customer and can test our relationship with a small investment. But don’t do projects of a few days only.

Small projects bring lots of advantages to customer and provider IF we can keep the startup and transaction costs of each project small. As an example, at one time we had a rule that no project could take longer than three months and that we had to deliver at least each month for customer acceptance. The smallest project (an extra feature in a product) took one week from customer request to delivery of the product CD. Many projects had weekly delivery for acceptance.

In retrospect: the advice still stands, but we deal with scope differently. Instead of creating lots of User Stories and selecting those that have high value, we start with the Business Value drivers and then derive the minimal set of User Stories that will deliver the value. Therefore, our scope is minimal and sufficient by construction, not by elimination.

Implementation Tip 1: Let the customer sort the requirements

User Stories are ordered by the customer and implemented, as much as possible, in that order so that the customer gets the high value stories sooner, can test sooner and reduces the risk of dropping high value features.

Implementing this way is good for the team: we’re working with value- and business-driven priorities, we have to make sure that the user stories are independent to give the customer the liberty to sort.

In retrospect: the advice still stands. If the stories have been derived from the Business Value drivers, we will already have this ordering.

As an aside: many agile teams get off to a wrong start when they talk about this to their customer:

Team: we need you to order the stories by value and we’ll implement them in that order.
Customer: why is that important? As long as you deliver the scope, in any order, I’m happy.
Team: well, if we mis-estimate and run out of time we’ll drop some of the lower value stories.
Customer: what? You plan to run out of time? And you‘ll drop my stories? Do you guys know what you’re doing?

Mitigating schedule risk is one of the minor advantages of implementing by value. It’s more about delivering value sooner, getting information sooner, keeping the customer involved and mitigating the risk of building the wrong thing.

Implementation Tip 2: Requirements as stories. Don’t sweat the details

The requirements for the project should be expressed as high level stories. These stories’ contents have some margin for negotiation. The specification becomes shorter and easier to understand. We put less effort in creating the specification and we can delay decisions. This only works if I have a pretty good understanding of the domain and the customer. I need a good working relationship with the customer to be sure that the details will get filled in just in time.

We install a pull analysis system to create detailed specs just in time. We usually make this visible by having one or more columns on the kanban board that show this activity, so that we can quickly see if the customer is keeping up with the team.

In retrospect: the advice still stands, but how do you make it actionable? The best way is to start from Business Value Drivers and then to describe real Business Requirements. The specification and the contract shouldn’t fix implementation, they should specify the business goals to be achieved and the capabilities that must be delivered to achieve the goals.

Implementation Tip 3: Exchange Requests

If the customer wants to add a new User Story, they must first remove a number of User Stories for at least the cost of the new User Story. That’s the way we keep budget and timing constant. That’s the way we keep the price fixed.

Change Requests are evil. When we run a project (not only fixed price ones), we’re very strict on Change Control. Nothing gets changed in the scope unless we know there will be no negative effects. I don’t like change.

In retrospect: advice still stands. It’s simple, but very effective. A well-run project with Exchange Requests has a fixed price, fixed deadline and a minimum guaranteed value. The customer gets more value than expected, because they exchange high value new stories for lower value stories.

Implementation Tip 4: Put dropped requirements in a follow-up project

The User Stories that get dropped because of an Exchange Request are probably still useful (or they wouldn’t have been in scope in the first place). Never extend the current project, but define a follow-up project for these lower-value stories.

Fixed price, fixed deadline. The customer gets the system on the requested date. Qualifying Tip 1 means that the customer can’t afford to miss the deadline. If they want more, we’re more than happy to do another project.

In retrospect: the advice still stands. Moving deadlines reduce the value of the solution and demoralise the customer and the development team.

Implementation Tip 5: Let the customer use the software before the follow-up project

Let the customer use the delivered system for a while before starting the next project. The customer will learn a lot and come up with better ideas for the next project.

The best feedback comes from production use. Let the customer put the solution in production and start earning value. By the time we start the next project, the customer has more information and more money.

The problem is that we delay our income. I consider this a sound investment in a collaboration that’s valuable for both parties.

In retrospect: the advice still stands.

Implementation Tip 6: I’m the onsite customer

Not every customer can afford to have a full-time onsite customer in the team. In those cases, I as business analyst-project manager, can play the proxy customer role. This requires that the proxy customer knows a lot about the domain and that they know what they don’t know. Then we need to consult with the real customer.

Projects with a real onsite customer go measurably faster. Projects with a proxy customer are slower, but still faster than those with an off-site customer. We do need to be sure that we can get enough access to the real customers when we need it. That’s why we’ve agreed from the start how we’ll communicate and collaborate (see Qualifying Tip 2).

In retrospect: try to get a real onsite customer first. It may seem impossible, but if the project is value-driven you may be able to convince the customer. For example: “with an onsite customer avalailable N days, we can deliver the project one month earlier, which will bring an extra revenue of X“. If X is substantially more than the cost of N days, the customer would be stupid not to have an onsite customer.

Implementation Tip 7: Frequent releases, incremental delivery

Release frequenly for acceptance testing (for example once a week) and divide the project in one month increments that deliver a coherent set of functionality. The customer might discover that these increments are good enough to be used and will ask for incremental delivery.

The team and the customer need to learn to deal with regular releases. See how fast you can go today and decrease the “takt time” gradually.

In retrospect: the advice still stands. Unfortunately, I see more and more companies and team that go backwards, delivering fewer releases per year and increasing their cycle time. This leads to a vicious cycle, as releases get more complex and error-prone. Agile requires technical and operational excellence, otherwise frequent releases can’t be sustained.

Implementation Tip 8: Looking back to learn

Take time to look back and learn in a retrospective. Review actuals versus estimates to provide the basis for future estimates. Preserve new knowledge about risks and how to deal with them.

It may sound self-evident that you’d do this, but I’ve seen very few companies that learned from projects. In many cases there are retrospectives, but no actions or no time (or courage) to tackle root causes. Many projects feel like Groundhog Day: an endless rerun of the same mistakes with no hope of escaping. An ominous voice in my head keeps repeating “It is happening again. It is happening again.”

In retrospect: sound advice, but how do you make it actionable? Make sure that you find and tackle root causes using, for example, Systems Thinking techniques. Make sure that actions are defined and performed. Keep track of real project measurements, especially actual cost and time versus estimate.

And the score is…

Most of the advice still stands but the implementation should be described better to make it actionable.

We have changed the way we do analysis: instead of discovering the scope and estimating value, we define value and derive the scope from that. This value-driven approach brings several benefits:

• The scope is minimal and sufficient by design, so we spend less time on it
• The project is value-driven, which make prioritising and assigning an onsite customer easier
• We negotiate about value first, cost second. Customers have no problem paying if they’re convinced of the value.

I’ve learned that the techniques from the two articles need to be taken together. It’s not “Do you want Agility with that?”,  but “You need Agility with that”.

There are some more tips I’ve collected over the years. We’ll look at them in the next entry.

In 2003 I wrote a two part article on Agile Fixed Price projects: “The Price is Right” and “Do you want Agility with that?“. These two articles were combined into one chapter for the “Managing Agile Projects” book. The tips are divided into three sections, corresponding to three phases:

• Qualifying: do I want to take this project on and if so, how?
• Selling: how do I get the contract in such a way that we can succeed?
• Implementing: now that we’ve got it, how do we make this project a success?

What’s changed since then? What have I learned since then? What would I do differently. Let’s revisit each of those papers and look if the advice is still right. Then, we’ll see some new lessons.

First, let’s re-read “The Price is Right“.

Qualifying Tip 1: Do I know what I’m doing?

I’ll only enter into a fixed-price contract if I can specify, estimate and plan the project as agreed, within a small tolerance.

I need to ask myself four questions:

1. Am I familiar with the domain? If not, I’ll spend a lot of time learning and won’t be able to help the customer define what they really need.
2. Am I familiar with the technology? If not, I’ll spend a lot of time dealing with stupid technology issues.
3. Am I working with my usual team? If not, I’ll spend a lot of time building the team and I won’t be able to use velocity to estimate.
4. Am I used to delivering projects of this size? I not, I’ll spend a lot of time scaling up my usual practices.

In retrospect: the advice still stands, not just for fixed-price projects.

Selling Tip 1: Don’t respond to RFPs, communicate

Don’t just respond to a written Request For Proposal but establish a real collaboration and communication with the customer.

We’re going to collaborate and communicate anyway, so let’s start now and see if it works before we’ve spend much time in this relationship.

In retrospect: the advice still stands. Some customers prefer not to communicate and keep providers at arm’s length. Do you really want to work with them? If so, plan on a large risk contingency.

Selling Tip 2: It works both ways

Ensure that the contract evenly distributes responsibilities and benefits between customer and provider. Make sure that the customer is committed to doing what you expect of them.

The most important goal of the sales process is to set up a working agreement between customer and provider than leads to success. Always “test” the customer: build in small commitments for the customer and see if they hold their part of the bargain.

In retrospect: the advice still stands. I won’t enter into an agreement that I think is unfair. I won’t start a project unless I have confidence that the customer will do what they’re responsible for. Too many projects go wrong because the customer agrees to do something and then doesn’t take up their responsibilities.

Selling Tip 3: Don’t underbid

Don’t quote a price below cost to win a contract with the intent of making it up later with extra costs.

No unfair contracts.

In retrospect: the advice still stands.

Selling Tip 4: Add enough slack to cover the risks

Do a risk assessment of the project. Add enough slack to the estimate to cover risk, estimation accuracy and (especially) the type of customer you’re working with.

How much slack needs to be added? That requires a lot of experience (see qualifying tip 1) and historical data. For example, what’s the fluctuation in velocity over the last few projects? How does this customer compare to previous customers?

In retrospect: the advice still stands, but I’d clarify that this is a “project buffer“, à la Critical Chain: the extra time does not get added to individual features, but is kept in a “global pot”. If things go better than expected, we add to the pot. If something goes less well than expected we take a bit from the pot. The state of the pot tells us if we’re on track.

Selling Tip 5: Real Business Requirements

Write the specification with the customer so that each feature is well-understood, adds business value and is testable.

We want to write a short, clear and actionable specification without technical detail and just enough functional detail to get started.

In retrospect: I didn’t emphasize this enough. We need to agree on Business Requirements, not System Requirements. What’s the difference? Business Requirements describe what the customer gets out of the project, the value that will be gained and the capabilities that are needed to achieve those goals. System Requirements describe how we will implement the capabilities. The customer doesn’t perform acceptance testing on implementations. The customer accepts when the capabilities deliver the expected value.

Implementation Tip 1: No Change Requests

Never allow Change Requests that increase the scope, cost or duration of a project.

Never. It’s a slippery slope: with each little change the project gets more out of control. I don’t like change.

In retrospect: the advice still stands, you should use “Exchange Requests” instead and only allow changes that are beneficial to the project.

Implementation Tip 2: Spend your slack wisely

Resist the temptation to “slack off” because there’s slack time left.

The project buffer should only be used when things go wrong. Avoid the temptation to “gold plate” features because there’s time left. The team should be energised and motivated to get their work done in time.

In retrospect: how do you implement this? Critical Chain recommends planning with “50% certainty” estimates, estimates that will be too short 50% of the time, to avoid Parkinsons Law. I recommend building a team that’s motivated to deliver quality and business value.

Implementation Tip 3: Simple, honest and correct tracking

Track progress using a simple burndown chart, but only count things that are DONE.

If you have a clear definition of done for every piece of work (and you can have definitions for each column on your kanban board), then you can simply record how much work is done versus how much work you expected to be done. For most projects, the expected amount of work done curve looks close enough to a zone around the diagonal from 100% to 0% done, so that a simple burndown chart, updated regularly, is enough to know where you are. Make sure that the information is visible and understandable to everyone involved.

In retrospect: the advice still stands. The important part is to be able to say that something is done. I’m very strict in this: I prefer seeing the burndown “flatline” because no story is done, than to see fake progress because something is “90% done”.

Implementation Tip 4: Manage your project

The job is not about specifying, estimating and planning perfectly. The job is about delivering what the customer needs.

Attack your risks or they will attack you.

Don’t shield the team. Help them to avoid and solve problems.

Good project managers don’t seem to do a lot and lead pretty uneventful lives.

Success comes from setting up the right project (qualifying) the right way (selling) and then doing all the daily work to keep it on track (implementing). It’s all about actively managing the project with a light touch.

In retrospect: the advice still stands, but to explain how you do this would require (at least) a whole book and lots of experience. Look for the project managers who have a reputation for “calm, quiet” projects that deliver and learn from them.

And the score is…

I still stand by what I wrote then, but I need to explain some of the tips in more detail.

I’ve learnt a lot more about writing contracts and discovering real business requirements.

I’ve also learnt that these tips aren’t enough to run a project, fixed-price or not. Agile (or professional) techniques aren’t an option, they’re necessary. Those are in the second part of the article.

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.

Like this?

Like this?

Like this?

How would you like to see the future? You can choose.

Freedom Evolves

Embarassing moment #239: Turning up late to teach an estimating and planning course.

Danger: Estimator at work!

Estimation is (sometimes) useful, but it has its dangers. Estimation provides us with useful information, to base management decision on. This information and the way we get it can be misused. Maybe that’s why so many people are so afraid of estimating and look for ways of avoiding it.

What are some of the problems?

Appearing too certain

We all feel uncertain when we have to estimate something, so how can we appear too certain?

If I ask you to estimate how long something will take, what do you answer? If you give me one number, my immediate reaction will be “Wrong!” If I think about it, I will ask you “Are you certain? Which factors influence that estimate?”

A number is always the wrong answer to any estimation question. Are you so certain that this work will take exactly so long? What about all risks and the myriad variables that influence that work? How much do you know about the customer, the project, the team, the technology. Admit it, at the start of the project you don’t know a lot.

The “Cone of Uncertainty” show us how the uncertainty range of estimations changes as we learn more. It teaches us to always quote a range when we’re asked to estimate. The more uncertainty, the larger the difference between low and high estimate. That’s the good news. The bad news:

• These Cone of Uncertainty ranges are best case values. The two lines show how badly good estimators can estimate. The shaded area shows how the ranges converge for bad estimators.
• The X axis isn’t time. Your estimates don’t improve with time, they improve with information, knowledge and experience. The X axis should display your level of knowledge.
• The cone isn’t symmetrical. Most of us tend to underestimate the amount of work required.
• For some reason, we tend to use ranges that are too small to adequately cover the uncertainty, even when nobody pressures us to do so.

For estimation purposes, remember these two definitions:

• Accuracy: how close to the real value a number is. “I estimate this blog entry will take me between 2 and 4 hours to write.” Not bad: it actually took me a bit more than 3:30 (based on the timestamps of the edits).
• Precision: how exact a number is, independently of its meaning. “I estimate this blog entry will take me 4 hours, 45 minutes, 23 seconds and 860 milliseconds to write.” Wrong! And I don’t need to know about seconds and milliseconds!

Mistaking estimation and commitment

“We don’t need a range, we need one number, one date, one deadline to communicate with other parties!” Right, but that’s not an estimate, that’s a commitment.

Given that we estimate the product to be delivered between D1 and D2, which delivery date do we commit to when we talk to our customer? That’s a management and commercial decision, based on the confidence we have in the estimate, commercial pressure, deadlines, how much risk we want to take, the cost of failing to deliver as committed…

Developer: This project will take between X and Y days to complete.
Salesperson: I sold the project based on 2/3 of that number of days. You’re responsible if we don’t deliver in time.
Developer: I think that’s your responsibility. We’ll deliver the project as fast as we can, but we can’t guarantee it’ll take less than Y days.

Spending too much time estimating

Estimating takes time and we want to get that estimate just right, because we’re afraid of what might happen when we get it wrong. So we do some more investigation, another spike, try another estimation method… In the limit, we could just do the project, that would give us a perfect estimate.

Estimates are information to base management decisions on. What kind of decision? Depending on the type of decision, we need more or less accuracy, we need to spend more or less time. In any case, estimating shouldn’t take more than a few percent of the team’s time.

Manager: I want to know how long <some project> will take. Give me an estimate.
Developer 1: Yes boss! I’ll get right to it!
Developer 2: What kind of estimate do you need? What’s the required accuracy? What information do you have? How much time can we afford to spend on this?

Not looking at the big picture

Many tutorials on estimating give the advice to break down the work in small bits and then estimate those. The advice isn’t bad because, as we’ll see later, having an estimate based on estimates of smaller pieces improves our accuracy. But breaking down the work in too small pieces has a lot of drawbacks:

• All that breaking down takes a lot of work and then you have to manage all these small pieces. If you do this too soon, you’ll have the wrong pieces anyway and you’ll have to carry them along until you discover they’re wrong.
• You could break down the work below that which can be usefully validated with acceptance tests. I tend to avoid estimating tasks, because there’s often no clear and independent way to verify that the task has really been done. What’s the use of estimating something nobody’s waiting for? I prefer to estimate deliverables and user stories where a “customer” can meaningfully say “This is (not) done.”
• Nobody wants to know when a specific story will be done. We want to know when a Minimal Marketable Feature will be done, when the release will be ready, when the deliverable is ready to hand over to another team. If we break down the work too far, we’ll waste time tracking that detail and lose sight of the real goal. If we keep looking at the big picture, the law of large numbers will work to our advantage.

Destructive negotiations

Developer: We estimate the project will take between X and Y days to complete.
Manager: That’s too long! Your estimates are wrong! Redo the estimation and don’t come back until they’re right!

Those who estimate are often faced with people who are a lot better negotiators than they are: managers and salespeople. Moreover, the estimates are often based on quicksand and the estimators have a poor track record, so there are few facts that can be used in the negotiation. The only way to win this game is not to play: estimates are not negotiable. Project contents are negotiable, approaches are negotiable, resources are negotiable, commitments are negotiable. Estimates aren’t negotiable, but up for review and improvement when we get new information.

Developer: I understand that we need to make a commitment that’s earlier than the worst case estimate. Can we have a look at the project to see if there’s a way to change it so that we can deliver upon that commitment?

Playing with models

Some estimation techniques are based on models with several variables. For example, we could have some parameters that increase the estimate if we work with an inexperienced team, new technology or in a new domain.

On the one hand, the models and their variables allow us to tune the estimation methods and be aware of the many variables that influence our projects. On the other hand, these variables can be manipulated to come closer to an expected outcome. Because the number “came out of the model”, they gain undeserved authority.

Project Manager: The model predicts this project will take between X and Y days.
Manager: Can I have a look at your assumptions? Why do you rate your team as “Inexperienced”? Those guys we brought in last month are very experienced! Let’s change that parameter. And why do you say that this is new technology? Surely, web applications are almost the same as the mainframe applications we usually make? A consultant told me so. Let’s change that parameter. Ah! The estimate looks a lot better. Still  a bit on the high side, though.
Project Manager: … (Stunned silence. Thinks: I still have Y days to get out before the shit hits the fan. Those estimates are really useful.)

We also play with Mental Models, models of how others will act. For example:

Manager: I always halve the developers’ estimate, because I’ve noticed a tendency to pad their estimates and then I get blamed because we’re outbid by our competitors.
Developer: I’ll best increase the estimate, because our manager has this tendency to cut our estimates and then we get blamed if we don’t deliver in time.

Where do these mental models come from? Probably from some small dysfunction a long time ago which has grown into a serious vicious cycle. And we’d best not talk about these mental models, because that might cause all sorts of nasty conflicts!

Corporate amnesia

Once a late project is (finally!) done, the team is disbanded and everybody tries to forget this awful experience, the death marches to reach impossible deadlines, the daily re-estimations, the frayed tempers and the shortcuts that will haunt the maintenance programmers.

And then another project comes along that’s quite similar. So, we estimate by analogy: if our project is similar, the effort required should be quite similar. But nobody knows (or wants to admit they know) how much effort the project actually took. We use the original, documented estimate as our estimation basis. Result: another late project, by design.

Developer: Wow, this estimate with your new estimating technique is too high! We can’t present these estimates to our management!
Estimator: Why not?
Developer: They’ll never believe these estimates. Previous’ projects estimates are much lower.
Estimator: And did you deliver these projects as planned?
Developer: No. Never.
Estimator: And then what happened?
Developer: We just continued developing until it was done.
Estimator: I wonder why your estimates aren’t believed…

Is it all bad news?

With all of these dangers, it’s a wonder that any project actually delivers as planned.

If you have anything to do with estimations (either as a consumer or producer of estimates), read Software Estimation: Demystifying the Black Art. It not only contains the bad news, but also very practical advice on how to deal with it and become a more successful estimator.

There are ways to become better at estimating. But that’s the topic of a future entry.

Aujourd’hui, Portia et moi présentons une nouvelle session, “Les cinq premiers pas pour devenir agile” au XP Day Suisse à Geneve. C’est une présentation courte et interactive (les participants jouent 5 jeux) qui introduit cinq “outils” que nous utilisons quand nous commencons à travailler avec une équipe.

Plus de nouvelles après le congrès.

Cinq outils… et plus

Si vous voulez apprendre ces cinq outils et plein d’autres pour aider votre équipe a réaliser plus de résultats, devenir plus agile et s’amuser plus, la formation “Agile en Pratique” de Zenika est toute faite pour vous.

Vous aimeriez appliquer les méthodes agiles. Comment les appliquer dans votre équipe, sur votre projet ? Comment faire la transition vers les méthodes agiles? Cette formation répond à toutes ces questions. A travers des exercices, des jeux et des simulations vous expérimenterez les techniques agiles. Vous saurez comment, pourquoi et quand les appliquer afin d’améliorer la qualité du résultat et du travail de votre équipe.

Rendez-vous les 21 et 22 Avril à Paris!

The five first steps to become really agile

Portia and I present the “Five first steps to become really agile” at the Swiss XP Day. This new session presents five simple “tools” that we use when we start to work with a new team.

This is the first session that we developed first in french. We’ll translate it in English and do a tryout soon. Then we’ll publish the session on our Agile Coach site with the other games we’ve made.

More about the session when it’s published.

J., the manager of the Financial systems IT department, came to me for advice. He wanted to expand his developers’ knowledge and responsibilities. He wanted them to grow beyond pure development: to get more involved in architecture and analysis, interact with customers… We looked at several options and finally decided to start up a book reading group.

In a book reading group, a number of people get together to read and discuss a chosen book. To set up a book reading group:

• Invite participants. Participation isn’t mandatory.
• Select a book that interests the participants.
• Get enough copies of the book, so that everyone can choose when to read.
• Define a suitable reading pace. For example one chapter per week. Keep the iterations short.
• Agree on a fixed meeting schedule, time and place to discuss the book. The discussion is often scheduled during a lunch break, with lunch provided by the company.
• Moderate the discussion and record the main insights, so that there’s an output and those who miss a session can catch up.

The quiet team

There was something unusual about this team. They were so… quiet. You probably don’t want your accounting, invoicing and ERP systems maintained by a bunch of party animals, but still. These developers rarely talked to each other, they all worked individually on their own part of the systems. I was a bit worried: would they come to the discussion meetings? Would they say something?

What would be a useful book for this team? They all had different backgrounds, worked on different applications and used different technologies. I proposed we should start with something that would be useful as a basis for further study. We chose “Quality Management I: Systems Thinking” by Gerald Weinberg. I’ve found Systems Thinking to be a useful tool to make sense of a lot of situations, but would the team find it interesting? Would a book about “management” be useful for developers? The manager and I decided it was worth the risk.

We’ve noticed that some people will find or create the time to read books to learn more, but they are the exception rather than the rule. Many people are so busy at work that they don’t have the time to read books. Reading a book isn’t “work”. And the principle of “sustainable pace” surely means you shouldn’t be spending time reading work-related stuff outside of work.

The reading group has a number of advantages:

• Reading becomes part of “work”.
• Peer-pressure and the short timeboxes ensure that participants create the time to read one chapter every week.
• The discussion sessions ensure that participants read more attentively and hear how others interpret the material.
• The discussion regularly leads to ideas for improvement actions or people getting together to try out some new idea.
• Reading the book together improves team cohesion and (cross-)team communication. Even if participants work on different applications or work in different teams, they’re doing something together and realise that they face the same issues.
• A reading group reveals strengths, weaknesses and skills in individuals you wouldn’t usually notice about one another working together day-to-day. This discovery could lead to increased appreciation among team members which, in turn, leads to increased respect.

Group learning

The first couple of sessions required a lot of facilitation to get participants to speak up and give their opinion. The participants didn’t see the relevance of systems thinking. And why were we reading a book about management? They weren’t managers. They were developers.

Luckily, they kept coming to the book group, they didn’t give up. Gradually, they started to speak up more; discussions started; they debated different viewpoints. They started to see things in their environment, things that had always been there. But now they saw the world with different eyes. They started to see the connections between things. They started to understand why things happened as they did. They started to realise how they could influence their environment. They started to generate ideas to improve the way they worked. The group required less and less facilitation: two participants emerged as leaders, they kept things going. I didn’t have to say anything; I just acted as their scribe. The team was no longer quiet; they were full of energy and ideas.

When starting up a reading group:

• Ensure that there’s enough support and encouragement from the coach, a manager or some team members to get the group going. The first two chapters of a book are often not very exciting; the group needs to get to know each other and the format.
• Small signs of company support like paying for the books, providing a place to meet and buying lunch shows participants that they and their growth are taken seriously.
• Provide facilitation to get the discussion going and to keep the meeting on track. As the group gets more experience and self-organises, they will require less facilitation.
• Take notes and publish them so that those who weren’t present can see the outcome. Publishing an output raises the importance of the meeting.
• Ensure that the book is relevant to the work of the team. Let the team describe what they want to learn. The coach should have enough experience to suggest books that fulfil the requirements of the team.
• As with iterations, a regular pace with short iterations is crucial. We recommend weekly sessions, to discuss one or two chapters.
• Ensure you always meet in the same room at the same time. Don’t reschedule the book group meetings because someone can’t attend. They can always catch up.
• In a larger or more heterogeneous team you can create two groups who read a different book. Discussing the two books together gives everyone some insight into both books. Maybe the participants will find interesting links or contradictions between both books.
• Try to find books that contain questions or exercises for the reader. Participants must answer one question or perform one exercise per chapter. The group facilitator can set up questions or exercises for the group.
• If participants are uncomfortable during discussions, the facilitator can use techniques like a clustering exercise to elicit everyone’s input.
• The discussion will often result in ideas for improvement and action. Handle these like you would at a retrospective: prioritise them by value and include them as part of the team’s delivery iteration.

Yesterday evening I was back in Paris to give a presentation about “Lean and the Toyota Way“. As I walked from the train station to the offices of Zenika, I came across a large billboard announcing “Dorothy et le magicien d’Oz”. It’s reassuring to see that the fairytales are alive and well.

My friends at Zenika had arranged a nice place and provided some fine drinks and snacks. More than 100 people showed up, among them many of the French Agilistas. I chatted for a while with them about agile, lean and the upcoming XP Days France.

And then it was time to start the presentation. The auditorium was almost completely full.

The Toyota Way

The presentation explained the 14 principles of The Toyota Way of Managing and the many parallels with Agile methods. As I go through the principles I illustrate them with stories from projects I’ve worked on. Each time I do this presentation it changes, as I learn more and discover more great ideas in Lean.

There were some great questions and discussions:

• “What can I do to introduce more Lean and Agile in my organisation?” – Apply the principles and values, set an example. Support and collaborate with others who apply these values.
• “Are there any incompatibilities between Lean and XP?” – None that I can see.
• “For Agile and Lean transformations to succeed we need support from management and workers. Often, we only have support from one of them.”
• “Lean coaches are very direct, not afraid of saying it as it is to management. Is that something they’re taught?” – It does seem so, judging from the documentary Kenji Hiranabe showed at Agile 2008, where a Lean coach almost made a factory manager cry by bluntly pointing out all the flaws in the production line.
• “Does Lean make you lose weight?” – A Gemba Walk a day helps

Unfortunately, I couldn’t stay for drinks afterwards because I had to rush to catch the last train back to Brussels. The next day I had another team to coach, another opportunity to “Develop exceptional people and teams”, the tenth principle of the Toyota Way.

I hope to see the participants again soon. See you at the XP Days France or a Zenika training session.

A bientôt!

What others say

Jean-Claude Grosjean summarizes the principles and contrasts them with the 7 principles of Lean Software Development and Agile.

Nicolas Martignole wrote a very extensive report on each of the principles and relates Lean, Scrum and XP.

Claude Aubry thinks “Obeya” is more beautiful than “War Room”. I fully agree. He currently tries to recreate the Obeya experience for an offshore team.

Thank you for the rapid and very detailed feedback!

Father Christmas brought me a large stack of books. First off is an easy read, the new Malcolm Gladwell book “Outliers: The Story of Success“. In the book, Gladwell tries to dig deep to explain the causes of unusually successful people, the outliers that are so far beyond the statistical norm that they seem magical.

Why do some people become hugely successful corporate lawyers, wealthy captains of industry, billionnaire IT entrepreneurs or hockey stars?

First of all, there’s talent. But talent isn’t enough. It takes effort, practice and hard training to develop that talent. Gladwell states that you need at least 10,000 hours of practice and illustrates the number with examples of The Beatles, Mozart, Bill Gates and Bill Joy.

But talent and practice by themselves are not enough to explain the cases Gladwell examines.

It’s not only who you are, but where you come from

For example, if you look at the month of birth of successful Canadian hockey players, the statistics show that most of them are born in the first months of the year. A few years ago I heard about the study that showed the same weird result for Belgian football players. Coincidence? Fluke? Is there something in the air in those months that gives babies an edge in sports? Gladwell doesn’t think so.

You see, there’s a cutoff date to select promising young players. That date happens to be the end of the year. The children who are born in january are just a few days too young to be eligible, so they have to wait until next year. By then, they are 11 months older than the eligible children born in December. They are stronger, smarter and have had more practice. They are more likely to stand out, get selected and profit from intensive training given to talented children.

A similar case can be made for successful IT entrepreneurs: they were all at the right age and in the right environment to profit from the availability of computer time to develop and apply their skills.

Held back by systemic constraints

In the case of the hockey players, it is likely that children born in December are (on average) as talented and hard working as those born in January. If they don’t get selected, a lot of talent and effort is wasted.

Gladwell calls the rate at which talents make it the “capitalisation rate”. The capitalisation rate for hockey players is lower than it could be. Why? Because of an arbitrary systemic constraint: the decision to select and sign young talents based on one cut off day. This effect is known and repeatable across the world. When the cut off date changes, the distribution of children is changed accordingly. We’ve all been subject to this systemic constraint because schools work with a fixed calendar.

Should we just accept those constraints?

Raising capitalisation rates

If we wish to raise the capitalisation rates, we need to tackle similar systemic constraints. One hopeful chapter describes how a school system improves the results of its pupils. First they notice the systemic constraint:

• children from richer backgrounds do better after the summer holiday as they have lots of stimulating activities;
• children from poorer backgrounds do worse after the summer holiday as their environment is much less stimulating.

The solution: less vacation and more school. Which also leads to more hours of practice, the second factor of success. Which leads to more opportunities to succeed and provide a stimulating environment to their children.

The chapter about plane crashes is chilling. The chapter contains several transcripts from cockpit conversations right before a crash. One common element comes back: the pilot makes a set of small mistakes and no one dares to speak up.

Some airlines have many more accidents than others. These statistics correlate with the culture of the country of the airline. Geert Hofstede has compiled a set of cultural dimensions for countries. One of the dimensions is “Uncertainty Avoidance”. A high score indicates a culture that doesn’t like ambiguity, relies on procedures and plans and is likely to stick to procedure regardless of circumstance. Another dimension is the “Power Distance Index”: a high score indicates that authority is very respected and a more powerful or knowledgeable person will not be questioned easily.

Do high Uncertainty Avoidance and Power Distance scores correlate with high numbers of airline incidents? Yes. If something goes wrong you want people to speak up and consider alternatives to the routine. Knowing this, training can take into account the differences. For example, techniques to lower the power distance can be taught and applied in the cockpit. Again, dealing with the systemic constraints brings dramatic improvements.

What have we learned today?

I got two lessons out of this book.

First, the capitalisation rate on our teams. It is sometimes said that “Agile only works with really good people and teams”. That’s true. But Agile also makes the people a lot better by providing them with a better environment, support and many learning opportunities. We create communities, conferences and help each other get better. We raise the capitalisation rates within IT. But we can do a lot more if we have the courage to tackle the systemic constraints. For example:

• Why are there fewer women than men in IT?
• Why is IT seen as a “young man’s game”? Why don’t we value experience more (and keep reinventing yesterday’s mistakes)?  Don’t we need to put in our 10,000 hours to become proficient? Well, at least many of us put in many hours in death marches. I don’t know if that’s useful practice, though…
• Why the division into “Business” vs “IT”? Aren’t we in this together?
• Why the division into development, testing, maintenance, operations? Isn’t it all one value stream?
• <your favourite constraint here>.

What small thing can you do to raise the capitalisation rate?

Secondly, Belgium was used as an example of a country with a high “Uncertainty Avoidance” culture. Yeah, we’re great at creating little rules to organise everything. We’re also great at breaking the rules, because they keep us from doing any useful work. But nobody must know we broke the rule, because we’re also a culture with a very high “Power Distance Index”. In this, we’re quite similar to France. Now, that’s not a culture that’s naturally predisposed to accept Agile methods. Except maybe, when they’re introduced top-down and are very structured?

On the other hand, The Netherlands and Scandinavian countries have a much lower Uncertainty Avoidance and Power Distance Index score. One would expect that they would accept Agile methods more easily.

Have a look at the scores for your country. Do they correlate in any way with the success and ease of introducing Agile?

Watch Gladwell present some of the ideas in the book:

On the 21st of January 2009 I’ll be in Paris to present an evening seminar on how to apply the Toyota Way management principles to Agile software development. The seminar is organised by Carl Azoury and Olivier Huber of Zenika.

To me, Agile is the application of Lean principles to software development. So, the presentation contains a lot of parallels between the two. A lot will be very familiar if you already know and practice Agile.

So, what’s left to learn? Some of the Toyota Way management principles aren’t in Agile methods. These principles are useful when we go beyond software development. There comes a moment in any successful Agile enablement when the development team is no longer the bottleneck. Suddenly, we’re faced with a completely different set of issues. Now that Agile gains more and more acceptance, we need to be able to deal with these new challenges or accept that most Agile transformations will either die or bring limited extra business value.

The more I read and learn about Toyota, the more I realise how much I don’t know and how many preconceived ideas I have to abandon. I need to keep learning. The Toyota Product Development System, for example, contains many counter-intuitive ideas like set-based design. Real Options thinking can help us understand why some of these techniques work. We’ve only started to scratch the surface of Lean ideas.

Toyota losing money? Impossible!

In the news, even Toyota is affected by the economic climate. They might even have to post the first loss since the early years. Isn’t Toyota invincible and perfect? Of course not. It will be a real show of faith in the Toyota Way if Toyota continue to keep on their workers, keep training them and keep improving to be ready when sales take off again.

Secretly, top Toyota management must be happy that this crisis happens now. One of their main concerns is complacency. No one should ever think that the work is “done”, now that Toyota is the biggest manufacturer. Hansei and Kaizen should be applied relentlessly, it’s always possible to do better. Nothing better than tough economic times to bring back the sense of urgency.

See you in Paris

The seminar is free, but you must register here. Don’t wait too long because places are limited.

See you there!

This summer, I met two of my heroes, Eli Goldratt and Neil Armstrong, in Paris.

Yesterday, I met another hero: Daniel Dennett. Professor Dennett gave a talk entitled “Considering Consciousness” at Antwerp University. Professor Daniel D. Hutto provided a counterpoint to the presentation.

What is consciousness?

Dennett used the metaphor that “Consciousness is Fame in the Brain”.

Lots of stuff is going on all the time in our brain. Information is changed, updated and revised (the “multiple drafts” model), distributed in time and space. Some of this activity wins a competition for attention and becomes “famous”. That’s when we become conscious of the activity.

We can make a clear distinction between conscious and unconscious, but we can’t pinpoint an exact time when something becomes conscious. A thought becoming conscious is like a “speciation event” (the start of a new species): the moment when it happened only becomes important in retrospect. An observer who was there at the moment it happened wouldn’t notice anything very special. Consciousness isn’t an all or nothing phenomenon. Are animals conscious? A lot less than humans. Is a baby conscious? Less than an adult and in a more limited way. As it grows it becomes more conscious and conscious of more.

The Cartesian Fallacy

Dennett warns us against the seductive “Cartesian Theater”, the idea that there is some special place (and time) in the brain where consciousness exists. As if there is some homunculus in the brain that is conscious and that watches and controls all the unconscious processes. But then, how can we explain that consciousness in terms of unconscious processes? We’d be stuck in an infinite regress. Subtle versions of this idea are very common.

Another common fallacy is to confuse the time of the represented with the time of representing. For example, when we hear the sentence “Bill arrived at the party after Tom”, we will first represent Bill, then Tom. But our representation indicates that Tom arrived before Bill. Our mind has clever tricks to deal with time-related issues. Signaling and processing in our bodies and brain is rather slow, so our brain will adjust the ‘timestamp’ of information received by taking into account the expected ‘travel time’ of the signal. Neurological experiments can exploit this adjustment so that it seems to the subject as if actions happen before they’ve initiated them.

When Dennett explains these fallacies, they seem pretty obvious. Yet, only a few months ago I read an article by a philosopher who claimed that a neurological experiment that ‘cheated’ the brain into thinking that actions had been performed before they had been decided showed that people have no free will. More on free will later.

The Heterophenomenological Method

Heterophenomenological Method is a big word to describe a method of enquiry where when someone tells us “It feels like <this> is happening in my brain” we certainly accept that this is how it feels. That doesn’t mean it actually happens that way. Another metaphor: when we investigate consciousness, we should act like a Martian investigator, looking for the objective mechanisms behind the subjective report.

Daniel Hutto questioned, with a presentation on the edge of “Bimbo slides“, whether Martians could really investigate us if they were devoid of a human body like the Martians in Wells’ “War of the Worlds”. Is the Heterophenomenological method really feasible? Hutto proposed to relax the requirements, because experience is crucial to understand.

Who’s “I” ?

Someone asked if consciousness could arise in a distributed “organism”. Dennett replied it could if the architecture was right. In many ways, we are a “colony” of many organisms. After the “Wisdom of the Crowds“, can there be a “Consciousness of the Crowds”? “Fame in the Crowd”…

Another question that arises is: what is “I”? Where is it? Is it the conscious part of me, like the Cartesian Theater would suggest? Or is the I more encompassing, including unconscious processes and the body?

I know how it feels it works.

About heroes

This summer, in a discussion about heroes, I realised that the people I admire have one thing in common: they’ve made me see things in a different way.

“The real voyage of discovery consists not in seeing new landscapes, but in having new eyes.” — Marcel Proust

Yesterday someone told me “Consulting is easy. You just say to management what we’ve been saying for years!”

People tell me that all the time.

My standard answer is: “You’re right. I just listen to people. They usually tell me what the problem is within 5 minutes. They tell me what the solution is in the next 10 minutes. Easy.” (The 5-minute Rule)

The rest of the day is filled with fooling around with word processors and presentation software. And playing with index cards, whiteboards, stickers and other silly stuff of course!

Consulting ain’t as easy as it looks (The Number One Secret)

But if it was so easy, why did this person need to repeat their message for years? Why wasn’t the message heard or acted upon?

Giving advice isn’t easy. Getting advice is even harder. The Secret of Consulting is that you have to be heard to have an effect.

Everybody who wants to be heard, not only consultants, should read this book at least once per year.

But, why does this customer need a consultant if their employees could give them the same advice, essentially for free? Why don’t they hear?

Everybody who wants to hear, not only consultants, should read this book at least once per year.

Real Lean

I hear a lot of talk about “Lean”, including at this customer. When asked about it, most people will say something about “eliminating waste”. Some may even mention “Japanese”, “flow” or “quality”.

Real Lean is making use of the collective wisdom of everybody in the organisation. Real Lean companies don’t need consultants. Everybody’s a consultant in a Real Lean company.

If you can’t accept failure, you’ll never succeed as a consultant (The Hard Law)

Most of the time, for most of the world, no matter how hard people work at it, nothing of any significance happens. (Weinberg’s Law of Twins)

No matter how many books you’ve read, your advice will be neglected, misunderstood or mis-applied some of the time. Or, more likely, you will give the wrong advice at the wrong time to the wrong person.

There are no perfect consultants. There are consultants who work on easy problems most of the time.

Some of the time, in some places, significant change happens – especially when people aren’t working hard at it. (Weinberg’s Law of Twins Inverted).

Helping myself is even harder than helping others (The Hardest Law)

Everybody who wants to hear or be heard should read The Secrets of Consulting at least once per year.

I’ve just started re-reading it. I rediscover at least one gem on each of its 200 pages each time I read it.

Do you want to be heard?

Do you want to hear?

Christian and Christoph presented the Conflict Resolution Diagram (or “Evaporating Cloud”), a technique to (dis)solve conflicts. I’ve been using this technique for a while, but I still learned something new: stating the underlying assumptions in an extreme way is fun and very effective. These statements ask to be challenged.

More about the Thinking Tools in Bill Dettmer’s “The Logical Thinking Processes“. The book is quite expensive, but the tools are very clearly explained. To make it perfect, I would add more “stories”, show how the tools are used on cases, step by step.