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.
À 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.
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.