me retrouver : |
smartview |
twitter |
slideshare |
linkedin |
3 derniers articles : |
Shadoks, freins, changement, cynefin |
coach retreat paris, 2012 |
Stoos network, un départ, des attentes |
recherche | archives | catégories | à propos
Sous ce titre un brin provocateur je ne recherche pas l’affrontement. Au contraire c’est la neutralité que je souhaite mettre en exergue. Ne faites pas de sentiment : soyez totalement neutre.
Exemple, vous déployez Scrum au sein d’une organisation ayant pignon sur rue (disons un grand compte), avec des habitudes, des méthodes, des gens qui ne vous ont pas attendu pour délivrer un produit. Mais vous voilà qui débarque avec votre “agilité”.
Support, documentation, QA viennent aux nouvelles.
Qu’en sera-t-il des spécifications (sur lesquelles la documentation se fonde), qu’en sera-t-il des tests ? qu’en sera-t-il de la documentation ? etc. etc. Ma position est simple (ce qui ne veut pas dire qu’elle est facile à tenir) : voici l’état des lieux, voici nos objectifs dictés par la création de valeur, voici notre planning, voici le périmètre actuel, voici la méthode, etc. Vous estimez que nous devons intégrer ce niveau de documentation pour pouvoir vendre le produit ? Très bien, j’en fais part à l’équipe et au product owner (ou mieux : aller leur en parler !). Ce dernier décidera (probablement pas seul d’ailleurs, il est le représentant investi des pouvoirs d’un groupe de travail plus vaste) de la priorité à donner à cette création de valeur. L’équipe proposera peut-être d’intégrer ce point dans leur notion de “fini”. Il faudra probablement se demander si la documentation que vous réclamez est réellement porteuse de valeur. Pourquoi et comment.
Je n’ai pas la réponse, vous avez réponse, ils ont la réponse. (Le consultant dans sa pose la plus obscène s’écrient certains).
Nous affichons clairement nos objectifs, nos priorités, le contexte, le calendrier, la notion de “fini”, etc. On peut essayer des choses si on n’est pas sur de la bonne solution. On analysera vite si cela a fonctionné ou non.
Transparence, Inspection, Adaptation.
Je réponds finalement souvent : “je ne sais pas, qu’en penses-tu ?”. Mon rôle est d’accompagner, protéger, garantir, expliquer, faciliter, lever les ambiguïtés, mettre en évidence, etc (sur ma mission actuelle et qui sert de décor à ce post j’ai un rôle ambivalent entre le coach agile et le scrummaster, certains vont crier à l’hérésie, perseverare diabolicum). Que les arbitrages et les priorités soient clairs, basés sur les bons indicateurs, communiqués. Que le droit à l’erreur et à l’essai soient permis.
Je n’ai pas de parti pris, pas de sentiment, je suis neutre.
Il m’arrive aussi de dire : à telle date nous aurons un feedback assez conséquent pour estimer si cela marche ou si c’est un échec (sous entendu le déploiement de Scrum fonctionne-t-il ou est-il un échec ?). Nous prendrons une décision en fonction d’indicateurs clairs et transparents.
Transparence, Inspection, Adaptation.
Cela peut irriter. Et là tout dépend de la psychologie (ouh là là comme c’est galvaudé) du Scrummaster ou du coach agile. Est-ce pour cela que Ken Schwaber dans une célèbre vidéo renomme le scrummaster, the prick… (la piqûre, mais en argot : la bite, la queue…) ? Oui très certainement, nous pouvons irriter.
Attention, un dernier point, rester neutre ne veut pas dire ne pas encourager ou féliciter l’équipe, ou au contraire lui dire que l’on est surpris ou déçu dans certains cas.
The prick.
* photo by m4r00n3d
http://www.flickr.com/photos/mar00ned/193863350
This entry was written by , posted on September 26, 2010 at 4:56 pm, filed under gestion projet, méthodes agiles, scrum and tagged adaptation, inspection, prick, scrum, transparence. Leave a comment or view the discussion at the permalink.
La notion de transparence est très importante dans les méthodes agiles type Scrum (mais pas uniquement là). C’est une façon d’être (être transparent) qui devrait être appliquée dans tous les cas (Agile, CMMI, qu’importe même aux projets sans méthode). Chez Scrum on associe la notion de transparence a celle de courage il me semble, sous-entendu : qui aurait envie d’aller se confronter à un client pour lui annoncer une très mauvaise nouvelle, ou qui a envie de prendre le risque de dénoncer le fait qu’il a échoué, etc, ce n’est jamais simple mais c’est essentiel.
Le mot courage est assez parlant, il faut l’associer dans notre cas à la maturité, l’expérience. A mon avis le courage de la transparence vient avec les années, avec l’expérience. Mais ici nulle question de moralité contrairement a ce que pourrait sous-entendre transparence que l’on rapprocherait de honnêteté, mais juste de réalisme économique, bref lorsque l’on travaille dans le privé : de maturité ! En effet, et c’est pourquoi j’insiste sur le fait que cela n’est pas exclusivement lié aux projets agiles, le fait de ne pas être transparent avec son client aboutira systématiquement par une perte de productivité et d’efficacité. Au plus tôt une anomalie est décelée, au plus tôt elle doit être traitée, au plus tôt un quiproquo voit le jour, au plus tôt il faut lever celui-ci. Tout ce qu’on laisse en chemin de façon délibérée (opaque) se retrouvera nécessairement sur notre route plus tard, et devra être traité avec des coûts plus élevés sans nul doute. C’est pour cela que je parle de productivité et d’efficacité au travers de la transparence. C’est une notion révélée par les méthodes agiles car elles nous obligent -par une constante itération et par mise à nu fréquente des résultats- à être transparent.
Suis-je clair ?
Je rebondis en fait sur un commentaire réalisé ce jour ici.
This entry was written by , posted on September 8, 2009 at 6:41 pm, filed under méthodes agiles and tagged courage, efficacité, honnêteté, productivité, scrum, transparence. Leave a comment or view the discussion at the permalink.