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

At XP Days London I attended an Open Space session on “Estimating Business Value”. Ironically, it was hard to hear the other people in the working group because of the noise generated by the working group next to us discussing “Agile isn’t solving our customers problems because they’re not here“. Yup, we were discussing business value with not a customer in sight or any idea on how we could involve them in the discussion.

The topic of the session was

How do we estimate the Business Value of User Stories?

We didn’t get much result from the discussion. There’s no writeup on the open space wiki. I don’ t know if the organiser of the session got anything out of the session. I didn’t.

First of all, the session never defined what “Business Value” is. That’s the topic of a later blog post.

Secondly, I don’t think you can get a good answer to that question because it’s the wrong question.

Why is this the wrong question?

Because it presupposes that we first write User Stories and then estimate their value.

If we don’t know the value of the stories, we risk writing a lot of low (or zero) value stories. And many teams do. We write lots of User Stories in the hope of discovering the high value ones. We end up with a lot of stories that then have to be prioritised, valued, estimated and managed. Portia taught me a colourful description of this result: a Vomit of User Stories.

What are the consequences of a Vomit of User Stories?

We spend a lot of time on them:

• user story telling meetings
• user story cost estimation meetings
• user story value estimation meetings (that’s the meeting where we force our product owner to put a value number on the user story)
• user story planning meetings

Just to decide what gets done in the next iteration.

If we estimate and track tasks, not stories, we need to add

• task breakdown meetings
• task estimation meetings instead of story estimation meetings

Add to that

• an iteration retrospective
• a mid-iteration review
• a show and tell meeting
• daily standup meetings

Meanwhile, there’s “backlog grooming” going on. It’s a wonder anything gets done in an iteration!

Indeed, I’ve heard many managers and developers of companies that have started with Agile complain about the many meetings. They feel that they’re not getting much done.

So, what’s the correct question then?

How do we find the User Stories that deliver the Business Values?

That presupposes a different process: one where we first define what Business Values we intend to achieve and then generate those User Stories that contribute to the Business Values.

That should be a no-brainer, right?

• We first decide what values (or benefits) we want to achieve before lauching a project or product
• Then we find and improve the business processes that deliver that value
• Then we find and improve the supporting business processes that make the value-delivering processes possible
• When the team needs user stories, we take the highest value processes and break them down into user stories at the right level of granularity for the team’s needs. The team pulls the stories, so we only generate a minimal set of user stories.

The User Stories that implement those business processes clearly contribute to the business values, otherwise we wouldn’t even have considered them.

What’s the value of an iteration?

We keep talking about value and business value, but for our customers there’s no value delivered by iterations. They see real value when the product (and that’s not just software, despite “Working software over comprehensive documentation”!) gets released into the hands of users. Iterations (more correctly: timeboxes) are a useful project management tool, no more.

What’s the business value of a story?

I don’t think it matters much.

Why do you want to know the business value of a user story?

• It’s no longer needed to eliminate zero or low value user stories, because we don’t create or consider them at all.
• Another use could be to prioritise user stories by business value in a release or timebox. If we’ve already prioritised the business values and the processes that deliver them, we need to make sure the processes are implemented completely. So, I’d schedule user stories in such a way as to finish the high value processes as soon as possible and have as few processes in progress as possible. Other considerations, like dependencies, constraints, risks and real options, will weigh much more heavily when scheduling.

Why else would you want to know the business value of a user story?

I see no need to put a Business Value number on User Stories.

In the end, the customer doesn’t care about the allocation of user stories to timeboxes. They care that the selected business values are delivered in the release.

Asking the right question

Before we can find the right User Stories, we first need to ask our customers

What are the business values, the benefits, you need to achieve with this project or product? And how will you know you got them?

So, instead of inviting your customers to XP Days, why don’t you go to them and ask some questions? Asking questions is simple, but not easy.

Do you know what values your work is going to deliver? Do you know how your work delivers those values? If not, why are you doing this project? Why are you being paid?

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.

The moment comes nearer when I have to decide which Agile 2009 sessions I want to attend. With so many sessions, the choice is difficult. So, let’s start by making a shortlist.

Monday

Morning:

• 11:00-12:30 “Agile Grows up: The Agile Business Analyst” (Columbus IJ) by Steve Adolph because I believe that an Agile Business Analyst can help find more value.
• 11:00-12:30 “Developing Agile Leaders and Teams: A Developmental & Transformational Path” (Columbus GH) by Gilles Brouillette because we need to form tomorrow’s leaders if we want our agile improvements to endure when we leave the customer.

Afternoon:

• 14:00-14:45 “New Approaches to Risk Management” (Grand Ballroom) by David Anderson because risk management is how we reliably increase our chances of success.
• 14:00-15:30 “Advances in Release Planning” (Crystal A) by Jim Highsmith because most customer want, need and deserve to know “when will it be done and what’s this going to cost me?”
• 14:00-17:30 “Creating Agile Simulations and Games for Coaches and Consultants” (Columbus GH) because I get paid to make games and play them. It is a long session, though.
• 14:00-15:30 “An introduction to Agile Through the Theory of Constraints” (Grand Ballroom B) by JB Rainsberger because ToC is a powerful tool to understand and improve processes, as we’ll show in our Bottleneck game on Wednesday morning.
• 16:00-17:30 “Mapping the Agile Enablement Battlefield” by George Schlitz and Giora Morein because we need to understand the dangers that agile teams face.
• 16:00-17:30 “Team Start-up: one of the first Agile Adoption activities” by Lyssa Adkins because the first few days with a new team can make a world of difference in the end.
• 16:00-16:45 “Giving and receiving effective feedback” by Liz Keogh because I listen to feedback but don’t always hear it.

Tuesday

Morning

• 11:00-12:30 “Don’t Sell Buzzwords to Business Leaders, Learn How to Describe Real Value” (Toronto) by Richard Sheridan and Clement Goebel because I want to get better at describing the value of projects and change.
• 11:00-12:00 “The Beer Game with Agile Teams – MIT Game Theory in Agile Project Management“(Regency A) ‘by Tom Looy because of the mix of systems thinking, lean and agilee.
• 11:00-12:00 “Risk and Risk  Management – Theory and Practice” (San Francisco) by Chris Matts and Todd Little because I want to learn more about the practice of risk management from two different fields.
• 11:45-12:30 “Top Ten Tips for Agile Coaches” (Regency B)  by Rachel Davies and Liz Sedley because I want to share coaching stories with the authors of the Agile Coaching book.

Afternoon

• 14:00-17:30 “Barely Sufficient Portfolio Management” (Crystal C) by Todd Little and Kent McDonald because this seems complementary to our own “The Business Value Game: How to build and use a Business Value Model” game and approach on Wednesday afternoon.
• 14:00-15:30 “Facilitation Patterns and Antipatterns” (Regency A) by Steve “Doc” List because I fear I know more antipatterns than patterns.
• 16:00-17:30 “Diagrams for understanding and improving Agile practice” (Atlanta) by Bonnie Aumann and Arlo Belshee because of the systems thinking approach to understanding and explaining agile practices
• 16:00-17:30 “How to Develop Your Leadership Power Daily: An Agile Approach to Growth” (Regency A) by Chris Avery because I regularly use Chris’s Responsibility Model and this session proposes some new problem solving methods

That’s a lot of options!

Many options means I have many choices to get value for money.

As Portia says: “It’s always better to have more options than too few.”

Choosing is for later. First let’s go see some of Chicago and fulfill some of the acceptance criteria of my “tourist” User Story.

TO make the long trip worthwhile
AS A tourist
I NEED to see or do things that are uniquely of Chicago

Acceptance tests:

• Have I seen “Nighthawks”?
• Have I seen one building or exhibition that’s unique for Chicago?

Imagine this situation: the CIO of a large company decrees that from now “all applications we develop must be browser based“. This becomes a non-negotiable constraint for every new project.

Unfortunately, a browser platform is not the best platform for all types of applications or all environments. A browser based application may not deliver the best user experience or support intensive workloads. It may be hard (or impossible) to access peripherals. It may be impossible to clearly show complex data sets. And when the network goes down, everybody’s work grinds to a halt.

But all the nice developers and project managers say “Yes boss!” and struggle to find workarounds for these difficulties, to satisfy the users. All of these workarounds make development and maintenance more complex. Users make do with what they receive and add more workarounds to deal with the deficiencies in the applications.

The real requirements

What he really meant was that from now on “all applications we develop must run on a small number of standard environments, be easy to deploy to all our users and centrally managed so that development, release and application support costs stop growing.” What’s the difference between this statement and the previous one? This statement sets a goal and constraints within which creativity can flourish. The first statement stifles creativity and stands in the way of achieving the real goal.

How do we find out what the real goal is? Because someone had the courage to ask “Why?” until it was clear what value we were generating for whom. As the “Discovering Real Business Requirements for Software Project Success” book says:

A requirement describes some value we need to deliver to someone.

Do your “requirements” fit this definition? Why not?

The value of analysis

The difference in value and cost can be staggering. The first statement costs the company lots of money and frustration from everyone who uses, develops and supports hobbled, complex applications. It’s a world of compromises. It doesn’t have to be this way. The second statement gives us a fighting chance to achieve the goals.

All it requires is someone to play the role of analyst to help the customer clearly describe what they need. Someone who acts like a detective to discover the real motives and issues.

A good analyst creates options and keeps them open as long as possible. The “Discovering Real Business Requirements for Software Project Success” book helps to get to the core of the problem. This fits well with a quote from “The Toyota Product Development System: Integrating People, Process and Technology“:

• Classical product development reduces the number of solutions early.
• Lean product development reduces the number of problems early and leaves as many solutions available as possible, for example by set-based development or by using tradeoff curves.

Is there someone who has the courage and skill to ask the right questions? Who has the tenacity to dig until they find the real business requirements?

The first XP book was very important for me. It changed the way I work. It changed my life.

I still apply the practices to improve the way I work. The principles have helped me to make my work more fun, sustainable and successful. The values have helped me to do worthwhile work that delivers value.

But “Embrace Change“? I don’t like change.

How to avoid change

I avoid change on my projects by

• Really understanding the needs of customers, stakeholders and users. Those needs change from time to time, but not very frequently if we really get to the core of what these people value. I get accused of doing Big Upfront Design or Analysis, even in companies seemingly doing Waterfall. Why waste so much time upfront, can’t we start building yet? Customers don’t know what they want anyway, so why try to discover what they need?
• Not committing to decisions too soon, applying Real Options. If we commit later by delaying decisions to the last responsible moment and gather more information, we need to come back on fewer of our decisions. I do get called a procrastinator. Real leaders take charge, take decisions!
• By not being distracted by useless technology churn. Simple, reliable and known tools and technology in our toolkit let us concentrate on adding value. I do get called a dinosaur, not up to date with the latest framework or fad du jour. Real geeks only work with the latest 0.1 version of technologies that are so complex that we can spend months unraveling their intricacies (and bugs). I need a well-padded resume with all the latest technologies to get that next job when the shit hits the fan on this job.
• By making sure we consider supporting processes and users in our value analysis. All too often we focus on the shiny business value generating processes but forget that these can’t work unless people can perform the unglamorous supporting jobs that make these value streams possible. I do get called a Waterfall analyst, who wants to explore every nook and cranny of the system before we can start building. Real Agile teams deliver Business Value, cash quickly. Why waste time with non-business value-adding processes like getting the product into the hands of the user or managing the system to keep it relevant?
• By making a plan (not a schedule) of the goals we want to achieve in the future so that we have a guiding vision when we travel the path. I do get called an old-school project manager who wants to control and stifle the creativity of his “resources”. You can’t be agile if you have a plan.

Projects with fewer changes are a lot easier and less stressful than those with many changes. These projects implement Heijunka. They deliver value surely and steadily. I like that.

Embrace risk reduction and new information

I welcome any change which reduces risk. We continuously identify our main risks and find ways to avoid them. For example, we discover that there’s simple alternative way of doing something. We can use that as our backup strategy if the planned way of doing the work doesn’t get ready in time. For example, we first implement a very basic implementation of a business process and iteratively refine it, so that we’ll always be ready to release by the deadline. Of course, we have to use that extra time that Real Options gives us to actively seek out information and reduce risk.

Embrace increased flow

I welcome any change which can increase flow, get us to release faster and get the cash flowing sooner. For example, we can start by statisfying a subset of stakeholders and users. We can focus on on value stream at a time. We can mercilessly pare down what is really needed to achieve goals. We can get rid of wasteful checks, approvals and delays. We increase quality to decrease changes due to rework.

Embrace value increase

I welcome a change that increases value. For example, “Exchange Requests” let the customer increase the value of our work. If the customer wants to add a feature to a release, they first have to remove an equivalent amount of work from the release. The customer will only perform the swap if the new feature has more value than the one swapped out. So, for equal (or lower) cost, we deliver a product with higher than initially expected value.

Embrace cost and investment reduction

I welcome a change that reduces cost or investment. I welcome a new, simpler way of achieving a goal. I welcome reducing scope as we discover that we can simplify business processes. I welcome a reduction in “dimension” as we discover that we can satisfy user needs (for now) with less exhaustive or refined implementations. I welcome a way to reduce the amount of work in process.

I’ll get me coat then…

Can I be Agile if I don’t Embrace Change? Can I be Agile if I value people and their interactions AND processes? Can I be Agile if I insist on customer collaboration AND a contract?  Can I be Agile if I only want to respond to beneficial change AND follow a plan? Can I be Agile if working software is not the solution or only a small part of the solution? Can I have my cake AND eat it too?

Where do I go to hand in my Agile badge?

If anybody needs a Waterfall coach, let me know. I can change. I’m agile

Like this?

Like this?

Like this?

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

Freedom Evolves

Portia, Vera and I have published a new version of the Agile Coach website. There you’ll find coaching tools we use like games, tutorials and presentations. Topics range from introductions to Agile (the XP Game, the Business Value Game, XP Loops, First Five Steps to Become Really Agile), Theory of Constraints, Real Options, Toyota Way, Interviewing techniques to Agile Fairytales.

More materials and translations will be added. All of these games are licensed “Creative Commons“, so that you can use and reuse them. If you want to help translate or improve the games, let us know.

We run retrospectives after each session so that we can improve. You can read the results of the retrospectives on the Past Events page. This transparency allows you to verify if we really take the feedback into account.

Come and play at XP Days

If you want to play the “Business Value Game” or “Mirror, Mirror on the Wall… Why Me?” come and see us at the Mini XP Day Benelux in Mechelen, Belgium (May 11th) or XP Days France in Paris, France (May 25-26th). Or invite us to come and play in your company or usergroup. Or better yet, download the games and play them yourself.

This Friday, Portia and I will present the “Real Options Space Game” at XP Days London. This strategy board game set in space allows players to experiment with Real Options concepts.

Real Options is a tool to optimize decisions: it helps us to consider and manage more possibilities and gives us more time to gather information, so that our decisions are better informed. The basic ideas are taken from financial options, but have been widened to be applicable to real-world management decisions.

There are several types of Real Options. Let’s see if the option metaphor is a useful one. How can we apply Real Options in the real world?

The option to delay a project

In this paper, Aswath Damodaran compares a Net Present Value (NPV) analysis with a Real Options analysis to decide which projects to fund when. Projects with a negative NPV now, might still become valuable later. That’s because the Real Options analysis takes into account the value of getting more information and therefore reducing risk and uncertainty.

We always have the Learning Option. We can always gather more information.

In the article, the delay is examined in a situation where the organisation has (or can buy) a way to get a hold on the market, like with a patent. We can create an option to delay a project even in a competitive market: if we have a shorter cycle time than our competitors we can afford to wait longer to start our projects. This gives us more time to gather market information. In a very volatile market, it can be more valuable to wait, to increase the odds of building the right product at the right time.

For example, if Toyota’s new product development time is 6 months shorter than a competitor, Toyota can afford to start development 6 months later. That’s 6 months in which to gather more information, six months in which they could see major swings in customer demand or in the market. That’s six months in which people can work on other projects.

So, if you decrease your cycle time you create options to

• Increase your cash flow
• Be first on the market
• Delay the project, take the go/no go decision later, when we have more information

By using Lean and Agile methods to decrease cycle time, we create real options. Starting later may be the right thing to do.

There are more fun real options, like the option to abandon a project. What could be the value of abandoning a project?

Real Options Space Game

Do you want to prevent galactic war? Do you have experience flying spaceships in dangerous corners of the universe? Not afraid of space pirates and angry aliens? Then sign up for the Real Options Space Game at XP Days London. The pay isn’t great, but the benefits more than make up for that.

The Real Options Space Game is a board game for 6-13 players that lets you play with Real Options concepts. Portia and I will be running two games in parallel (in parallel universes?), so that we can compare many different strategies, a sort of set-based design.

In the game, pairs play the crew of a spaceship who must transport a precious cargo from one end of the galaxy to another. On the way, the crew has to deal with risks such as attacks by space pirates, strikes by disgruntled transport workers, disputes between different alien races, technology breakdowns and more bizarre plot twists. And they have to do it with limited resources and time. Sound familiar?

What are Real Options?

Real Options is a decision-making tool that, like so many of these tools, looks deceptively simple. It’s just common sense, most people respond when we first explain the concepts. But we quickly see that these simple concepts aren’t applied. We can explain Real Options until we’re blue in the face without any effect. You have to experience how to apply the tool under (simulated) pressure to realize if and how Real Options are useful.

Real Options consists of two components:

• The concept of options. Each option has
  • A value
  • A buying and exercising cost
  • An expiry condition which determines when the option becomes useless

• A process to deal with options:
  • A way to determine the last moment when we have to take a decision and commit ourselves
  • Keeping as many options open as long as possible
  • Actively seeking out more information and more options in the time before we have to commit

Unlike with financial options, we often don’t have exact numbers for cost and value. Most of the time we don’t need the numbers, we only need to know which of two options has a higher value or lower cost.

And what does that have to do with XP and Agile?

You can apply Real Options in just about any situation where you’re faced with difficult decisions. Once you know the concepts, you see options everywhere.

Real Options underlie some of the tricky Agile and Lean practices. By working with short releases and user stories that are elaborated during a release, we push back the moment of difficult decisions, so that we have more time to gather information. By using good engineering practices (TDD, refactoring, continuous integration…) we lower the cost of changes and decisions, again pushing back the moment of decision. Meanwhile, we have more options open for the direction of the application. Set-based design is an economical way of exploring may design options

It all sounds very reasonable to me, but much of the resistance against Agile is about the ideal moment of decision. Most of us feel more comfortable when we’ve made a decision. Having lots of open options may seem like procrastination or even indecisiveness. We feel the need to make that decision NOW, especially when we’re under pressure. Keeping our heads cool and applying the Real Options tool can help us make better informed decisions.

Once we practice Real Options in real life, we start asking “when do we have to decide?” and we look for more options. Try it, practice it, so that you can take better decisions under pressure.

See you at XP Days London, 11-12 December 2008.

The handout for the Real Options session is not yet online, but you can download it from our site.

The last session of the day was our first run of the Real Options Space Game in French. The little skit Portia and I did at the day’s opening must have worked because a lot of people came to the session. This time we had a larger room than the previous session, but still not enough room to seat everybody comfortably. At the previous session at Agile North, we had 28 participants. This time we had about double that number.

We started off with a brief presentation on Real Options. We then explained the rules to the participants, grouped in about 7 teams. Participants first had to plan their route across the game galaxy, using very limited funds. Then, in several rounds, they made their moves from planet to planet. To keep the game manageable, one representative of each team came to sit at the game table. This way, we didn’t have to deal with the whole audience, but only one participant per group. Unfortunately, keeping this large an audience to the game timeboxes proved to be too difficult. Switching between game and reflection was also very difficult. You try to quieten 50-60 players engrossed in the game, trying to win.

After the Agile North session, Portia and I held a retrospective and improved the game. With the changes, we were confident that we could host the game for +/- 30 people. Unfortunately, the changes were not enough to comfortably deal with double that number. Waiting for my train home, drinking a beer at the Gare du Nord I thought of some ways to deal with this large a group. Too late. L’esprit de l’escalier is alive and well.

We will write up the session and publish the game materials, like for the XP Game, so that you can play this game at home and at work.

Despite the noisy and crowded session, the participants did get the message of the session. The groups did a short retrospective at the end, with generally favourable feedback and some ideas for improvement.

Closing drinks

The conference closed. The turnout was a success: participants got good value for their money, lots of contacts were made. Dealing with unexpectedly large numbers of participants proved difficult. The organizers of XP Days France and Benelux will collaborate on ideas to scale sessions.

Portia and I bought a round of drinks and had a bit of time to chat with some participants. My Swiss friends had a bit of interesting news that you’ll hear more about. All too soon we had to leave to catch our trains back to London and Brussels.

XP Days Paris, je t’aime! I had a great time and hope to be back next year. Hope to see you there!