Coup de gueule contre certaines formations agiles

Je débute l’année par un coup de gueule contre certaines formations agiles. Je ne les citerai pas car je me permets ce coup de gueule sans avoir participé à l’une d’elles, sans connaitre les formateurs, ni la société qui les parraine (prenez donc ce coup de gueule avec les pincettes qui vont plairont). Je me permets ce coup de gueule en raison des feedback réguliers que j’obtiens des stagiaires qui y participent depuis la fin d’année 2010. Coup de gueule contre des formations où les gens sortent avec plus de troubles et de questions qu’avec une vraie réflexion ou un vrai apprentissage, et surtout le sentiment d’avoir un peu été mené en bateau (quand on plus on sait qu’il s’agit de formations certifiantes, chères, et que l’on connaît la valeur de la certification …. délivrée automatiquement en fin de session…). Coup de gueule contre les formateurs qui planent et qui répondent sans aucun sens commun, sans aucune mise en situation, qui trônent dans leurs éthers.

Voici certains des retours que j’ai eu :

“Pourquoi Scrum ?”

“Parce que cela va augmenter de 400% votre productivité ! ”

“ah… et pourquoi ?”

“Parce que c’est Scrum !”

ok on est bien avancé…

“Je travaille avec une équipe QA (assurance qualité) de 10 personnes en Roumanie, comment dois-je l’intégrer avec mon framework Scrum à Paris ?”

“Faites la venir en France”

C’est probablement une bonne réponse *dans l’absolu*, mais il est inconvenant de la limiter à cela. Je sais bien qu’il faille un électrochoc, et que devenir “agile” est un changement culturel fort. Je comprends et je pratique souvent la “réponse par une question” en formation, mais cela doit être un cheminement, une réflexion qui doit s’ancrer dans les pratiques en cours :  avec une mise en situation nécessaire, une mise en évidence des contraintes, des risques, des objectifs, etc.

Une connaissance me rétorque : “oui mais 2 ou 3 jours pour entamer une révolution psychologique personnelle c’est court”. Oui, naturellement, mais cette formation est souvent un premier pas essentiel. Si on a l’impression en sortant que le formateur a bouffé trop de champignons, c’est déjà un très mauvais départ, et cela ne va pas nous aider au quotidien !

Sur ce, meilleurs voeux 2011

* en haut à gauche : psilocybin, indispensable pour certaines formations agiles manifestement

This entry was written by pablo, posted on January 1, 2011 at 1:27 pm, filed under méthodes agiles, scrum and tagged coup de gueule, formation, scrum. Leave a comment or view the discussion at the permalink.

Soyez Agile

Nous déclenchons une offre agile plus étoffée : formations, petits déjeuners, accompagnement : http://formation.smartview.fr/soyez-agile/

This entry was written by pablo, posted on December 13, 2010 at 1:44 pm, filed under kanban, lean, méthodes agiles, scrum, XP and tagged agile, kanban, lean, scrum, XP. Leave a comment or view the discussion at the permalink.

La communauté “agile” se cherche (une certification)

La communauté agile semble se chercher actuellement, le succès l’étouffe-t-elle ?
Entre les grands penseurs qui sont parfois trop peu confrontés au réel, et les rapaces qui ont senti
l’odeur de l’argent frais (l’agile c’est un buzz ! c’est donc aussi du fric !), chacun essaye de se positionner et d’occuper le terrain (côté français je vois fleurir un institut, une fédération, cela pourrait être inquiétant. Je ne jette pas la pierre, toutes ces instances partent probablement d’une bonne idée et ont sûrement -sans ironie- un but avouable. Au passage agile-academie.com et .fr sont dispos, allez y !! -avec ironie-).

On assiste donc à une guerre de positionnement dont la certification est probablement la face la plus visible. Constat : la certification agile n’a pas de sens réel : soit on passe 2 jours (plus de 1000 euros) avec un coach agile et on obtient automatiquement la certification (ScrumAlliance), soit on paye 100 euros et on a le droit de passer un QCM pour avoir une certification (scrum.org).
Alors oui c’est mal car on se retrouve avec pas mal de gens qui n’ont aucune expérience réelle du terrain et qui sont certifiés. Mais est-ce que cela diffère des autres certifications ? ben non, pas vraiment à mes yeux. Est-ce que cela a de la valeur : très peu mais pas rien (j’ai passé du temps -2 jours- avec un coach agile, ou je me suis plongé dans le manuel (20 pages) de scrum.org avec un QCM au  bout) ; c’est déjà une différence n’en déplaise à certains. Le problème est plutôt que certains s’octroient le droit d’attribuer la certification, et que d’autres n’ont pas ce privilège.

Faut-il blamer quelqu’un ? Celui qui abuse du système en certifiant à tour de bras ou celui qui n’emploie que des gens “certifiés” sachant que cette certification n’a que peu de valeur ? J’opte pour l’acheteur. Sans demande, pas d’offre… Pour autant il est compréhensible que l’on souhaite s’assurer des compétences des personnes que l’on embauche ou avec lesquelles on va travailler. Il me parait cependant évident que les acheteurs doivent faire un effort concernant leur recrutement.

Est-ce possible de certifier en agile ? Pas moins que dans d’autre domaine. Cela a-t-il un sens ? Je suis moins convaincu. Le côté humain, conceptuel, contextuel jouent un rôle fort, comment dès lors proposer une check list permettant de valider les connaissances agiles de certains et industrialiser (argh) cela…

Alors faut-il certifier malgré tout l’agile et comment ? Je me baserai sur le modèle CMMi (que bien j’ai connu). Je certifierai une organisation, une entité, et non pas une personne, et à intervalles réguliers. En continuant ce parallèle avec CMMi, au lieu de pratiques j’évoquerai les principes et valeurs et je laisserai libre cours à l’entitée de les embrasser comme elle le souhaite. Mais je ne fais que repousser le problème (bien visible côté CMMi) : qui ??? a le privilège de certifier…

Et on retombe ainsi sur les errements actuels de la “communauté agile” : faut il un pragmatisme outrancier (quitte à faire tourner la machine à billets), ou faut-il se lancer dans de longues diatribes sur le changement culturel, le côté humain, etc… qui fleurent bon parfois le charlatanisme ou la croyance.  Au passage les deux ne sont pas si mauvais, négatifs. Oui c’est beau et bien de défendre un idéal, une philosophie (même si les clients ne cherchent pas forcément cela…enfin un salarié heureux est un bon salarié). Deuxio je ne vois aucun mal à gagner de l’argent avec l’agile. Il faut bien gagner de l’argent, si en plus on peut le faire en faisant ce que l’on aime…

Ca tiraille fort. Mais c’est bon signe aussi ces discussions endiablées, ces oppositions.
Et, pour adoucir mon billet, de mon humble point de vue, il y a une voie au milieu et la majorité des gens que j’observe semblent la choisir.

Ah je note que agile-certification est disponible en .fr (messieurs tirez les premiers).

Un très bon article sur les problèmes soulevés par la certification agile :

http://xprogramming.com/articles/csm-certification-thoughts/

Les faits m’accablent :

a) je me mêle à la meute concernant la certif agile
b) je suis certifié
c) je gagne de l’argent avec l’agile

image : http://www.flickr.com/photos/denverjeffrey/458846356/

This entry was written by pablo, posted on November 5, 2010 at 10:13 am, filed under méthodes agiles, scrum and tagged agile, certification, scrum. Leave a comment or view the discussion at the permalink.

Pour être “in”, jouez la “retro”

Pour ceux qui ne seraient pas encore au courant à la fin d’un sprint agile on fait (on doit faire ! on devrait faire !) la rétrospective. Son but : mettre en évidence dans le contexte de l’itération que l’on vient d’achever : ce qui a marché, ce qui n’a pas marché, ce que l’on pourrait améliorer.

En voici une (il s’agit d’un mix d’extraits entre plusieurs clients, que j’ai anonymisés), histoire de rendre les choses concrètes. Vous pouvez la juger, la dénigrer, l’utiliser, etc.

Comment : on regroupe toute l’équipe (équipe, scrummaster, product owner). On fixe 4 grands axes : “les plus”, “les moins”, “les optimisations à envisager”, “le plan d’action”. Le plan d’action étant constitué par les optimisations que l’on souhaite mettre en oeuvre dès à présent, ou qui concerne un évènement pour le prochain sprint. Presque une antichambre : si nous envisageons régulièrement la même optimisation il faudra se décider à la basculer dans “plan d’action”. De même on peut rapidement glisser dans “les moins” les éléments du plan d’action que l’on aura finalement pas ou mal mis en oeuvre. Chacun évoque les points qu’il souhaite mettre en évidence. Je n’interviens (en tant que ScrumMaster) qu’à la fin, mais j’ai mon mot à dire et si je peux influencer dans tel ou tel sens je n’hésite pas mais je ne tranche pas.

Mes commentaires en italiques.

Les plus

- Backlog et stories plus complets (Stories plus complètes : au niveau des tests d’acceptation et/ou des scénarios de validation)

- Réorganisation de l’espace, salle, post-it, etc. (chez ce client un espace dédié a été aménagé pour l’agilité durant le sprint).

- Motivation de l’équipe (se passe de commentaire, mais j’explique qu’il est normal avec Scrum d’avoir des équipes plus motivées. Par contre il est essentiel de faire signe quand la motivation n’est plus au rendez-vous, et surtout pourquoi. Tout le monde ne peut pas être motivé 100% du temps.)

- Intégration des tests unitaires dans la notion de fini (se passe de commentaire)

Les moins

- Mauvais découpage des stories et des tâches (trop de dépendances !)

- Ponctualité (se passe de commentaire)

- Un expert externe peut interférer sur le périmètre du sprint sans faire partie de l’équipe. (il faudra résoudre ce point si celui-ci se répète, c’est un point de vigilance)

- Cadence pas assez régulière (coup de collier sur la fin). La validation des stories doit être régulière. (se passe de commentaire, un point du plan d’action est dédié à ce problème)

- Difficulté à concilier le focus du sprint et les demandes externes (il faut protéger cette équipe)

A envisager/optimiser ?

- Intégrer la revue de pair dans la notion de fini (c’est à dire que dans ce cas elle s’applique sur toutes les stories).

- Meilleurs jeux de données.

- Plus/Mieux utiliser des normes de codage/développement/nommage. (XP…le pair programming va suivre…)

Plan d’action

- Validation régulière des stories (pas de coup de collier final) (sur le prochain sprint -3 semaines- on se fixe les premières validations sur la seconde semaine)

- Chaque membre de l’équipe annonce aux autres au début du sprint le nb de jours qu’il estime pouvoir accomplir sur le projet (des soucis d’estimation liés notamment au temps “réel” passé sur le sprint)

- Chart température équipe (un des participants sort d’une formation Scrum, on lui a parlé d’un chart décrivant la courbe du moral des membres de l’équipe, il souhaite le mettre en oeuvre. je vais lui passer le relais en tant que ScrumMaster pour prendre du recul. C’est sa première “mission” de ScrumMaster : établir ce chart et surveiller le moral des troupes)

- préparation en amont de l’arrivée d’un nouveau membre de l’équipe (annoncée le mois prochain il faut préparer cette arrivée, la dernière fois on a perdu un temps fou !)

Voilà. La rétrospective dure une heure max. J’affiche au mur (radiateur) uniquement le plan d’action. Naturellement plus celui-ci sera concis plus il sera suivi.

The prick.

Images : Grotto in an iceberg, photographed during the British Antarctic Expedition of 1911-1913, 5 Jan 1911, http://www.flickr.com/photos/nationallibrarynz_commons/4078337967/

This entry was written by pablo, posted on October 17, 2010 at 1:52 pm, filed under méthodes agiles, scrum, XP and tagged retrospective, scrum. Leave a comment or view the discussion at the permalink.

Scrum : Ne faites pas de sentiments

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 pablo, 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.