Procastination and Responsibility

A short discussion with Christopher Avery (The Leadership Gift TM) about the Responsibility Process TM and Procastination

  • pierre_fauvel:@ChristopherAver I see a deep link between procastination and responsibility process. What do you think ?
  • ChristopherAver:@pierre_fauvel Yes, of course. Say more? How does The Responsibility Process inform procrastination?
    • pierre_fauvel:@ChristopherAver i feel that procastination lasts when you don’t fully take responsability, perhaps by fear of difficulty.
      • ChristopherAver:@pierre_fauvel That is well said. We see procrastination as a natural effect of Obligation. The individual could use better goals.
        • pierre_fauvel:@ChristopherAver i see also shame ( i don’t feel able to do it so i am stressed so i postpone the start )
          • ChristopherAver:@pierre_fauvel I can see that.
            • pierre_fauvel:@ChristopherAver As a procastinator how can i overcome faster those steps that prevent me to take action sooner ?
              • ChristopherAver:@pierre_fauvel Better goals. Find goals that support WHO you really are, WHY you are here, HOW you want to experience life.
                • pierre_fauvel:@ChristopherAver In other words : step back to jump into action quicker ;-
                  • ChristopherAver:@pierre_fauvel yes. If you are procrastinating then you don’t really really want what you think you do. Confront your intentions.
                    • pierre_fauvel:@ChristopherAver it has something to do with limitating beliefs, with actions taken more to reduce fear than to be really useful.
                    • pierre_fauvel:@ChristopherAver it has to do with improvisation : i am afraid of being not prepared but i am convinced that preparing too much is wrong.
                      • ChristopherAver:@pierre_fauvel So your advice is « do nothing »? That’s a Control Cycle event. #LeadershipGift
                        • pierre_fauvel:@ChristopherAver « trust yourself, you will start unconsciously when it is time, don’t fear to be late, start urgent things instead ».
Publié dans _ | Laisser un commentaire

is Kanban Method an Agile Method ?

A very intersting discussion on Twitter the 09/05/2016 with David J Anderson, founder of the Kanban Method

  • pierre_fauvel:@lki_dja perhaps stupid but frequent question : is Kanban Method an Agile Method ? I’d say there are common parts and different parts
  • lki_dja:@pierre_fauvel hence, #kanban is « the alternative path to agility »!
    • pierre_fauvel:@lki_dja What is the position of Kanban about the agile manifesto ?
      • lki_dja:@pierre_fauvel before you charge people for professional advice about #kanban perhaps you should attend some training? KMP & KCP classes
        • pierre_fauvel:@lki_dja good point ;-) at the time being the question is about the choice of the method
          • lki_dja:@pierre_fauvel #kanban vs #agile method is a false choice. It’s capability to evolve your own vs adopt defined/prescribed process
            • pierre_fauvel:@lki_dja big industrial companies like predefined processes. At least in France
              • lki_dja:@pierre_fauvel yes, industrial mindset. Because they like it, doesn’t mean it will work.Professional services/knowledge work needs new ideas
                • pierre_fauvel:@lki_dja agreed. But to sell it, surfing on the agile wave can help. Thus deguising Kanban in agile clothes.
                  • lki_dja:@pierre_fauvel yes. that is a valid approach used by many coaches/consultants
      • lki_dja:@pierre_fauvel I don’t understand the question? Can you rephrase?
        • pierre_fauvel:@lki_dja as a Kanban referent, would you sign the agile manifesto ? Do you share agile values and principles described in it ?
          • lki_dja:@pierre_fauvel see my Agile 2008 conference Mainstage video for an answer to this question
          • lki_dja:@pierre_fauvel I don’t think you quite understand, I was there before we called it #agile. I was also at the 10 Year Anniversary in Snowbird
            • pierre_fauvel:@lki_dja let me reformulate. You were part of something. Part of it became agile methodologies. You continued a different part, Kanban. ?
              • lki_dja:@pierre_fauvel « an alternative path to agility » a method that let’s you evolve your own uniquely tailored processes specific to your context
                • pierre_fauvel:@lki_dja if i have 100 teams in a company i have 100 contexts ?
                  • lki_dja:@pierre_fauvel 100 teams could be 1 context collaborating together or 100 contexts or anything in between. ~10-20 maybe typical
                  • lki_dja:@pierre_fauvel depends. Do the teams collaborate on same customer service delivery and workflow? Context is a business context
                    • pierre_fauvel:@lki_dja lets consider for the discussion that they don’t. They adress different, separate business needs.
                      • lki_dja:@pierre_fauvel you should consider reading my #kanban & Lessons in #agile management books, taking @leankanbanu training. These will help
                        • pierre_fauvel:@lki_dja I’ve read the kanban book (with interest). I should start the other one ;-) do you plan a third ? The first was clear & synthetic
                          • lki_dja:@pierre_fauvel I plan several more. I have several partially complete. Dealing with your industrial context is a topic I need to address
                      • lki_dja:@pierre_fauvel then you have 100 contexts. You could have 100 unique process definitions. Each will evolve on its own
                        • pierre_fauvel:@lki_dja our quality controllers won’t like that. 100 different ways to control !
                          • lki_dja:@pierre_fauvel learn to control with fitness criteria metrics not through process compliance
                            • pierre_fauvel:@lki_dja thats a transformation !
                              • lki_dja:@pierre_fauvel I’m sympathetic to your situation. I’ve seen it many times before. I must address with new guidance. Thanks for inspiration
                                • pierre_fauvel:@lki_dja thx for the time you took for this discussion. Would you allow me to relate it in my blog ?
                          • lki_dja:@pierre_fauvel try @ChrisAch’s #kanban Kickstart Guide. Consider taking @leankanbanu KCP class & visiting our Retreat in Barcelona in July
                          • lki_dja:@pierre_fauvel as a crutch the work of @ChrisAch will help you. He also works in a big industrial context
                          • lki_dja:@pierre_fauvel you need to get them out of the industrial mindset. There is no economy of scale in professional services
                            • pierre_fauvel:@lki_dja +1
              • lki_dja:@pierre_fauvel « an alternative path to agility ». An approach that gives you the benefit of outcomes without the pain of change/adoption
              • lki_dja:@pierre_fauvel by 2003, I recognized that resistance to adoption of #agile methods hindered scaling. I looked for an alternative
                • pierre_fauvel:@lki_dja so you adopted an evolutive framework to ease adoption ?
                  • lki_dja:@pierre_fauvel I adopted an evolutionary approach because it gets you to the desired business outcome much faster with lower risk
    • pierre_fauvel:@lki_dja my customer is doing an « agile transformation » however i would advise Kanban in some cases (run) and agile in other(build).
      • lki_dja:@pierre_fauvel i don’t understand what « (run) » or « (build) » means in this context. #kanban is the antithesis of #agile transformation
        • pierre_fauvel:@lki_dja build a new application (from scratch) vs run an application ( fix bugs and add evolutions )
          • lki_dja:@pierre_fauvel why would you give that advice? because #agile methods are easier to adopt? Do you need optionality in your « build » process?
            • pierre_fauvel:@lki_dja i think i would need optionality
              • lki_dja:@pierre_fauvel then a #kanban system gives you an advantage. Have you read my Tyranny of Ever Decreasing Timebox blog post?
Publié dans _ | Laisser un commentaire

The Customer Voice : Black Box Agile

I am a customer. Software is not my job, but I need software for my business. I heard about agile, and I have bought the concept. I consider asking your company to write software for me. Thus…

  • I expect from you a good understanding of my business, my context, my requirements. I commit to spend all the time needed to explain it. As a matter of fact, I commit to tell everything which is needed to any relevant person, but I want to have direct access to the team members (even if they are subconstractors distributed all around the world)
  • I want to trade changes, switching User Stories based on their estimates, and I want you to be able to accept change all along (even if we are in a fixed price contract, you have to allow change). I will only accept objections based on cost, not on the fact that we said something different a few monthes ago.
  • I can understand that you have technical (or other) constraints, but I wan’t you to deliver value to me on a regular basis. You will demonstrate your software regularly and you will give me access to an environment were I can test it (I don’t care were it is or who is hosting what).
  • I expect us to meet regularly to find ways of improvement, on both side and as regards to our cooperation. I expect transparency and openess.

I don’t know much about software, it it like a black box for me, but I want agile properties. By the way, I am wondering : wouldn’t it be simpler if we were just a co-located, agile team working at my place, and in Time & Materials contract ?

Publié dans _ | Laisser un commentaire

How to compose a Minimum Viable Product

The concept of « Minimum Viable Product » (MVP), defined in Lean Startup, is becoming more and more popular. What should we do in the next release. In Eric Ries book, the answer is two-fold : we should bring value to the customers AND learn as much as possible about our market.

In our projects, the criteria of selection in the minimum viable product is thus :

–          Bring as much value as possible (I mean economical value)

–          Learn, about the future acceptance of the business process we intend to deploy or about risks

We score every user story with a value (from 1 to 10) and we include has much user story as we can in the MVP, based on estimates.

Well, in fact, we score every features, not user story. Some user stories have no meaning alone, and can only be considered as a part of a whole.

Well, in fact, sometimes we split features, because user stories don’t have the same level of priority / of value, and if we really want user story 3.5, 3.6 and 3.8, we can wait for user story 3.7 and 3.9, so they become part of a new feature.

Well, in fact, based on Impact Mapping, we prioritize Impacts we want to have on the way people work (do the closing in one day) more than features needed to have this impact (automate the consolidation)

But that’s not all. Let’s talk about MoSCoW and Kano.

MoSCoW is a classic way to prioritize impacts : Must-Have, Should-Have, Could-Have, Won’t Have.

Kano is a more elaborated way to prioritize impacts: You answer two questions for every user story : “What if we get it ?” and “What if I don’t get it ?”. Based on the answers, you can categorize your features :  basic (I need them but they don’t bring satisfaction), linear (the more I get them, the more I am satisfied) and delighters (I can live without them, but I will be excited if I get some).

Merging both approach, I would say : for an MVP, define Must-Have based on a mix : 70% basic, 20% linear, 10% delighters. Do the same with the remaining features for the Should-Have.

diagramme kano-moscow

The iPhone was launched without basic feature but with delighters, for instance, and it was a success.

There is a gap between the value of the impact perceived by the sponsor of the project AND the perception by end users. It is necessary to spoil some money on delighters, to get enough adhesion from the end users, i.e. to ease change management.

In summary : a product is a set of features, bringing a set of impacts. This set is built around value, but with adjustments, selecting impacts with a bit more complexity than just taking high value scores only.

Publié dans Agile | Laisser un commentaire

What is a retrospective ?

During a coaching session with @MaLainDa we had a short discussion about retrospectives. What is a retrospective ? More than that, why do we run and enjoy retrospectives ? What is at stake ? What happens ?

Is it a way to solve problems, by zooming on key issues during the session, taking sometimes the time to run a root cause analysis to take the most efficient actions ?

Is it a way to share risks evaluations, and to start mitigation actions ?

Is it a way to learn, to improve the commonly accepted model of the project : the goals, the people, the constraints, the strategy, the agreed way to proceed (the best we can think about), the communication means and paths, event the history of the project…?

Is it a way to align every body on the necessity to improve, at every level ? To share improvement axis ? To share ambition levels ?

Is it a way to build the team, by showing and feeling that every voice has a value, that every demand can be expressed and will be listened to ?

Is it a way to heal the wounds and share the emotions raised by events lived together ( efforts, failures, successes ) ?

Is it the time when to solve untold resent and personal conflicts before it is too late ? The 5 whys used by root cause analysis can be very incisive when it comes to go beyond the “it’s not me it’s him” stage. The human system is at fault, not its members.

It is all that. It is a priviledged moment where the whole team stops building, steps back, and thinks to whatever is needed for the team to work better. It is my favorite moment to coach the team as a group, by making sure that the group thinks at its best towards a greater performance. When my time on a project runs short, it is the last ritual I stop attending as a coach.

See Esther Derby, always sharp, about running rich retrospectives.

Publié dans Agile, English, Humain, Pensée | 1 commentaire

Traduction : Organiser pour la complexité

Nous avons traduit
« Organiser pour la Complexité » du BetaCodex Network
avec @SylvainPAM18 et @FranckDepierre

Publié dans Entreprise, Humain | Laisser un commentaire

La fourchette thérapeutique du #Coaching #Agile

Il existe pour certains médicaments une fourchette thérapeutique, c’est à dire 2 seuils.
Un seuil en dessous duquel le traitement n’agit pas.
Un seuil, supérieur au précédent, au dessus duquel le traitement est toxique.

Pour être utile sans être nocif, la concentration du médicament dans le sang doit être entre les deux. On la monitore pour s’assurer que l’on reste dans la bonne fourchette par des prises de sang régulières.

Pour le coaching agile, c’est pareil.

Je considère qu’en dessous d’un certain seuil (une journée par semaine ? une demi journée par semaine) je n’ai plus suffisamment d’informations de contexte pour fonctionner comme je le souhaiterais. Je ne prends pas assez de cafés avec les uns et les autres, je me repose uniquement sur la vision du scrum master, qui se livre de moins en moins.

Bref progressivement, je me fais éjecter, je ne suis plus dans la boucle, je perds la richesse du contexte.

Les signes sont bien visibles. J’ai un train de retard sur les problèmes de l’équipe. On me salue en me disant « tiens, un revenant », …

Inversement, quand je suis présent trop, d’autres effets pervers se manifestent.

On me propose de remplacer le scrum master pendant ses congés plutôt que de lui trouver un remplaçant dans l’équipe. On essaie de me faire prendre parti, produire des livrables projets. Cela déresponsabilise les scrum master, voire l’équipe.

Comme dit mon collègue @dmourgand, il faut laisser à l’équipe la possibilité de faire des erreurs.

Il y a bien une façon de tempérer ça (s’installer dans un plateau, mais pour travailler sur autre chose, tout en tendant l’oreille), mais on « use » quand même son costume de coach à être trop présent.

Le coaching c’est amener, par le biais d’une relation personnelle, les coachés à se remettre en question, à aller au fond des choses. Si on est trop loin, la relation devient « le coach est juste un expert agile » et la remise en question ne va pas assez profond. Trop près, s’il y a remise en question, il n’y a plus assez de distance et l’on ne raisonne pas assez « out of the box ».

Du coup, il faut parfois faire, de la présence, juste pour faire de la présence ( ce qui peut sembler étrange quand on a 10 projets dans son scope ).
Et il faut prendre du recul, et pour cela rien ne vaut les échanges avec les collègues coach, quand on a comme moi la chance d’être au sein d’un groupe de coach.

Le luxe étant d’avoir un collègue qui vous supervise, bref qui vous coache. Même une fois par mois, c’est déjà bien.

Publié dans Agile, Efficacité, Humain | 3 commentaires

Project Portfolio game : Beyond budgeting, Finance, Kanban and Agile.

Absurdity of Budgeting

One day, while I was coaching a project, I realised that the project team would be dissolved after the delivery of V1, and formed again, with different team members, for V2. You can imagine my reaction in front of this absurdity. It looked like nothing could be done. It was not the same year, not the same budget. And until february, budgets are not finished negociating, so continuity of the project was impossible. At that time, I was not aware of movements like Beyond Budgeting, but it still was absurd. Finally, the clever manager managed to keep one team member during the gap between the two projects, using accounting tricks and non-urgent tasks.

Financial investments

Another day, at Lean Kanban France 2012, I heard David J Anderson talking about project porfolios that should be managed as financial products portfolios, arbitrating risk and value. I liked the idea a lot. You start your project telling it will cost 100 and bring a value of 150. Before then end, you revise your risks, and decide it will finally cost 120. At the end of the project, maybe the value will be less, like 140. Thus you may gain 140-120 instead of 150-100. Realy looks like a risky financial investment.

In my distant past in finance, I had a theory about the ideal way to manage a stock portfolio. You invest 10000. You check your porfolio’s value every day. If it goes down, you invest more to go back to 10000 (up to a certain limit at wich you quit investing). If it goes up, you sell stoks, securing your gains, until your invested value (your risk exposal) is back to 10000. To say it briefly, you keep your risk exposure constant and secure your benefits all along.

Project Portfolios

Thinking about that, and to the explaination of Kanban by David J Anderson in his Kanban book, I was wandering what would happend if a company kept constant its investments (the sum of the estimates of all started projects). If a projects gets in trouble and needs refill, you reduce the budget of others. If a project can be ended before its full end, you stop it and reinvest the budget into others.

The more frequent decisions, to be taken effectively, will need a clear vision. For that, the list of projects should not be too long. This will be made possible by efficient and explicit arbitration between business goals. Thus, in a way, we will have both a constant investment and a constant number of projects, i.e. two WIP limits, one per budget, the other per number.

Staff Liquidity

Since the investment are constant, so his the number of people needed. You keep them all permanently, and move them across projects to accomodate the investment changes. I like a lot the staff liquidity advocated by Chriss Matts during the 2013/4/15 xALEc Hangout.


Agile brings a value driven planning, which will help stop or reduce projects. Agile brings also shared code ownership, which will help move people. Last but not least, to invest and reinvest and reallocate, the weight of history, of obsolete applications, i.e. the debt should be managed and reduced, notion dear to agilists.

Publié dans Agile, English, Entreprise, Humain | Laisser un commentaire

256 combinations of agile coaches #agile #coaching

This post has been translated into portugese by Marcelo L. Barros (@MLeiteBarros). Thanks !

I have the privilege to act as an agile coach in a huge French manufacturing company, along with other agile coaches like Laurent Carbonnaux, Pierrick Revol. I am thus exposed to a real agile transformation initiative, going further than the classic agile pilot. We are currently coaching approximately 40 projects. And, what’s more, we are speaking to each other, trying ideas like Lean Design, comparing, counselling.


In this privileged environment, it came clear to me that there is at least 8 ways in with agile coaches can differ, making 2^8 possibilities, thus 256. Of course, your posture will depend on the context. Moreover, the answer will be grey, not black or white. However, after having working with coaches since 2 years, I find that they have, and I have, dominant traits. We need to acknowledge them, either too encourage them (work on our strengths) or encouraging the opposite (work on our weaknesses).

Here are the 8 axis

(1) Prescriptive versus Contextualized

  1. The coach can be prescriptive, focused on the current change management initiative, deploying the official agile flavour of the company, being sometimes brutal and creating sometimes resistance.
  2. On the opposite, the coach can base his/her change management on listening to people, providing a contextualized agility, but somehow loosing readability of his effort.

(2) Therapist versus Lean senseï

  1. Some coaches put the focus on psychology, on the stages of the team of Bruce Tuckman, on the resolution of conflict, harmony. Retrospective are long, looking sometimes as family therapy sessions, but rich.
  2. Some other coaches put much more emphasis on optimization of the process, delivering fast value, improvement of tasks. Retrospective are short,  focused and somehow poor.

(3) Serious versus Playfull

  1. Some coaches, perhaps the older ones, have quite a classic way to teach, and are not at ease with games, fearing to loose the clarity of the message in the details of the play. Sometimes, trainees get bored by academic details.
  2. Some other coaches, perhaps the younger ones, enjoy games so much they could do a complete agile training with games, leaving people delighted. Sometimes, trainees don’t remember that much, and find the whole thing too fun to be taken seriously.

(4) Proven versus Innovative

  1. Some coaches wait until concepts are proven in the community and tried on guinee pigs projects before they deploy them massively, thus delaying the deployment of new beneficial techniques.
  2. Some other coaches are so much innovators they deploy techniques as soon as they grasp them, or invent them, without sound preparation, taking risks while innovating.

(5) Persuading versus Leading

  1. a. Some coaches appeal to the logical mind of people, handling carefully and logically objections, until they agree to « give it at try », perhaps making too much concessions.
  2. b. Some other coaches, more charismatic, lead them in the adoption, by the sheer strength of their will and energy, perhaps with a lack of explanations.

(6) Intensive vs Lasting

  1. a. Some coaches manage to train to agile and set on track the whole team in a week, having set up the foundations of the agility of the project the next week. They then leave to coach other projects, the team will feel alone, and diverge from agile.
  2. b. Some other coaches prefer to work by touches, training and starting the project at the beginning, coming back, attending retrospectives, coaching the scrum master in his personal development. This coaching takes more time, reducing the number of projects coached and the transformation.

(7) Planned vs Reactive

  1. a. Some coaches plan their intervention, writing a coaching plan with a set of actions and goals, perhaps lacking somehow flexibility.
  2. b. Some other coaches have a reactive, opportunist approach, coming with an open mind, looking for the most urgent intervention at the time. This way of coaching lacks of readability.

(8) Visible vs Invisible

  1. a. Some coaches are very visible, incarnating the agile transformation, somehow the guest star of the project, preventing leadership from emerging.
  2. b. Some coaches are invisible, whispering in the ears of people, like a film director, having again readability problems.

My signature is 1b-2a-3a-4a-5a-6b-7b-8b. Can you tell me yours?


By the way, do you see other axis, other ways for you to differ from your fellow coach friends ? Things they find obvious and that you don’t understand, or at least you don’t share? Variations from a so-called agile consensus?

Publié dans Agile, English | 4 commentaires

#ControleQualité en environnement #Lean / #Agile


L’entreprise pratique les développements de manière structurée depuis des années, et une partie de cette expérience accumulée conserve sa valeur, que par le passé on a tenté de capitaliser dans un processus, pour éviter de faire plusieurs fois les mêmes erreurs.

L’entreprise a aussi choisi de se transformer radicalement en adoptant les approches lean/agile, en instaurant notamment l’amélioration continue et globale et l’adaptation au contexte des projets.

Cette dualité entre capitalisation et adaptation pose des questions sur la garantie qualité des projets. La garantie qualité c’est le contrôle par un tiers de la conformité au processus. Si l’on admet l’idée d’une adaptation permanent, à quoi doit-on rester conforme ?

Les projets agiles doivent intégrer ce souci de contrôlabilité puisque l’entreprise a choisi de mettre en place cette démarche qualité, et ne s’est pas cantonnée à la sensibilisation et à la formation des équipes.


Les projets doivent être contrôlables facilement (le contrôleur regarde les preuves, les traces) :

  • Adapter de manière réfléchie et formalisée, ce qui n’est pas compatible avec une démarche Scrum ou Kanban (qui insiste encore plus sur le côté scientifique avant/après des actions d’amélioration)
  • Les projets doivent décrire leurs choix de fonctionnement : definition of done, checklists, …
  • Les projets doivent rendre visible et transparent leur fonctionnement : management visuel clair, explicite, lisible.


La qualité est dans le regard de celui qui regarde :

  • Le regard du contrôleur doit évoluer, pour aller du processus vers les principes sous-jacents du processus, en considérant notamment les grands principes lean ou agiles que l’on essaie d’implémenter.
  • La capacité du contrôleur qualité, de par son expérience, à envisager ce qui va se produire si l’on fait quelque chose d’un peu nouveau se substitue à celle de comparer à un processus de référence.
  • Les normes qualités doivent évoluer, pour modifier la nature des points que l’on contrôle. Contrôler le résultat (« l’équipe réussit à livrer les user stories qu’elle a envisagé en début de sprint ») plutôt que le moyen (« l’équipe fait une démo en fin de sprint des user stories qu’elle a livrées »). Evaluer le résultat du résultat (auditer la satisfaction client, évaluer les retours signalés après la mise en production, …) , ce qui suppose que l’on livre en production souvent, sinon le résultat du résultat arrive trop tard.
  • Les pratiques du contrôleur change, pour passer d’un contrôle rare, long et souvent à distance (à base de document) à un contrôle fréquent, plus bref, sur site (« Gemba »), ainsi qu’une présence lors de cérémonies.


Ces contrôles seront difficultés à effectuer: les projets seront tous différents. Les contrôleurs qualité ont souvent dans leur escarcelle de nombreux projets, s’adapter à chaque fois demande un effort certain.

Par exemple : Imaginez… Trois mondes parallèles où existe le même projet… Dans chaque monde, le projet est contrôlé… Les contrôleurs qualité sont différents. Ils examinent la même situation, font un diagnostic légèrement différent, et optent pour des conclusions et actions différentes. Les projets évoluent dans des trajectoires différentes. Il n’y a pas de processus général de la vie d’un projet, il n’y a que des principes, un jugement humain sur ce qu’il faut changer. Même l’évolution de la maturité d’un projet va potentiellement varier d’un contrôleur à l’autre.



Fils de médecin, je vois un peu l’accompagnement d’un projet comme un diagnostic médical. Examiner les symptômes (les signes de disfonctionnement), connaître le fonctionnement général d’un projet informatique tout en intégrant les spécificités d’un cas concret, son historique, la coexistence potentielle de plusieurs pathologies. Décider d’une prescription ou intervention, en suivre les conséquences, réitérer.

Si les médecins jouent aux dés, ils « trichent » en obtenant des statistiques sur l’impact de tel médicament dans tel contexte, pour battre le hasard. Ce qui manque, au contrôleur agile, c’est une phénoménologie scientifique donnant les probabilités de succès d’une action ou d
’une autre selon le contexte.

L’analogie m’amène à voir aussi les rôles d’accompagnement comme un médecin généraliste, qui ferait intervenir un expert du leandesign, de l’intégration continue ou un expert de l’automatisation des tests. L’adoption de communautés de pratique dans l’entreprise pourra faire émerger, à défaut d’un consensus, des interlocuteurs fiables, sur ces différents sujets.

Cette analogie, comme toute analogue, a ses limites : la médecine a un consensus sur le fonctionnement « normal ». Pour la transformation agile, il me semble plus judicieux de miser sur une montée en maturité des équipes. Il peu s’agir d’agilité en général, ou, selon les centres d’intérêts et les situations sur des points plus spécifiques. Les contrôleurs mettront à profit cette maturité, les experts émergents se substituant à une savoir phénoménologique figé, le contrôle étant fait en premier approche par ces contrôleurs qualité.

Publié dans Entreprise, Pensée | Laisser un commentaire

Sortir d’un deadlock humain

On n’imagine pas à quel point les points de vue des personnes lors d’une réunion peuvent être radicalement différents, pas tant sur le contenu que sur l’attitude, la posture elle même. Du coup l’ensemble de la réunion a un cours erratique, on tourne en rond, on passe autant de temps à discuter de comment on va discuter qu’à discuter réellement des sujets.

Voici un exemple de casting pouvant mener à ce deadlock humain, une situation inextricable ou aucune décision ne peut être prise pour sortir du statu quo. Réunissez les dans la même réunion, et profitez du spectacle ! Drame garanti, mais cela devient répétitif au bout d’un moment.

B, Responsable de domaine, Interne
Je veux que l’on soit précis sur les faits. J’ai envie de leur dire : « Je ne comprends rien à ce que vous racontez. Que se passe-t-il ? ». Je n’aime pas Le désordre, l’ambiguïté.
R s’investit beaucoup, mais manque de recul. V est plein( e) de bonnes idées mais remet en question trop de choses.
Le projet doit avant tout être-efficient et rester dans le budget

J, Directeur de projets, Interne
Je ne veux pas que l’on cède au pessimisme. Un projet a besoin d’énergie positive, pas de jérémiades. Etre positif c’est être actif !
Je n’aime pas ceux qui passent leur temps à râler sans rien proposer, ceux qui ne voient que des problèmes et passent leur temps à en parler. N est insupportable, ne parle que de problèmes.
Il ne faut pas trop alarmer B. On va trouver une solution.

R, Chef de projet, Interne
J’ai beaucoup de tension accumulée. Je porte ce projet à bout de bras, je n’en peux plus. Je ne suis pas une machine, j’ai besoin de dire ce que j’ai sur le cœur.
J’ai envie de leur faire comprendre que je ne sais pas où donner de la tête, que ce projet me tape sur le système.
B est froid(e). J n’est pas à mon écoute.
J’ai l’impression que l’on attend de moi que je sois une machine. C’est trop dur, j’ai envie de sortir du projet.

N, Scrum Master, Externe
Il faut rester réaliste, que l’on ne s’embarque pas dans n’importe quoi. J’ai envie de leur crier : « Pipo ! »
Je n’aime pas ceux qui sont toujours positifs, au point de ne pas être réalistes (souvent les CP et les managers qui noient le poisson en espérant se refaire, comme des joueurs de pokers incapable de s’arrêter de miser.)
V est incontrolable et raconte n’importe quoi.
J est une autruche.
Cherchons des solutions viables, renégocions le périmètre avec le métier.

V, Coach agile, Externe
Je veux que l’on trouve une solution durable à la situation
J’ai envie de leur dire : « Et si… Examinons les idées les plus folles »
Je n’aime pas ceux qui refusent d’écouter de nouvelles idées, qui censurent. N n’écoute aucune de mes idées
Je pense qu’il faut un changement radical, réorganiser le projet en deux feature teams.

Si on applique les chapeaux de Bono, dont le principe est d’aligner TOUS les participants sur le même mode (créativité, faits, émotions, esprit critique, energie positive) à un moment donné et d’appliquer les modes l’un après l’autre,

B pourra accepter un plan d’action, quel qu’il soit, s’il est structuré et ordonné. Il saura être critique sur les questions de faisabilité ou de budget.
J pourra accepter des remises en question de ce plan d’action, s’il accepte ce temps de critique comme un souci de perfectionnement. Au moment opportun, il pourra mettre son expérience a contribution pour dire ce qui marche ou pas.
R verra une sortie poindre au bout du tunnel, et sortira du mode panique. Elle pourra communiquer sa vision des contraintes sans avoir l’impression de se plaindre.
N pourra améliorer ses relations avec la hiérarchie, car il acceptera de cantonner ses critiques au moment opportun. Il amènera les idées des membres de l’équipe.
V pourra faire passer son idée avec un meilleur impact, si tout le monde est en phase « créative ». Elle sera transformée et rationalisée, mais peu importe, elle sera passée.

Contrairement à ce que l’on peut imaginer, le respect des postures des autres ne vient pas naturellement dans le feu de l’action. Un complément peut être le baton de parole.

PS: Cela me rappelle les mésaventures de notre équipe de coach naissante.

Publié dans Agile, Humain | Laisser un commentaire

L’agent de changement sans ego

Féru de zen, je m’aperçois, rétrospectivement, que je cherche à me comporter comme un agent de changement « sans ego ».

Un agent de changement sans ego est un consultant qui n’existe pas en soi, qui ne laisse pas de signature particulière si ce n’est qu’il semble se produire un peu plus de changements là où il est passé. Un peu comme un coach.

Ghost in The Shell - Invisible

Quand il rencontre un manager, il sait bien que la messe est dite, que le manager du manager a déjà fait passer le message. Les questions qui se posent ne sont plus faut-il changer, mais comment aider les équipes à changer, et pour cela c’est le manager qui connait le mieux ses équipes (y compris le middle management) qui va lancer les ateliers, insuffler la dynamique.

Certes, l’agent de changement sans égo forme les équipes et le middle management, mais c’est une formation à la théorie. Il fait émerger la stratégie d’implémentation des équipes et du middle management, en canalisant, en relançant la balle et en poussant à l’approfondissement lors des ateliers de transformation ou de lancement de projet.

Alors, il y a bien sûr les évènements, les conférences, les jeux de sensibilisation, mais l’agent de changement s’efface devant les retours d’expérience faits par des acteurs de terrain, et fait animer les jeux par des middle managers locaux, préalablement entraînés, et donc mis en situation de porter le changement auprès des équipes, ce qui permet au passage de les aligner.

Il lui arrive d’animer des workshops ou des jeux lui-même, mais dans ce cas il est habité par le rôle, s’efface devant ce qui doit être fait, et n’a toujours pas d’égo.

L’agent de changement sans ego arrive puis s’en va, et l’entreprise se transforme, et continue de se transformer après son départ. Aurait-il eu un ego qu’il y aurait eu plus de résistance. Car c’est bien de cela qu’il s’agit : trouver la forme d’intervention la plus efficace pour libérer les énergies favorables à la transformation et aider les noeuds à se défaire d’eux mêmes (la phrase magique étant « tu lui en as parlé ? »), enrobant les énergies pour les réorienter imperceptiblement comme en aïkido.


Cela pose des problèmes de lisibilité de l’action (à quoi sert l’agent de changement s’il ne fait rien ?), mais il préfère en faire les frais, plutôt que d’imposer sa présence quand on peut s’en passer ou de se mettre en avant alors que cela n’apporte rien au système qu’il s’efforce d’aider à changer. La seule mesure de son action est la transformation elle-même, pas d’éventuelles preuves des moyens engagés.

Bien sûr, cette description est idéaliste. Je n’agis pas complètement sans ego. Je me souviens cependant d’un entretien de qualification pour un job de transformation où l’on m’avait demandé mes plus grandes qualités, et où ma première réponse avait été « l’écoute », à la surprise générale. C’est un point clé en aikido : conserver un contact physique souple avec son partenaire pour savoir où il est et où il va.

Publié dans Agile, Entreprise, Humain | Laisser un commentaire

Les patterns & frameworks sont toxiques

Pourquoi les patterns ne sont pas juste un réseau utile pour canaliser l’expérience et sont ils considérés comme des modèles d’action prêt à l’emploi ?

Imaginons un projet scrum qui décide de passer à des itérations de 4 semaines, mais avec une rétrospective intermédiaire au milieu.
La modification fonctionne.
Faut-il en tirer un pattern ? Faut-il l’appliquer à tous les projets ?
Peut-on dire autre chose que « dans ce contexte, effectivement, c’était judicieux » ?

Lean Startup est un framework pour Startup (comme son nom l’indique) très séduisant et très efficace.
Il est possible de l’étendre à des projets innovants au sein d’une entreprise plus corporate.
Imaginons un projet « un peu » innovant.
Faut-il appliquer à la lettre les préceptes de lean startup, et se faire des noeuds au cerveau pour trouver exactement les attendus d’une startup ?
Pourquoi ne pas essayer de comprendre ce qui nous séduit dans lean startup (l’apprentissage validé pour les projets innovants par exemple) et d’en déduire ce qui pourrait marcher sur notre projet ?

Certes, l’avantage des patterns et frameworks est de capitaliser une expérience.
Mais on n’a pas exactement besoin d’une expérience capitalisée.
On a besoin d’un expérience suffisamment internalisée pour pouvoir innover (RI).
On en vient naturellement au A3 Process pour la capitalisation sur la résolution de problèmes que l’on peut généraliser à toute démarche d’amélioration : l’essentiel est l’identification du problème que l’on souhaitait résoudre et la recherche des causes racines.
On documente aussi la solution essayée et les résultats, mais le partage sur les questions que l’on s’est posées me semble presque plus fécond.

Il y a ceux qui se réclament d’un framework ou d’un pattern, pour s’appuyer sa notoriété et le discours standard qui va avec.
Lors de la mise en oeuvre, ils font cependant à leur idée, soutenant mordicus qu’ils appliquent la référence.
Le management est-il si obtus qu’il faille absolument des concepts markétés à l’extérieur ?
S’il n’est pas idiot de sortir du contexte et de ne pas réinventer la roue, pourquoi ne pas s’assumer et simplement dire que l’on fait en partie à son idée ?

Un autre intérêt, parfois inavoué, des méthodes construites à partir de frameworks et de patterns est d’homogénéiser les pratiques au sein d’une entreprise, notamment pour en faciliter la lisibilité par le management et par les instances de contrôle (qualité).
Ce côté systématique (et accessoirement schématique) vaut-il la peine de réduire la capacité d’innovation des équipes ?
Ne vaut-il pas mieux homogénéiser le reporting de synthèse, en laissant la liberté aux équipes de s’adapter à leurs problématiques ?
Et trouver une façon de produire au contrôle qualité des « preuves » suffisantes du bon fonctionnement, en les orientant plus sur le contrôle des résultats et des bonnes propriétés des projets que sur le contrôle des moyens ?

Ces patterns, frameworks et pratiques sont ce que Jurgen Appelo appelle des memes dans Management 3.0, des véhicules pour partager de l’expérience. Il ne s’agit pas de théories établies par des démarches scientifiques ou de formules toutes faites, mais bien d’outils de conduite du changement. Qu’ils en restent là, et que l’on bon sens et l’esprit critique reprennent leur place.

Publié dans Agile, Pensée | Laisser un commentaire

L’important, c’est de facturer

Je ne suis pas cynique, par contre j’aime bien tenir des propos cyniques. D’où ma phrase fétiche, quand une équipe de consultants se cherche : l’important c’est de facturer

Disclaimer : Cette phrase, prise au pied de la lettre, peut malheureusement se lire : je viens, je ne fais pas le maximum, je facture. Cette attitude me semble bien dangereuse (pour la facturation !). Et particulièrement déprimante. Tel n’est donc pas mon propos.

Quand je dis facturer, c’est dans la durée. Donc on peut faire des actes gratuits ou mal rémunérés en visant une facturation future. Inversement, il n’est pas forcément judicieux de facturer très cher trop tôt, si cela met en danger la pérennité de la mission.

Pour facturer, il faut que le client en aie pour son argent. Donc il faut produire mais aussi rendre visible ce que l’on a produit. Donc de l’action, de la communication. Cela peut créer des « jeux » un peu complexes quand plusieurs société de conseil sont représentées (chacun veillant à se voir attribuer le mérite de son travail, notion floue dans une équipe)

Le client n’est pas toujours à même de dire a priori ce qui va le satisfaire a posteriori. Donc il faut parfois dire non au client (c’est trop cher et vous n’en avez pas besoin) et vendre des concepts au client (vous ne connaissez pas ça, vous en avez besoin et ce n’est pas trop cher par rapport à la valeur). Bref, parfois ne pas faire ce qui est demandé mais ce qui finalement aura de la valeur.

Pour facturer, il faut aussi savoir qui a la décision de prolonger ou non la relation commerciale. Et considérer que la mesure du résultat est cette décision de poursuivre, prise de manière répétée. Pas toujours simple, quand les interlocuteurs ne sont pas en phase ou ne disent pas tout. Et en plus ils parlent entre eux !

Pour facturer, il faut savoir ce qui se passe dans la tête du client (une ou plusieurs personnes), et pour se faire il faut une relation d’échange, formels ou informels, cordiaux ou non, pour éviter les surprises, pour comprendre finalement dans quelle direction il est utile de faire un effort car il sera et pertinent et accepter. Garder un contact, comme dans les arts martiaux où on se sert d’un contact avec le corps du partenaire pour savoir où il est.

Bref, la facturation est pour moi la reconnaissance de la valeur perçue au final par qui de droit (celui qui signe !)

Pour une approche fouillée et très percutante, lire l’excellent « The secrets of consulting » de G. Weinberg

Publié dans Agile, Entreprise | 2 commentaires

Shu Ha Ri : Et si Scrum n’était qu’un Kata ?

Faut-il estimer les tâches ? Si l’équipe est dynamique, s’il y a une vision partagée des enjeux, un simple découpage en tâches, bien visualisées peut parfois suffire pour tenir l’engagement. L’estimation importe moins que l’identification, l’organisation, la répartition, la remise en question, …

De même, faut-il estimer les user stories ? Il faut débattre des user stories, les challenger au niveau de l’architecture, des implications.
Maintenant, à quoi sert le chiffre de la vélocité si l’on est capable d’avoir des user stories en gros de même taille ? On peut se contenter alors de compter le nombre de user stories par sprint.

Les gens du business ont rarement la dispo que l’on attend d’un scrum master.
Parfois la connaissance du métier est plus dans l’équipe qu’en eux.
On crée des relais vers LE product owner, des intermédiaires et le travail crucial de négociation entre besoin et solution est dilué, éclaté et inéfficace.
A l’inverse des binômes technique / métier peuvent parfois porter les sujets beaucoup plus efficacement, quitte à ce que cela soit supervisé et arbitré par un lead business.
Alors pourquoi ce passage obligé unique ? Est-ce que cela ne serait pas une matérialisation organisationnelle d’un enjeu (la cohérence fonctionnelle) qui peut être traité différemment ?
Je peux comprendre qu’il soit nécessaire d’avoir un interlocuteur unique pour chaque sujet, mais pourquoi toujours le même d’un sujet à l’autre ?

Et puis pourquoi faut-il un Scrum Master si l’équipe est convaincue de la nécessité d’être agile ?
Pourquoi confier les tâches administratives toujours à la même personne ?
Pourquoi incarner en une personne ce que l’équipe devrait assumer d’elle même, la privant même de l’occasion de l’assumer ?
Pourquoi pas un Scrum Master tournant, à supposer que l’information circule bien pour une action dans la durée.

Et puis d’abord pourquoi faut-il des sprints ?
Pourquoi pas une démo tous les mois, avec des rétros toutes les 2 semaines, et une présentation des User Stories chaque semaine ?
J’imagine que c’est psychologique : imposer une durée fixe pour être sûr d’avoir des démos régulières. Mais n’est-ce pas un peu ridicule de se retrancher derrière des règles immuable pour matérialiser un enjeu (le feedback et la transparence) qui peuvent être traités différemment.

Toute la panoplie Scrum, vendue par le coach en début de projet, déployée par le Scrum Master.
Quand ça va bien, ce déploiement est challengé par l’équipe, des contre propositions émergent.
Kanban apporte une approche plus continue dans l’introduction des pratiques.
Il ne s’agit pas de Scrum-But, mais de Not-All-At-First

Et donc il y a des fois ou je me demande si Scrum n’est pas un peu comme un kata : on le répète consciencieusement pour s’approprier les techniques, mais on sait bien que le kata n’est pas réaliste.
Personne ne prendrait au pied de la lettre les symboles et simplifications pédagogiques.
Personne n’irait dérouler un kata tel quel dans un combat de rue.

L’estimation pour apprendre à gérer ses tâches et ses User Stories
Le product owner pour mettre en marche la machine à négocier besoin et solution.
Le scrum master pour mettre en marche la responsabilité de l’équipe.
Les sprints pour insuffler un rythme.

N’oublions juste pas que c’est une forme pédagogique, pas une finalité.

PS: je soupçonne Christophe Addinquy d’une part  (« En finir avec le product owner« ) et la conference « Lean Kanban France 2012 » de m’avoir mis cette idée dans la tête, cette autre lecture du Shu Ha Ri.

Publié dans Agile, Pensée | Laisser un commentaire

Scrum et les types de personnalité

Lors d’une formation au coaching par Véronique Messager, j’ai pu être un peu initié à la process com, et à ses 6 types de personnalités : travaillomane, persévérant, rêveur, rebelle, empathique et promoteur. Avec les réserves que je peux avoir sur ce genre de classification des gens en seulement 6 rubriques.

Un peu plus tard, je me suis dit : L’organisation d’un projet agile  prend une forme concrête qui dépend du contexte. Mais c’est quoi le contexte ?
Et si ce contexte dépendait surtout de la personnalité du business (notamment le product owner) et de l’équipe (notamment le Scrum Master)  ?

Voici donc, pour les 6 profils, des exemples en situation de stress léger (comme pour tout projet agile)

Empathique (compatissant, sensible, chaleureux)

  • Un product owner « empathique » voudra faire plaisir à tout le monde, et n’arrivera pas à trancher.
  • Un scrum master empathique n’arrivera pas à mettre les pieds dans le plat, à recadrer par exemple le product owner par rapport à scrum, à la vélocité, aux interuptions et aux changements de périmètre en cours de sprint.
  • Un membre d’équipe « empathique » voudra faire plaisir à ses collègues (et se laissera donc marcher sur les pieds), au product owner (et prendra donc le risque de ne pas finir ce qui est prévu)

Travaillomane (logique, responsable, organisé)

  • Un product owner « travaillomane » fournira des user stories hyperdétaillées et contraignantes, et ne voudra pas les renégocier ensuite (3C)
  • Un scrum master « travaillomane » voudra tu contrôler par lui même, tracer, calculer, prévoir et n’arrivera pas à déléguer à l’équipe, qui du coup ne prendra pas ses responsabilités.
  • Un membre d’équipe « travaillomane » voudra tout planifier, attribuer toutes les tâches en début de sprint

Persévérant (dévoué, respectueux des règles, consciencieux)

  • Un product owner « persévérant » n’arrivera pas à prendre du recul, ne vera que ce qui ne va pas lors des démos, et démoralisera tout le monde.
  • Un scrum master « persévérant » voudra convaincre l’équipe du bien fondé de son point de vue, et par ailleurs la soupçonnera de ne pas être engagée à fond.
  • Un membre d’équipe « persévérant » sera très à cheval sur la règle et aura beaucoup de mal à imaginer que l’on puisse ne pas être d’accord avec lui

Reveur (imaginatif, réfléchi, calme)

  • Un product owner « reveur » se plaindra de ne jamais avoir le temps de réfléchir avec le rythme itératif.
  • Un scrum master « reveur » fonctionnera en mode réactif, sans leadership.
  • Un membre d’équipe « rêveur » aura du mal à s’intégrer aux rituels, à rendre compte de son avancement.

Rebelle (spontané, créatif et ludique)

  • Un product owner « rebelle » aura du mal à se plier aux contraintes de scrum, à préparer ses user stories, à répondre.
  • Un scrum master « rebelle » mettra un bonne ambiance quand ca va bien, râlera beaucoup le reste du temps.
  • Un membre d’équipe « rebelle » mettra beaucoup d’animation mais aura du mal à faire ce qui aura été décidé par l’équipe

Promoteur (adaptable, persuasif et charmeur)

  • Un product owner « promoteur » utilisera tous les moyens (manipulation comprise) pour aboutir à ses fins, et réagit très négativement quand il n’a pas ce qu’il veut.
  • Un scrum master « promoteur » n’offre pas tout le soutien nécessaire aux membres de l’équipe, et tord le processus scrum pour atteindre ses buts personnels.
  • Un membre d’équipe « promoteur » utilisera les moyens les plus déloyaux pour se faire attribuer les tâches qui l’intéressent.

Suivant la combinaison Product Owner + Scrum Master + membres d’Equipe, le processus Scrum sera appliqué de manière plus formelle ou plus lâche, les rituels se passeront de telle ou telle manière, les user stories embarqueront ou non des éléments de solution difficiles à négocier ensuite, le sprint burndown sera ou non tracé, etc…

Ou placeriez vous votre scrum master et votre product owner et vos membres d’équipe ?

Voyez vous un lien avec le fonctionnement de votre projet ?

Et enfin quel autre facteur est à considérer, si on fait abstraction des personnalités des personnes ?

Publié dans Agile, Humain | 6 commentaires

Comment faire le casting du Product Owner et du Scrum Master dans Scrum

On ne décide pas de la stratégie d’une équipe sportive pour un match indépendamment de sa composition. On se soucie des spécificités de chacun. Le rôle affecté aux joueurs est déterminant, mais ne résume pas l’alchimie de l’ensemble.

Quand on intervient sur une transformation d’entreprise, ou même sur un simple projet, on a tendance à parler des Scrum Masters et des Product Owners, en terme générique, comme un concept transcendant, alors qu’il ne s’agit que d’une collection, hétéroclite d’individus qui sont très différents. Qualités, défauts, réseau, historique, personnalité, relations avec les autres acteurs… Comme me l’a écrit @MaLainDa : « Suivant les circonstances, certains défauts sont des qualités. En plus des circonstances, il y aussi les personnes qui nous entourent. Chaque individu n’a pas la même tolérance face aux défauts. »

Le Scrum Master et le Product Owner ne sont que des concepts pédagogiques du framework Scrum, qui regroupent des responsabilités qui peuvent être portées dans certains cas par d’autres. L’article « en finir avec le Product Owner » de mon ami @addinquy m’a catalysé dans cette idée.

Pourquoi ne peut on pas décrire le « système équipe » avec les acteurs réels plutôt qu’à se cacher derrière des concepts ? Les responsabilités doivent être assumées, par une ou plusieurs personnes. Les rôles théoriques, les fiches de poste dans l’entreprise sont secondaires. Ce qui compte c’est que ça marche. On doit faire au mieux avec les personnes que l’on a, pas avec l’idée d’une organisation imaginaire incompatible avec les contraintes du réel.

Pour le contexte que j’ai en tête, je vais donc oeuvrer pour que les personnes concernées trouvent une répartition des responsabilités pragmatique, adaptable si besoin, sans les laisser se cacher derrière des rôles idéaux. Il y a une résistance dans certaines entreprises, quand on a une culture du processus et des rôles établis, quand on a des fiches de poste et des places affectées dans l’organigramme. Ce qui me laisse me livrer à mon activité favorite : rappeler la première valeur du manifeste : « Les individus et leurs interactions plus que les processus et les outils. » Et rappeler que l’on est dans un configuration incertaine, que l’on va inspecter le résultat périodiquement, et s’adapter (par exemple pour suivre l’évolution des compétences des uns et des autres, ou leur envie de changer de sujet).

Publié dans Agile, Entreprise, Humain, Pensée | 1 commentaire

Ateliers de créativité : 3×3 vs 9

Lors d’une formation des Business Analysts que je co-animais, et dans le but de pratiquer un peu les ateliers de créativité, j’ai fait une expérience comparative.

Le sujet général de la formation et de l’expérience était la transformation annoncée du métier des stagiaires, car leur entreprise allait recourrir systématiquement à l’externalisation.

La nature de l’exercice, et les reponses obtenues ne m’intéressent pas ici, ce qui m’intéresse c’est le processus de créativité de groupe. Comment avoir des idées quand on est 9, que l’on ne dispose pas de beaucoup de temps, et que le consensus reste à trouver.

« Protocole experimental »

Experience 1 : « Placez vous dans 1 an, vous croisez votre DSI dans l’ascenseur, la transformation est un succès, qu’est-ce que vous lui dites. » (les experts y verront un pâle reflet de Remember the Future )

Chaque stagiaire a écrit ses idées (bénéfices, réalisations, …) dans son coin sur des post-its. Nous avons collé ces post-its au mur.

Experience 2 : « Quels sont les freins, les obstacles pour cette transformation » (les experts auront cette fois-ci, ainsi que pour l’experience 3, reconnu l’ombre d’un Speed Boat).

Les stagiaires ont été groupés par 3 (3 groupes puisqu’ils étaient 9). Au bout du même temps que pour l’experience 1, un representant de chaque groupe est venu coller dans une autre zone du mur les idées. J’avais limité à 4 le nombre d’idées.

Experience 3 : « Quels sont les atouts, qu’est-ce qui va vous aider, faire que ce soit un succès ».

Cette fois ci, pour changer un peu des post-its, j’ai fait un tour de table, une idée chacun. Au bout de 6 intervenants, la source s’est rapidement tarie.

Resultats et conclusions

Nbre de post its (en ordre décroissant) 1,2,3

Unicité et pertinence des idées 3,2,1 (avec un écart assez faible). La censure sur le 3 est arrivée trop tôt.  Je dois dire que je m’attendais à pire pour le 1, il n’y avait pas tant de redondance que ça

Richesse 1 et 2 exaequo puis 3. La contrainte « 4 freins max » n’a pas trop bridé la créativité.

Intelligibilite 2, 3, 1

Si vous avez 9 participants « bavards » le mieux c’est le 2 (en changeant les groupes a chaque fois), avec l’inconvenient que certains parlent peu, et peut-etre un peu trop de censure.

Le 1 donne une plus grande sensation de créativité pendant l’exercice, mais reste derrière le travail d’articulation et de synthèse, que je trouve frustrant s’il est fait plus tard.

Du coup ma préférence va au 22, le 3 je n’aime pas trop (à part peut être pour une rétrospective où il est critique que tout le monde parle), le 1 j’hesite. Je n’ai pas trouvé comment faire une synthèse collectivement (le dot voting a ses limites).

Publié dans Agile, Efficacité | Laisser un commentaire

Vers une autre structure projet

Couper un système en deux crée deux sous-systèmes et une interface, une surface de frontière commune aux deux systèmes.
Cette interface va engendrer du gaspillage, au sens lean du terme.

Exemple caricatural mais réaliste : une entreprise confie la rédaction des spécifications à un premier sous-traitant, la réalisation des développements à un second, la recette des développements à un troisième. Sois trois sous-systèmes. Je vous laisse dénombrer le nombre d’interfaces.
Ici, le découpage créer des sous-système appartenant à des organisations différentes (au sein ou non du même groupe, il ne s’agit pas nécessairement de SSII), ce qui « durcit » les interfaces : les organisations parentes ayant des objectifs différents, elles « blindent » leurs points de contact avec les autres.

Pour chaque interface, ce découpage engendre un besoin de formalisation de « contrats ». Cahier des charges, spécifications fonctionnelles détaillées, cahier de tests détaillés, etc… Le summum étant le contrat au forfait.
Ces contrats engendrent la nécessité de formaliser à l’excès un échange d’information qui pourrait être plus fluide, rester à un niveau synthétique, être complété de manière « ad hoc » dans un wiki, le meilleur passage de connaissance restant le biseau, en synchrone, formation des nouveaux par les anciens.

Le découpage crée la nécessité de pouvoir stocker une information pour la restaurer plus tard dans d’autres contextes (chez un sous-traitant qui n’a pas participé à l’effort initial d’élaboration de l’information, au tribunal pour justifier de ce qui avait été convenu, …) créer une formalisme qui serait –sans cette nécessité- inutile. La source de ce besoin en formalisme est la nature asynchrone de l’utilisation de l’information par les différents sous-systèmes.
Du coup, l’idéal est d’appliquer le principe du mode projet (que l’on soit en interne ou avec des ssii partenaires) selon son esprit : Tous à bord, tous dans le même bateau. En régie. Dans les mêmes locaux.

Ce découpage en sous-entités engendre aussi un besoin de synchronisation dans le temps.
Du coup chacun va publier son planning, ses jalons. Et déployer une énergie phénoménale à se synchroniser avec le planning des autres,
prendre des marges en annonçant ses dates et freiner des quatre fers à l’idée du moindre changement.
Changer une ampoule passe de 10 minutes à 3 semaines.

Autre exemple, caricatural mais réaliste lui aussi.
On n’a pas le budget qu’il me faut pour faire mon projet.
On en réalise un premier tiers cette année.
L’année d’après on en réalise un nouveau tiers.
L’année encore après on en réalise un troisième tiers.
Evidemment, les tiers ne durent pas toutes l’année, donc il y a des trous, pendant lesquels on libère les membres de l’équipe.
Quand on reprend le tiers suivant, on prend de nouveaux intervenants.
Et après le dernier tiers, on passe en maintenance, par une équipe encore différente.
On se retrouve avec un besoin de formalisation décuplé.
Comment faire passer à l’équipe suivante toute la compréhension métier et technique ?
On rédige tout, mais comme on n’a pas le temps de le faire au fur et à mesure, on le fait au dernier moment, en remontant péniblement le temps, avec une piètre qualité.


  • Prendre moins de monde (sacrifier les délais) pour garder les personnes en continu. Dans mon exemple, faire des tiers mieux étalés dans le temps, de façon à conserver l’équipe. Le « sacrifice » est donc d’étaler aussi les livraisons, donc d’avoir la release moins vite.
  • Embarquer un membre de l’équipe support dans le projet.
  • Embarquer un membre de l’équipe projet dans le support.


La nécessité de gérer la complexité d’un gros projet est indéniable. Le découpage en équipes est inévitable.
Ce découpage est fait pour des raisons commerciales (client / fournisseur), politiques, historiques, … que je peux comprendre mais qui aboutissent à un résultat qui n’est pas toujours optimum.
L’organisation d’un projet, calque parfois à tort sur la base de l’organigramme de l’entreprise (découpage fonctionnel, business d’un côté, IT de l’autre)
et pas sur un découpage ad hoc (feature teams).
Ce qui devrait compter, à tous les niveaux, y compris pour l’organisation, c’est la seule efficacité du fonctionnement du projet !

Et puis il y a l’aspect dynamique : J’ai visité il y a très longtemps un projet où les intervenants n’avaient pas de bureau fixe, où ils se regroupaient selon le sujet du sprint, afin d’optimiser les échanges. Cela m’avait impressionné.
A un niveau plus avancé : plutôt que de décréter ce qui sera efficace, faire intervenir les uns et les autres dans l’élaboration, sans y passer trop de temps, faire un essai, éprouver, faire un retour, changer ce qui a été élaboré, … Mais cela suppose que l’on admette que l’on ne sait pas et que l’on refuse de plaquer des organisation importées d’autres contextes, même si elles sont popularisées.

Publié dans Agile, Entreprise, Humain | 1 commentaire

Transformation agile agile : Les besoins et la valeur

Deuxième post d’une série sur la question : « la transformation agile de l’entreprise est-elle elle-même agile ? »

Je contribue à la transformation agile d’un grand compte industriel, au sein d’une équipe de 5 coaches. Cette série de post est un retour d’expérience visant à visiter mon retour d’expérience à l’aune des principes agiles. Un trait récurrent est de remettre en question l’applicabilité au pied de la lettre d’une analogie entre l’activité de transformation agile elle même et un projet gérable par Scrum (méthode agile la plus classique), tout en redécouvrant  les principes du manifeste agile.

La définition du produit : « Business people and developers must work together daily throughout the project »

Dans scrum, la définition du produit est assumée par le product owner, qui sait obtenir de ses interlocuteurs côté utilisateurs une compréhension du besoin et sait définir une vision. Ici en revanche la responsable au sein de l’entreprise de la transformation n’est pas forcément à même de se forger une vision. Elle a besoin de contributions de conseil que nous, prestataires consultants, fournissons. S’il fallait appliquer l’analogie, nous serions dans une situation où l’équipe est parfois plus compétente que le product owner sur la nature des actions à entreprendre. Du coup, que fait-on ? Lors d’atelier et d’échanges, la connaissance des rouages de l’entreprise va à la rencontre du savoir faire agile, et des propositions en sortent. En revanche, elle a la décision finale.

Le périmètre des sprints : « Welcome changing requirements, even late in development« 

Nous nous astreignons à tenir des itérations de un mois, validées par des démos.Or, il apparaît que de nouveaux besoins apparaissent souvent en cours d’itération, des opportunités de prêcher la bonne parole en adressant tel ou tel aspect non couvert jusque là. La décision est souvent d’accepter ces besoins.

S’il fallait appliquer l’analogie, nous serions en infraction avec le principe de protection du périmètre de l’itération, qui ne doit pas changer en cours.

Pour nous c’est différent : ok pour accepter ces nouvelles actions, après tout elles seront démontrées à la fin et illustrerons bien l’avancement, quitte à ne pas faire tout ce qui était prévu si ce n’est pas urgent.

Du coup nous passons à un mode un peu plus Kanban, en observant tout particulièrement la durée entre le début et la fin d’une action, et en limitant le nombre d’actions entamées à un moment donné.

Mesure de la valeur acquise : « Working software is the primary measure of progress. »

La démo, auprès d’un certain nombre d’acteurs côté DSI sanctionne l’effort, l’existence des livrables produits, pas vraiment le déploiement de l’agilité (comme « software » à installer dans les esprits).

Une vision qualitative nous vient de nos ateliers communautaires ou conférences de types « Open Space Technology ».

Pour être vraiment rigoureux, il faudra disposer de PKI (Indicateurs clefs de performance) sur les projets agiles et sur les autres, et comparer l’apport de l’agilité. Nous ne mesurerions pas notre action de transformation isolément, son impact étant confondu avec celui de l’agilité.

Une autre approche, que nous allons mettre en oeuvre, est de systématiser des revues de l’agilité des projets, et d’en agréger les résultats pour voir leur évolution dans le temps par exemple. Cet outil nous permettra plus précisément de voir l’impact de notre action. En revanche, il s’agira plus d’une évaluation de l’adoption (rendre les projets agiles) que de la transformation (rendre l’entreprise agile dans son ensemble, y compris le business, l’infrastructure, …)

Publié dans Agile, Entreprise, Humain | Laisser un commentaire