lean « Thinking for a Change

May

Journée Agile Belgique 2010

Je présenterai deux sessions à la conférence Journée Agile 2010 à Gosselies (près de Charleroi), Belgique ce 16 juin.

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!

Jan

Value in Lean

In search of Lean Business Value

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?

Jan

Pinocchio at SPA 2010

A Fairytale about Lean Management

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!

Dec

How do you estimate the Business Value of User Stories? You don’t.

Estimating Business Value

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?

Oct

Toyota Way at XP Days Benelux 2009

Portia and I present the “Toyota Way Management Principles to Sustain Lean and Agile” at the XP Days Benelux 2009 conference.

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.

Thinking for a Change

Categories

Blogroll