L’Agilité expliquée à mon cheval

question

_Tu es coach Agile non ?

Oui pourquoi….

_Bah ça m’intéresse Agile, tout le monde en parle, c’est  à la mode, il faut que je m’y mette à ce truc nouveau.

Nouveau…oui, enfin, tout est relatif… c’est apparu dans les années 90.

_Ah… bon ça m’intéresse quand même, mon chef m’en parle tous les jours. Moi je veux être Scrum Master. Je veux être le master, le chef, le masterchef. Le masterchef de l’Agile !

D’accord… mais le Scrum Master c’est pas un chef…. C’est un serviteur de l’équipe de développement.

_Ah… bon… C’est pas un travail pour moi. J’aime rendre service mais c’est  pas mon métier de rendre service. Bon, on m’a parlé de Product Owner. Ca ça m’intéresse ! Le Product Owner c’est le chef de projet non ?

Bah… non en fait. Le Product Owner c’est le serviteur du produit. Il priorise constamment le besoin, en tenant compte des feedbacks utilisateurs, mais ne donne aucun ordre à l’équipe de développement.

_Aie… c’est pas trop mon truc d’être serviteur au travail je te l’ai déjà dit. Bon, finalement je vais être développeur. C’est sympa ça développeur, j’ai fait un peu de Java à la fac, c’est coooolll. Je mettrai des t-shirts et j’aurai des tatouages et on me laissera tranquille derrière mon ordinateur.

Ah bonne idée je te vois bien avec des tatouages. Bon tu sais faire du Test-Driven development, du Behaviour-driven development, du refactoring, et travailler en interaction avec ton équipe ?

_ ….. Bon, on verra ça quand tu m’expliqueras quelle langue tu parles. En tous cas moi je veux être dans une équipe agile. Plus de planning, plus de documentation, plus de deadline. Je livre quand je veux, ce que je veux…..

En fait tu dois livrer toute les 2 semaines un incrément de produit qui répond à ce que veut ton Product Owner, qui fonctionne, ne contient aucun bug, possède tous les tests automatisés, et soit potentiellement déployable immédiatement en production.

_Ouh la tu te moques sûrement de moi là. Ca n’existe pas ça. Mais bon, si ça existe, le manager il n’a plus rien à faire ! C’est une bonne nouvelle si je veux devenir manager non ?

Pour que ça fonctionne, et parce que c’est si difficile, le manager a un rôle primordial à jouer, il doit démêler les problèmes que l’équipe ne peut régler elle-même, faire en sorte que l’équipe soit en mesure de répondre aux besoins du métier et doit la protéger des perturbations extérieures. En fait il est au service des différents acteurs.

_Mais tout le monde est au service de tout le monde, c’est un monde utopique ça ! C’est les bisounours votre histoire d’agilité, avec ces histoires de bienveillance. Nous sommes entre adultes, on s’en fiche de la bienveillance.

Ca dépend. Regarde un peu autour de toi et tu verras que la bienveillance est recommandée par des experts pour que le moral des employés soit meilleur. Et sache qu’un salarié qui a le moral et plus productif qu’un salarié qui n’a pas le moral.

_Ah bon ? Ca alors, on en apprend tous les jours ! Mais bon, il y a un truc choquant dans vos histoires, c’est cette notion de droit à l’erreur. Non mais tu te rends compte ? Imagine si je prends l’avion et qu’on me dit que le pilote a le droit à l’erreur !

Sache que les pilotes de lignes sont fortement encouragés après un vol à  signaler tout faute même la plus bénigne à un comité spécialisé pour recueillir ces faits.

_Ah ça c’est bien ! J’espère qu’ils sont sévèrement punis !

Et bien non ils ne sont jamais punis. Chaque erreur est considérée comme résultant d’une défaillance du système, qu’il faut corriger, pour empêcher ces erreurs de se reproduire. On préfère prévenir plutôt que punir, et apprendre de ses erreurs.

_Bon tu m’as eu là. Mais la personne qui gère le budget, c’est un beau poste non ? Puisqu’en Agile, justement, il n’y a plus de budget !

Le budget… disons que sur un projet Agile, le budget est constamment re-priorisé, en quelque sorte. Puisqu’il est connu qu’en règle générale, environ 80% des utilisateurs utilisent 20% des fonctionnalités d’une application, et bien on essaye d’avoir assez de budget pour produire les 20% les plus importants. Et une fois que c’est fait, on réévalue quels sont les prochains 20% les plus importants, ou bien… on peut également décider de se contente de ce qui a été livré, et passer à un projet qui deviendrait encore plus prioritaire.

_…. Tu as réponse à tout toi, un vrai consultant ! Bon il faut quand même que je te dise que vous me faites un peu de la peine avec vos Troubles Obsessionnels Compulsifs, vous les agilistes.

Ah ? Des TOCS ? Comment ça ?

_Oui vous ne pouvez pas vous empêcher de gribouiller des post-its et de les disperser sur tous les murs que vous trouvez. Et vous avez cette manie de vous mettre debout en cercle tous les matins pendant 15 mns. Et au bout de 15mns pétante on dirait qu’un démon vous invoque de regagner immédiatement vos places. Ca se soigne tout ça. On dirait que vous participez à un TOC-Show !

Oui on aime bien utiliser des post-its pour que chacun puisse exprimer ses idées, et effectivement conférer chaque matin pour s’adapter quotidiennement à un contexte changeant. Et je crois qu’une fois qu’on y a goûté ça ne peut pas se soigner.

_Ouai ouai ouai, enfin ne me dis pas que vous aimez pas faire un peu les malins. On dirait que vous prenez un malin plaisir à faire des choses complètement à revers du bon sens. On m’a révélé, pour ne rien te cacher, que vous écrivez des test avant de développer, et que vous vérifiez que ces tests échouent avant de développer. Et vous trouvez ça drôle ?

Et est-ce que tu trouves drôle le fait de donner une tâche à un développeur, d’attendre qu’il livre, et seulement à ce moment -là effectuer des tests dont il n’avait même pas idée, pour lui dire qu’il aurait dû développer autrement ?

_Non, ça c’est pas très drôle et j’espère bien que c’est pas la vraie vie.

_Bon, finalement, j’ai trouvé !

Oui ?

_Je vais faire coach agile ! C’est sympa ça coach agile ! Tu vois les équipes de temps en temps, tu leur expliques comment ils travaillent mal, tu leur fais des slides sur Scrum… C’est top !

Oui…. Est-ce que tu sais avoir de l’empathie pour les personnes, les encourager à prendre du temps pour s’améliorer tout en livrant leur projet à temps, à repérer les forces de chacun de tes interlocuteurs pour l’aider à jouer sur ses forces, à montrer à une équipe comment ne pas appliquer la méthodologie by the book mais à trouver leur propre voie ?

_Bon, Constance, quand est-ce que je prends un rendez-vous avec toi pour me faire soigner… euh… coacher ?

Mob programming: start signal

We finally gave Mob Programming a try here at Amadeus IT Group !  If you don’t know what Mob Programming is, you can find more information on mobprogramming.org.

How did we finally get there? The first step was a one-hour presentation of the concept of Mob Programming by Woody Zuill in the Boston office of Amadeus IT Group. He graciously accepted to give this talk to us, and we thank him again for that. We are based in Nice, in the south of France, and attended the meeting via webex. One Scrum Master was very impressed by the presentation and talked about it to his team. So they asked me to give them more details about this “technique”, which I did, and at the end we decided to give it a try. The main reasons were:

  • When working individually we accumulate some specialized knowledge, that we don’t share with the others
  • When working alone, we usually give up the practices like TDD (and in fact the team had  even never started to do TDD). Perhaps when working together, there will be a sort of emulation to use more good coding practices.

We decided to schedule five initial half-day mob programming sessions, as an experiment. Because that’s what agile is: trying things and see if it works for us.  As I was a little anxious, I had a quick skype session with Woody Zuill the day before and he told me that the best way to start with mob programming is to try to find something to do out of the “business as usual” stuff. You can for instance start with some sort of coding dojo with the whole team, with a coding exercise like Fizz Buzz. There is no pressure when you do this exercise, and the team will be more able to focus on trying to develop good interactions.

Another tip that Woody gave me was to start with frequent rotations, something like every 4 minutes, so that the team members get used to those rotations (it can be counter-intuitive for a developer that is used to work alone).

Last but not least, Woody insisted that mob programming works well if you use TDD. If not, how can you be sure not to accumulate technical debt and defects when you mob?

So there we were, 4 people in the same room (unfortunately one of developer was in training this day). We decided to work on one of the bugs that the team had to solve. We started with one that was less complicated that the others (even if on this project, all bugs are complicated).

We used the Attila Buturla’s mob timer and there we went, 5mns rotations. It was interesting to see that from the very beginning, the team members noticed some simple things about how each of them configures its coding environment, and rapidly began to exchange tips and tricks. When you mob, you really share the details, not just the big picture.

The teams members quickly got used to rotating on the keyboard. Even if Woody Zuill recommends using the strong-style pairing style, we did not get to it, because sometimes the person at the keyboard was the only one knowing what to do.

As I said before,  the bug we had to solve was quite complex, but we rapidly noticed that everyone could bring its own expertise to try to find a solution. At the end of the 3 hours sessions, the team did not solve the problem, but knew what documentation they had to look at to find the solution. As we had to leave the meeting room at the end of the 3-hours sessions, we decided that one of the team members would look at the documentation, and we would work again on the problem as a mob during the next session, which was scheduled two days later.

We made a short retro at the end of this first session, and one of the things that came up was that “it was fun”. The team had some doubts about whether it made them more productive than working alone, because they told me they already have great interactions throughout the day. We also decided that it is better to plan two half-day sessions in the same day so we really have time to solve a problem, and not stop in the middle. Or we can have two half-day sessions on two consecutive days.

Anyway, what stands out is that the team found that it was fun, and I think it’s really a good reason to continue the experiment. If we can make work fun,  it will certainly increase our motivation, and hence make us work better. It’s as simple as that. I am pretty sure that we cannot scientifically measure if we are more productive with mob programming, at least not after the first sessions, but if we can notice that we work better as a team, it is a very good reason to keep on doing it. Next mob programming sessions are coming next week, I will continue to share our experiences in the next blog posts.

The blame culture can destroy a team

I had the great pleasure to be interviewed on March 2015 by Vasco Duarte for the Scrum Master Toolbox Podcast.

There were 5 episodes, on five different topics.

One of them was about how the blame culture can destroy a team.

You can listen to it on this link :

http://www.scrum-master-toolbox.com/2015/03/podcast/nicolas-umiastowski-blame-culture-can-destroy-team/

Don’t hesitate to leave a comment on this episode, I would be glad to hear your onw thoughts about this unfortunately common topic.