|
|
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
Résoudre les conflits sans compromis
La semaine passée j’ai présenté comment résoudre les conflits avec le “Diagramme de Résolution des Conflits” à la Conférence Agile Paris. La présentation est disponible ci-dessous. Plus d’informations sont disponibles sur le site Agile Coach.
A la fin de la présentation il y a deux questions pour voir si vous avez compris la leçon:
- Est-ce qu’il est possible de former un gouvernement belge avec cet outil? Si oui, pourquoi? Si non, pourquoi pas?
- Est-ce que vous pouvez résoudre ce conflit récurrent entre Product Manager et Développeurs:
- Le Product Manager a besoin d’estimations et de planning très détaillé et fiable pour publier une roadmap qui dit quand quel fonctionnalité sera livrée quand ET livrer ces fonctionnalités comme promis
- Les clients, qui souvent sont des grandes entreprises avec plusieures filiales dans les monde et beaucoup d’utilisateurs, ont besoin de cette roadmap pour planifier quand ils vont implémenter une nouvelle version
- Les Développeurs sont “passés au Kanban”: ils ont arrêté de faire des estimations ou des plans. Cela prenait beaucoup de temps et ce n’était jamais correct.
- Les Développeurs “éliminent le gachis” parce qu’ils doivent aller de plus en plus vite pour satisfaire les requêtes d’un nombre de clients qui toujours croissant.
- Tout le monde veut livrer les fonctionnalités au client au moment où les clients attendent ces fonctionnalités.
Vos réponses et questions dans les commentaires…
D’abord essayez de clarifier le conflit.
Puis, découvrez les suppositions derrière chaque étape du raisonnement.
Translation
I presented an interactive tutorial on how to apply the “Conflict Resolution Diagram” at the French Agile conference in Paris. You can see the English version of the presentation at the Agile Coach site.
At the end of the French version of the presentation there are two tests to see if participants understood the tool:
- Can you use this tool to form a Belgian Governement. If yes, why? If not, why not?
- Can you resolve this common conflict between Product Manager and Developers:
- The Product Manager needs detailed estimates and accurate planning because she has to create a long-term roadmap which spells out which features will be delivered when AND deliver those features when promised to keep customers’ trust
- Customers, who are typically large multi-site companies with many users of the product, need the roadmap because they need to plan when they will roll out which version throughout the enterprise
- Developers have “gone Kanban” and have stopped estimating and planning because the estimates took too much time and were incorrect anyway
- Developers stopped estimating and planning to decrease waste so that they can keep up with the increased demand for features from the increasing user base
- The whole company wants to deliver the features customers ask for when customers expect them.
Answers on a postcard or a comment…
First, try to clarify the conflict.
Then try to find the assumptions behind each step of the reasoning.
Playing The Bottleneck Game
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:
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.
 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
Parallel evolution
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 
  
|
|
