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

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

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

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

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

In the Business Value Modelling session at the XP users group 6 teams created a Business Value Model for a mobile phone company struggling to keep customers and regulators happy while reducing call center costs. In the final step, each team had to create a poster that they could use to guide their decisions and to explain the reason behind the project.

As you can see from the session feedback everybody wanted to know if they had built the ‘right’ model. Let’s take a stroll through the business value model gallery and see how the teams did. Click on the images to enlarge.

Team 1

This team spent a lot of time discussing and didn’t have much time actually making the diagram. The large yellow Post-its contain the major goals. Small green Post-its are measures of the goal. Are small blue Post-its leading indicators? It’s not very clear. Only two goals seem to be worked out. There are four more large yellow Post-its to the side. What’s their meaning?

To make it perfect:

• Add a legend to the diagram
• Fully work out at least one goal
• A Business Value Model doesn’t have to be “perfect”. Make something quickly and iterate.

Team 2

This team tells a story: we have unhappy customers and we have lots of measures that make that visible (left). We have several measures (both lagging at the top and leading at the bottom) that we can use to measure and drive improvement. Then we have several things on the right that we must comply with, either constraints or non-negotiable goals. All of this should lead to happy people (customers, employees, regulators).

To make it perfect:

• The diagram focuses heavily on the customer. Where are the company, the regulators and the project sponsor? How could you represent their views?
• Does the ordering of complaints have any meaning? If you could do only one thing, where would you focus?

Team 3

This is a very clear and near diagram with a business-like 4 quadrant format. Each of the quadrants represents the view of one stakeholder. I like the big, clear goals on the yellow Post-its. Each stakeholder has both constraints and measurements/tests.

To make it perfect:

• Explain the meaning of the arrows. Am I correct in interpreting it as customers and regulators have goals which drive internal goals of the Operations Manager and IT?
• The IT measurement “daily reporting” isn’t very actionable. What’s in the report?
• The Operations manager measurement “Send confirmation” message sounds more like an action or capability than an measure or test. How can you test that confirmations have been sent? Why will that reduce costs?

Team 4

This team used a concentric circles model: on the outer circle we have the viewpoints of the stakeholders. The pink Post-Its represent a stakeholder goal; the attached blue Post-its are the measures for the goal. I’m not clear what the yellow Post-Its in the center mean. This team added a new goal that wasn’t in the original assignment: “Increase Antenna Coverage”. Apparently lots of people call in to say they can’t call

To make it perfect:

• Show some relationships between the different items so that it clear what belongs where. For example who wants to “Bill correctly”? The customer or the organisation? Who wants to port numbers quickly? The customer or the regulator?
• Explain the meaning of the yellow Post-its in the center
• Instead of the “Atern” Post-its (some leftovers from the Agile Business Conference), draw the stakeholders

Team 5

Another diagram that uses the concentric circles (or maybe a Mandala) idea. At the outside (the small yellow Post-Its) we see the stakeholders. Big bold yellow Post-its show the goals with attached measures. The Blue arrows indicate that achieving some goals helps achieve other goals. Big red Post-its indicate constraints.

To make it perfect:

• Make the stakeholders stand out more by drawing them or having larger Post-Its. Everything we do starts with the stakeholder.
• Add a small legend: for example what are the green lines?
• You don’t have to reuse the Post-its. Why not just redraw the goals and measures neatly?

Team 6

The last team had a completely drawn business value model. The central metaphor of the scales can be very powerful: by working on one side we can influence the other. Here: by increasing usability of the service, we reduce the cost of the service (or “Quality is free“). On the right, we want to reduce the number of people who call in (presumably without reducing the number of customers?). This is done, on the left, by going from a situation with few computers and lots of employees to one where computers have taken over the work. Or, as the team put it succinctly: “the solution is to replace people by computers”.

To make it perfect:

• we have one measure for cost (“# of incoming calls” on the right). How would you measure usability on the left?
• The image on the left (“replace employees by computers”) focuses on the ‘solution’. Can you represent how stakeholders will benefit?
• Replacing employees by computers is (for most people) not a very rousing goal. Is this the first message you want to get across when you explain your project? How do you think those employees feel? You’ll probably have to talk to them to implement the project.

At the end of the tour

What have we learned? A Business Value Model serves several purposes:

• To make it clear why we do the project: which stakeholder goals do we want to achieve?
• To prioritise: which goals are more important than others?
• To have project/product acceptance criteria: how will we know we achieved the goals?
• To show how we will steer the project: what measures/subgoals can we use to go in the right direction?
• To understand what is out of our control: which constraints should we abide by?
• To create a shared model of the important aspects of value and how these aspects affect each other: what is our hypothesis of how we will generate value?

What I look for in a model is:

• It’s clear: legible writing, a legend, appropriate use of colour and size
• It tells a story: “we focus first on <this> and then on <that>”, “if we do <this> it’ll lead to <that>”
• It’s motivating: the goals indicate that we’re making life and work better for people, there’s more than making money
• It’s useful: it helps me ask the right questions like “how is this feature going to help us achieve our goals?”;  helps me to make the right decisions like  “we’ll focus on area A first, because that will help us achieve our primary goal”
• It’s temporary: this is the best model of our system for now; as soon as we learn, we’ll update our model
• It’s shared: the whole team contributes to making and changing the model.

When is the model “done”? Ask yourself:

• Do I want to have this displayed prominently in the team room?
• Do I want to use this as a decision aid?
• Do I want to use this to explain the project to my most important customer or user; to the CFO; to the CEO; to a new team member?
• Do I know how we can test and invalidate the model?
• Do I want to keep this up to date?

See you at the Business Value Modelling session at XP Days Benelux. I’m looking forward to seeing the models that come out of that session.

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

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

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

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

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

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

Agenda:

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

Address: Bessenveldstraat 19, B-1831 Diegem, Belgium

Register here for this free event

XP Days Benelux 2010 will be held in Kapellerput, Heeze (near Eindhoven), The Netherlands on 25-26 November

The program for XP Days Benelux has been published. This year we have more sessions than ever before: 41 sessions over 2 days. As always, it’s going to be hard to select only one session from the five parallel tracks.

I’ll be presenting “Agreeing on Business Value with Systems Thinking” with Portia Tung. I’ll be doing a tryout of this presentation, which has been updated after presenting it at Agile 2010. Come to the Agile/XP Belgium user group meeting on Tuesday 26th of October.

If you want to see a tryout of the “Database Change Management” session, join us in the Agile/XP Belgium user group meeting on Tuesday 5th of October.

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

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…

• In “Pinocchio, On Becoming a Lean Leader” (Tuesday August 10, 13:30-15:00) Portia Tung and I help participants along the dangerous journey from toy boy to real boy. You’ll meet all your favourite characters from this Agile Fairytale and come away with some concrete actions to become a better leader.
• “Agreeing on Business Value using Systems Thinking” (Wednesday August 11, 09:00-10:30) is a workshop where Portia Tung and I help participants come up with a “Business Value Model” for their current project. You’ll be able to use the Business Value Model to identify the high value solutions that satisfy your customers. The number of places for this workshop will be strictly limited to 20.
• “Estimation Games” (Thursday August 12, 13:30-15:00) gives participants some rules of thumb to create reliable estimates with little effort. During the session we’ll play some small estimation games to put the lessons into practice. You need never be afraid again of estimating.

If you want to know more…

C’est la première édition de cette conférence et aussi la première conférence francophone sur l’agilité en Belgique.

“Les Boucles XP” est une introduction à la méthode Extreme Programming. Vera Peeters et moi avons créé cette présentation il y a longtemps pour donner un goût de la façon de travailler d’une équipe vraiment agile. A travers les pratiques et les exemples d’équipes avec qui nous avons travaillé depuis 1999, la présentation explique pourquoi cette méthode marche et comment procéder pour définir une méthode qui convient à votre équipe. Pour cela, il faut voir les choses comme un système où la valeur du tout est bien plus que la somme des valeurs des éléments.

“Agile + Business Analysis = Lean Projects” explique comment on peut combiner les techniques de Business Analysis avec ceux des méthodes Agiles pour “construire la bonne chose” et “construire de la bonne façon”. Le résultat: des projets vraiment “Lean”, de la demande du client jusqu’à la livraison. L’expérience nous a montré que cette combinaison nous a permis de livrer des projets en beaucoup moins de temps qu’auparavant et en même temps livrer un produit qui avait plus de valeur que prévu. Vous verrez quelques techniques que vous pourrez appliquer dès demain et des pistes pour en savoir plus.

A bientôt!

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?

Portia Tung and I will co-present “Pinocchio: On Becoming a Lean Leader” at the SPA 2010 conference in London on May 18th 2010.

Come and play with us to sharpen your leadership skills!

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 learn how we’ve applied the Toyota Way management principles to introduce Lean and Agile methods in such a way that the companies can sustain the change.

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

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

What Went Well

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

What Went Wrong

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

Puzzles

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

Lessons Learned

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

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

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

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

Why do you visualise these things?

The goal is to take action

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

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

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

A visualisation without actions is just a pretty picture.

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

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

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

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

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

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

Visualise to show the need for action

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

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

That same day the decision was taken.

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

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

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

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

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

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

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

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

What can I do?

Have a look at all the visualisations your team uses.

If your team has none, ask yourself:

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

If your team has visualisations, ask yourself:

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

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

The laws of Visual Management

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

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

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

Where do you start?

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

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?

Would you rather be a member of a Cost Centre or of a Value Stream?

Even if you don’t know exactly what each term means, where would you rather work?

Which of the two would focus most on the customer?

Which of the two would be more open to Agile, Lean or continuous improvement?

Accounting matters. Not just for the numbers, but also for the words.

When was the last time you talked to your accountant or CFO?

How many times have you heard this apology? Often, the apology is “The system is down again.” In some places the system is always down around certain times and you get the same apology every day.

Why are we suprised when systems are unavailable? There will be bugs, mistakes and scheduled downtime. We should not be suprised the system is down, we should expect it.

Some time ago, an IT architect asked me during a job interview if it was possible to build reliable systems out of unreliable parts. My response:

The only way to build a reliable system is to build it out of unreliable parts (or systems)

If you want to build a reliable system, you have to be aware that all its subsystems are unreliable. This allows you to take appropriate measures, like building in redundancy.

We need a paper process

A smart manager I once worked with insisted that every business-critical automated process also required a backup “Paper Process”.  The Paper Process defined how the work would be done when (not if) IT systems were down, with nothing more complicated than pen and paper (and a battery-powered calculator if really needed). When systems were unavailable everybody knew what they had to do to keep the business ticking over as if nothing happened. They also knew how to catch up when the systems were available again. In this case, it was clear who the bottlenecks were, so the other people subordinated by entering the backlog of data on paper into the system. Did I mention that this department used less automation than other similar departments, yet had a better track record of delivering on time,  was more efficient and brought in more money?

Defining an alternative Paper Process was relatively easy, because we really understood the real business requirements of our customer. Since then I use this as a test of my understanding of the real requirements: could I implement the requirements with nothing more than paper and pencil? If you have real requirements (and not a solution in disguise) it’s easy to define several different implementations.

Since that project I learned more about processes. If I had to do this project again I would do it the other way round: implement the Paper Process first and ask what, if anything, we would need if the Paper Process broke down. Maybe a whiteboard is enough.