Bienvenue sur Développement Agile

Référence sur le développement logiciel Agile. Nous traitons de conception, de programmation, de pratiques de génie logiciel, d'essais et d'autres sujets connexes.

Coach versus consultant

Publié par Louis-Philippe Carignan le mardi 2 juillet 2013 à 22:00

Lors d’une formation récemment, j’ai beaucoup aimé l’image suivante pour comparer un coach à un consultant.

Imaginer que vous êtes le client et que vous avez votre tasse devant vous. Votre tasse représente votre problème en entreprise. Tenez la tasse dans votre main. C’est présentement votre problème.

Lorsque vous engagez un consultant, vous lui donnez votre tasse en lui demandant de régler le problème. Cette façon de faire s’applique dans beaucoup de cas. Lorsqu’il faut fabriquer une solution logicielle et que vous n’avez pas les effectifs pour la produire dans les délais prescris, vous donnerez votre tasse à une firme de consultants pour qu’elle solutionne votre problème. En termes plus larges, le consultant va offrir plusieurs solutions au client.

L’approche est différente avec un coach. Lorsque vous engagez un coach, il vous demande plutôt de garder la tasse dans vos mains. Il est simplement là pour vous aider à résoudre votre problème puisque après tout, c’est votre tasse à café. Le coach assume que vous détenez la solution et qu’elle émergera par des questions fortes. Vous devenez alors partie prenante de la solution ainsi que de sa mise en place.

Mots-Clés :

Mon appréciation des cours du Agile Coaching Institute

Publié par Louis-Philippe Carignan le mardi 2 juillet 2013 à 18:00

Depuis les 2 dernières années, j’ai eu l’occasion de suivre deux cours du Agile Coaching Institute (ACI). Cet institut fût fondé par Lyssa Adkins et Michael Spayd. Lyssa est l’auteure du livre « Coaching Agile Teams » tandis que Michael est sur le point de publier son propre livre, « Coaching the Agile Enterprise ». Grosso modo, l’objectif du ACI est de coacher les coachs Agile.

En juin 2011, j’ai suivi le cours « Coaching Agile Teams » qui est un bon condensé du livre de Lyssa mais avec beaucoup d’interactions. Par exemple, le manuel du participant ne tient que sur une vingtaine de pages. À chaque segment du cours, on voit un peu de théorie pour ensuite mettre la théorie en pratique. On se sert donc du manuel pour prendre quelques notes à propos de la théorie ainsi que noter nos propres expériences lors des exercices. Lors de ce cours, j’ai pu mieux comprendre toutes les facettes d’un coach Agile. Par exemple, j’ai pu faire la différence entre un mentor, coach et facilitateur, trois des postures demandées par un coach Agile. Dans un autre segment du cours, nous avons pratiqué l’écoute active par des exercices et en étant jumelé avec différents individus, on identifie rapidement nos forces et nos faiblesses en ce comparant à nos coéquipiers.

En juin 2013, j’ai alors suivi le cours « The Coaching Stance » qui est la suite du cours que j’avais suivi en 2011. Je me compte chanceux d’avoir suivi ce cours lors de la rencontre annuelle des formateurs de Scrum.org puisque j’ai pu travailler avec des coachs d’expérience. Par exemple, lors d’un exercice, on devait donner du feedback à notre coéquipier. J’ai pu voir comment un coach sénior donnait du feedback et ainsi cibler des points d’amélioration en ma propre personne.

Un point fort de cette formation est le détail d’une conversation qu’un coach a avec son client. Chaque conversation débute en ciblant le sujet dont on veut parler suivi d’une période d’exploration où le client doit répondre à une série de questions fortes posées par le coach. Lorsque le client identifie des pistes de solutions, le coach ferme la conversation en lui offrant une demande ainsi qu’un geste d’imputabilité pour faire un suivi dans des délais raisonnables.

Encore une fois, ce second cours est accompagné d’un manuel d’une vingtaine de pages qui sera remplit de nos propres expériences et commenté d’un peu de théorie. Lors de ce cours, le segment à propos du « Design Alliance » est un vrai bijou. Sans rentrer dans les détails, Lyssa qualifie ce sujet comme étant « Team norms on steroids ». Et c’est exactement ça. En résumé, on voudra dresser un code de conduire lorsque l’équipe va dérailler. Comme exemple pour mieux apprécier le concept, on raconte comment il peut être important de discuter avec les passagers qui sont à côté de nous dans l’avion. Lorsqu’il sera temps d’aller au petit coin, que ferons-nous si la personne à côté de nous dort? Il faudra bien la déranger pour se rendre aux toilettes. Pourquoi ne pas en parler avant pour déterminer comment gérer cette situation. Il est donc préférable d'eéchanger auparavant pour que tout le monde soit d’accord lorsque cela arrivera. C’est le même concept avec son équipe Agile. On se définit des règles pour gérer des conflits qui ne sont pas encore arrivés, question que toute l'équipe soit d’accord sur les mesures à prendre lorsque ceux-ci auront lieux.

Lors des deux cours, je n’ai pas eu le temps de regarder ma montre et j’avais le sentiment de bien avoir investi mon argent. Les formateurs interviennent lorsqu'on se pratique pour qu'on identifie nos points faibles. Certains exercices sont en groupe pour que tous puissent apprendre en même temps avec le feedback des formateurs.

Je recommande ces deux cours aux Scrum Masters et coachs Agile qui désirent améliorer leurs aptitudes au travail. Mais je conseille aussi ce cours aux gestionnaires et chargés de projets qui aimeraient inclure cette dimension à leur carrière. Par exemple, l’écoute active est une habileté fort utile pour un gestionnaire et le temps passé à la pratiquer lors de ces deux cours lui sera certainement bénéfique à son retour au travail. À plusieurs occasions, j’entends des gestionnaires me confier qu’ils aiment bien aider leurs subordonnés identifier leur profil de carrière. Je crois que plusieurs éléments dans les cours du ACI peuvent aider les gestionnaires qui désirent accompagner leur personnel. L’écoute active. Poser des questions fortes. Ces thèmes ne font, qu'à mon avis, améliorer l'étoffe des gestionnaires.

Le ACI offrira bientôt le cours « The Agile Facilitator » qui, vous l’avez deviné, tourne autour du thème de facilitateur. Puisque Michael est un Certified Professional Facilitator (CPF), il a sûrement monté un cours à cet effet. J’invite les Scrum Masters qui lisent ce blogue à garder un œil pour ce cours.

J’ai aussi une opinion favorable envers Lyssa, Michael et leur initiative. Ils ont cerné un créneau dans l’Agilité, coacher les coachs, qui était absent mais nécessaire dans notre profession. Grâce à leur leadership, ils vont définir ce qu’est un coach Agile. Par exemple, ils visent utiliser les « learning objectives » du International Consortium for Agile (IC Agile) pour définir les trois types de coach : Scrum Master (ou Team Facilitator), Agile Coach (ou coach de Scrum Masters) et Enterprise Agile Coach. L’image suivante, prise de leur site, résume bien ces trois niveaux de coaching :

Icagile Coaching 

Finalement, les gens du ACI ne saisissent jamais l’occasion pour ridiculiser les autres experts en Agilité. Dans les dernières années, j’ai souvent lu des chicanes entre Scrum et Kanban, le ridicule envers l'absence de pratiques d’ingénierie sous Scrum ou des moqueries à l’égard des certifications Scrum. Le ACI ne se permet pas une telle critique et cela est tout à son honneur. Ils s’élèvent au-dessus de la mêlée pour le bien de notre profession et non celui de leur porte-feuille.

Visualisons notre profession

Publié par Louis-Philippe Carignan le vendredi 14 juin 2013 à 16:00

Des fois, j’aimerais être un architecte ou un graphiste pour qu’on puisse voir mon travail. Plus d’une fois, lors de réunions de famille ou des soirées entre amis, j’ai à expliquer ce que je fais. J’aimerais tellement sortir mes plans ou mes dessins pour qu’ils comprennent tout de suite. Hélas, expliquer le travail d’un coach Agile ainsi que ma profession en général peut prendre plusieurs minutes pas toujours plaisantes. Des fois, je dis simplement que je suis physicien nucléaire pour m’éviter des questions. D’autres fois, je dis que je suis chanteur dans un band rock, Skydome pour faire un clin d’œil aux Invincibles. Malheureusement, pas assez de gens réalisent ce clin d’œil. M’écoutaient-ils vraiment?

S’il y a une profession qui est virtuelle, c’est bien en technologie de l’information que l’on peut la retrouver. Mais puisque l’être humain comprend rapidement par la force des images, voici ma tentative de présenter ma profession en quelques images.

Picasso

Ma profession est abstraite. À ma connaissance, le développement de logiciel est la seule profession où on peut affirmer que nous avons rien fait de concret à la fin de la journée puisqu’en somme, le produit de notre travail est une pile de 0 et de 1 sur un ruban magnétique.

Bmxbikejump

Produire un logiciel fiable, de qualité en répondant aux attentes de notre clientèle, c’est extrêmement difficile. En plus de conjuguer les besoins du client tout en respectant les petits détails du langage de programmation, il faut travailler en équipe, comprendre le domaine d'affaires du client, faire son possible pour respecter les échéanciers et continuellement rester à jour avec les technologies émergentes.   

Nerd

Vous pensez probablement à cette image lorsqu’on vous dit qu’on programme toute la journée devant un ordinateur. Pourtant, certaines études affirment que 50% de notre temps est passé à socialiser avec nos collègues et notre clientèle.

Juggler

Pour nous, on se voit plutôt comme ça. On jongle avec plusieurs problèmes en même temps. On essaie de rien échapper dans du code pas toujours lisible. Pendant que nous travaillons sur un problème, notre inconscient réfléchi au problème de hier. 

Whiteboard

Nous adorons résoudre des problèmes, aussi complexes soient-ils. Nous sommes curieux et intéressés par une panoplie de sujets orthogonaux et avons un appétit pour de l’information qui ne nous ait pas toujours utile dans l'immédiat.

Flowers

Et finalement, nous adorons faire plaisir aux gens. Nous sommes très sensibles aux petits détails. Nous serons gênés si les attentes de nos clients ne sont pas comblées puisque nous sommes très fiers de notre travail.

Mots-Clés :

33 modèles organisationnels sous Scrum

Publié par Louis-Philippe Carignan le mardi 4 juin 2013 à 12:00

J’adore les auteurs qui font des ouvrages de référence en informatique. Je trouve ces gens courageux de répertorier de façon exhaustive un volet de notre profession. À ma connaissance, ils le font par altruisme puisque les nombreuses heures passées à documenter et réviser ces ouvrages ne sont probablement pas les plus palpitantes d’une vie. J’aime aussi lire le dédicace que les auteurs en informatique offrent au début de leur livre. Les avez-vous déjà lu? Habituellement, ils remercient leur femme (ou mari) pour le support moral lors de ces nombreuses soirées où l’auteur devait travailler seul.

Mes deux ouvrages de référence préférés sont Design Patterns et xUnit Test Patterns. Lorsque ma candidature pour devenir un Certified Scrum Coach (CSC) à la Scrum Alliance a été refusé la première fois, on m’a référé le livre Organizational Patterns of Agile Software Development de James O. Coplien et Neil B. Harrison.

Ce petit bijou de 400 pages a été une révélation pour moi. Ces auteurs avaient documenté les modèles organisationnels Agile et ce, bien au-delà des fameuses techniques/pratiques que je connaissais déjà (TDD, BDD, refactoring, intégration continue). Il faut faire attention au terme « modèle organisationnel ». On ne parle pas de modèle pour structurer une organisation. Puisqu’un « design pattern » en programmation est traduit par « modèle de conception », j’étais tenté de traduire « organizational pattern » par « modèle organisationnel ». Il faut bien s’entendre donc qu’un modèle organisationnel dans ce billet représente, à mes yeux, une façon de faire dans le but de rendre l’organisation plus agile à la fin de la journée.

Coté 5 étoiles sur 5 chez Amazon.com, le livre de Coplien et Harrison répertorie les modèles que l’on peut mettre en place pour qu’une organisation de développement logiciel livre de la valeur. N’oubliez pas que modèle organisationnel n’est pas synonyme de bonne pratique. Pour les lecteurs proches du PMBOK, garder en tête qu’une organisation Agile comprend qu’elle est dans un environnement complexe et que la mise en place de bonnes pratiques n’est pas suffisante pour s’adapter à l’environnement complexe du XXIième siècle. Les modèles dans le livre permettent d’avoir une organisation vivante qui est en mesure de s’adapter aux problèmes qu’elle fait face dans un environnement en constante évolution.

33 modèles dans Scrum

J’avais lu dernièrement un billet sur le blogue de Jeff Sutherland (Scrum Inc.) où l’on avançait que Scrum comportait 33 modèles organisationnels :

Recent work by Jim Coplien shows that Scrum is deceptively simply while compressing a complex array of organizational patterns in his book, "Organizational Patterns in Agile Software Development." Jim was surprised when he found that Scrum compresses at least 33 patterns from his book into a concept that can be explained in 2 minutes.

Un lien vers la présentation de Coplien permet de voir cette décomposition. Entre les diapositives 20 et 23, on peut voir plusieurs modèles répertoriés par catégorie. À la diapositive 24, on peut finalement voir les 33 modèles dans une seule hiérarchie.

Scrum Organizational Patterns

À la gauche complètement de cette image, le premier modèle est « Community of Trust ». On prend ensuite différent chemin, c’est-à-dire qu’on ajoute de nouveaux modèles au précédent. Finalement, tous les chemins menant à Rome, c’est-à-dire que le dernier modèle qu’apporte Scrum a une organisation est le « Team Pride ».

Si vous comptez les bulles bleues, vous devriez arriver à 33.

De la théorie à la pratique

J’entends déjà les lecteurs pragmatiques quitter ce billet puisque tout ce volet est beaucoup trop théorique. J’aimerais illustrer comment ces modèles se conjuguent à votre réalité.

Prenons le chemin dans le haut de l’image précédente, c’est-à-dire les bulles suivantes où les parenthèses réfèrent aux modèles dans le livre de Coplien: 

  • Community of Trust (p. 34)
  • Work Queue (p. 62)
  • Informal Labor Plan (p. 64)
  • Developer Controls Process (p. 70)
  • Group Validation (p. 174)
  • Team Pride (p. 128)

Décortiquons maintenant chaque modèle. Voyons comment Scrum le met en place et comment chaque modèle vient appuyer le prochain. Dans les sections suivantes, le texte en gras est extrait du modèle organisationnel dans le livre « Organizational Patterns of Agile Software Development ». Un court texte suit pour expliquer concrètement la mise en application de ce modèle dans une équipe Scrum.

Community of Trust

It is essential that the people in a team trust each other; otherwise, i twill be difficult to get anything done.

Do things that explicitly demonstrate trust. Managers, for example, should make it overtly obvious that they facilitate the achievement of organizational goals, rather than playing a central role to assert control over people. Take visible actions to gve developers control over the process.

Avant de mettre tout autre modèle en avant, il faut tout d’abord que l’équipe se fasse confiance. Et c’est ce qu’on essaie de faire avec les trois piliers de Scrum dont la transparence est le premier. En étant transparent, autant dans son travail que dans ses relations avec ses collègues, on débute par bâtir une communauté de confiance dans l’équipe Scrum.

Work Queue

It is difficult to perform linear, monochronic scheduling in light of implied requirements. 

Produce a schedule that is simply a prioritized list of work. Use the list of implied requirements as a starting point to situate them into a likely implementation order, favoring the more urgent or higher priority items.

Dans son livre, Coplien compare le product backlog de Scrum à ce modèle. En effet, on demande toujours de mettre tout (fonctionnalités, cas d’utilisation, histoire utilisateur, requis non-fonctionnel) dans un seul et unique product backlog. On ne retrouve pas une liste de bogues dans un backlog à part. Si c'est votre situation, posez-vous la question en réfléchissant sur ce modèle.

Avec Scrum, cette seule et unique liste est la concrétisation du modèle « Work Queue ». Une fois que l’équipe se fait confiance, elle peut alors attaquer les items du product backlog.

Informal Labor Plan

A schedule of developer work tasks can both assist workers in planning their time and provide reassurance to stakeholders about scheduling expectations.

Let individuals devise their own short-term plans.

Maintenant qu’on connaît le travail à faire dans le product backlog grâce au modèle « Work Queue », l’équipe peut maintenant s’attaquer aux items les plus importants de cette pile. Avec Scrum, on prescrit le carnet d’itération comme étant le plan de livraison que l’équipe doit mettre en place au début de chaque itération pour livrer la commande au client. À mon avis, c’est une mise en application de ce modèle. On demande à l’équipe de faire son propre découpage en tâches. Si le plan de livraison n’est pas assez précis, le product owner a le droit de questionner le carnet et ainsi demander des précisions pour calmer ses inquiétudes.

Developer Controls Process

A development culture, like any culture, can benefit from recognizing a focal point of project direction and communication. 

Make the developer the focal point of process information.

Avec Scrum, on peut souvent lire que l’équipe est le moteur d’une organisation. C’est elle qui transforme des requis périssables en livrable. Pour exprimer ce point de vue de façon imagée, j’ai déjà entendu l’analogie suivante : une équipe Scrum, c’est un peu comme une Ferrari sur un gros paquebot.

 Ce que ce modèle prescrit, c’est de mettre le développeur au centre du processus de développement. J’extrapole un peu ce modèle pour Scrum où je remplace le mot « développeur » par « équipe ».

Group Validation

Product quality is crucial to the success of the enterprise. 

Even before engaging QA, the development team – including the customer – can validate the design.

Selon ma compréhension de ce modèle, l’équipe doit se valider pour assurer un livrable de qualité. Avec Scrum, cela prend forme à quelques endroits pendant une itération. Tout d’abord, l’équipe se concerte à chaque jour lors de mêlée quotidienne. C’est une validation informelle à mon avis. Une deuxième validation formelle est la revue d’itération pour assurer la qualité du produit.

Mais il y a aussi des moments plus informels dans Scrum comme une revue de code commune (coding dojo) ou une séance d’analyse pour préparer la prochaine itération. Celles-ci ne sont pas exigées par Scrum bien que permises. Lors de ces rencontres, on valide en équipe le code ou l’expression du requis pour s’assurer qu’il est de qualité.

Team Pride

People are most successful when they feel good about their project and when they are confident. But there is a chicken and egg problem here: Confidence breeds success, but success creates confidence.

Instill a sense of elitism into the team. Teams that have a certain arrogance tend to work hard and accomplish what is put before them.

Et finalement, une fois que:

  • la confiance s’est installée (Community of Trust),
  • le travail est défini dans une seule liste (Work Queue)
  • l’équipe est en mesure d’organiser son travail (Informal Labor Plan)
  • l’équipe est au cœur du développement (Developer Controls Process)
  • et l’équipe se valide entre elle (Group Validation)

On peut finalement atteindre le dernier modèle d’organisation que nous offre Scrum, c’est-à-dire la fierté d’équipe.

Vous n'êtes pas convaincu. Prenez ce modèle à l'envers?

Est-ce qu'on peut être une équipe fière si:

  • on ne se fait pas confiance? Non.
  • on ne connait pas le travail à faire? Non. L'équipe ne sait pas quoi bâtir.
  • on ne peut pas gérer son propre travail? Discutable mais probablement que non.
  • on n'est pas au centre du développement? Discutable mais plus stimulant si on l'est.
  • on ne se valide pas pour livrer de la qualité? Non. Êtes-vous fier de vous lorsque vous livrer un produit de piètre qualité. 

Pour conclure

Si on revient à notre image des 33 modèles, je la trouve très utile puisqu’elle aide un coach Agile/Scrum Master à faire un diagnostique (état des lieux) de son équipe. En identifiant les modèles actuellement en place dans l’équipe, on peut se positionner dans la carte des modèles et identifier les prochains à mettre en place avec l'équipe.

Lors des formations à propos de Scrum, je souligne souvent le fait que Scrum est extrêmement facile à comprendre mais difficile à maîtriser. Bien que l’image suivante soit souvent mon point de départ pour expliquer Scrum en 2 minutes, on s’aperçoit avec ces 33 modèles organisationnels pourquoi Scrum est ensuite difficile à maîtriser.

Scrum process

Et c'est pour ces raisons, et bien d’autres encore, que Scrum continue à être la méthodologie Agile la plus employée année après année.

Un p.d.g ou un facilitateur en chef?

Publié par Louis-Philippe Carignan le lundi 3 juin 2013 à 15:00

Je suis tombé sur cet article dernièrement sur LaPresse.ca où Jacques Guénette, cofondateur de l’entreprise D.L.G.L, se présente comme « facilitateur en chef ».

Pour Jacques Guénette, cofondateur de l'entreprise (il préfère le terme «facilitateur en chef»), une excellente mobilisation passe avant tout par un environnement agréable. «C'est simple, il faut que les employés aient le goût de venir travailler», affirme-t-il.

D.L.G.L est une firme en technologies de l’information à Blainville, au nord de Montréal. L’organisation comprend 89 personnes et un taux de roulement presque nul.

J’avais écrit dernièrement à propos Crisp.se, une firme de consultants T.I en Suède, qui ne visait pas essentiellement la croissance mais plutôt d’être dans un environnement heureux. Dans l’article de La Presse, Jacques Guénette dit essentiellement la même chose.

L'entrepreneur a ce concept en horreur. «La croissance à outrance n'apporte rien de bon. Et ça ne fera jamais partie de mon vocabulaire. Des objectifs de croissance élevés, ça mine le moral des employés et, par la suite, c'est la santé de l'entreprise qui en prend un coup.»

Il est dommage que l’article à propos de D.L.G.L soit aussi court. J’aimerais bien en apprendre davantage sur ce que fait ce facilitateur en chef pour être l’huile dans l’engrenage de son entreprise.

Mots-Clés :

Archive