Apr
02

Devoxx FR 2013 presentation available

My Devoxx presentation on Real Options is now available on Slideshare:

Mar
21

Devoxx Paris 2013

Decisions, decisions, decisions

On Friday march 29th I’ll present a session about Real Options and other techniques to take better architectural decisions at a better moment. Billions of years of evolution have equipped us with these wonderfully irrational brains that sometimes get in the way of making good decisions. With a few simple but counter-intuitive techniques we can make our decisions a bit less stressful and more useful.

See you in Paris.

Jun
07

Conf Agile France 2011: Les bases des méthodes Agiles et Lean

Six éléments essentiels

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

Dec
30

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
24

Bottleneck Game at Agile Tour Lille 2009

I present the Bottleneck Game at Agile Tour Lille on October 30th 2009.

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 Bottleneck Game