Jun
09

Lean & Kanban Europe 2010

I’ll present “Lean out your product backlog with lean product development and business analysis techniques” at the Lean & Kanban Europe 2010 conference.

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.


Lean & Kanban 2010 Europe Speaker

Jun
08

Université du SI 2010

I’ll co-present a session with Christophe Thibaut about the “A3 process” at the Université du SI conference on July 1-2 in Paris.

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…

Jun
07

Agile 2010

I’ll co-present three sessions at this year’s Agile 2010 conference on August 9-13 in Orlando, Florida:

  • 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…

May
27

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
29

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?