Coopération, la 5e partie de Scrum 6
Une partie qui contient 5 chapitres, chacun décrivant une forme de coopération adaptée au contexte.
Mon livre présente Scrum comme un outil convivial pour une agilité radicale. Les 4 premières parties portent sur les fondamentaux de l’agilité (l’équipe et les boucles), sur comment démarrer (le prélude) puis sur comment se déroulent les rites, emblématiques de Scrum. La coopération est enclenchée, puis instituée, avec toute l’équipe. Cependant les rites ne représentent qu’une petite partie du temps des coéquipiers.
La coopération se poursuit entre les rites.
J’avais d’abord envisagé de nommer cette dernière partie Scrum, et après ? Puis en travaillant sur le sujet mob programming avec Anthony, la lumière m’est apparue. Cette dernière partie allait s’appeler Les coopérations, puis finalement La coopération sur les conseils de mon éditeur.
Il ne faudrait pas croire qu’une fois un rite fini, chacun va travailler dans son coin et ne se revoit qu’au suivant. D’ailleurs, la mêlée est l’occasion de prévoir les moments de coopération de la journée. Une équipe qui s’en tient uniquement au respect des rites ne devient pas agile pour autant. La valeur du résultat n’est pas acquise parce qu’on aura fait des mêlées quotidiennes.
Pour arriver à donner un résultat, les coéquipiers ont besoin de compétences et de capacités autres que celles utiles pour les rites.
Faire seulement les rites mène au faux-agile et à ses déconvenues.
Quelles compétences acquérir et quelles capacités développer ?
Dans un domaine aussi foisonnant que l’agilité, le choix est vaste. On s’en rend compte en assistant aux nombreuses conférences agiles, qui ont continué en ligne pendant le confinement, et repris depuis, souvent avec des intentions d’ouverture plus grande. Elles drainent toujours un public important. Les sujets présentés évoluent au fil des années.
La liste que je présente ci-dessous – totalement subjective – donne une idée des sujets qui m’ont marqué ces vingt dernières années.
Comment choisir ?
Ces sujets représentent potentiellement des capacités à acquérir par les coéquipiers. Même si on devine qu’un Product Owner sera intéressé par l’axe produit et un Scrum Master par l’axe facilitation, la difficulté est de choisir.
Cela commence par la connaissance de son contexte.
J’ai beaucoup écrit sur la notion de contexte d’un projet. Dans des éditions précédentes, cela constituait un chapitre entier. Dans Scrum édition 6, pour cette partie 5, je réduis à quelques questions les attributs permettant de qualifier le contexte.
- L’équipe développe du logiciel ?
- Le besoin de prévision est fort ?
- Le travail est souvent interrompu par des urgences ?
- Le projet est de grande taille ?
- Souhaitons-nous —vraiment— pérenniser et renforcer l’agilité ?
Les réponses à ces questions aident à trouver son chemin dans l’éventail de ce qu’offre l’agilité.
Chapitres de la partie 5
Une réponse à oui à une question renvoie à un chapitre.
Coopérer pour donner un résultat de qualité
Il est simple de répondre à la cette question. Si l’équipe développe du logiciel, alors elle DOIT acquérir des capacités en ingénierie du logiciel. C’est l’objet du premier chapitre de cette partie, coopérer pour donner un résultat de qualité.
Coopérer pour prévoir
Pour répondre à la question sur le besoin de prévision, il est utile de revenir sur la classification présentée dans le chapitre sur les parties prenantes. Dans le cas de sous-traitance, il est fort probable que les organisations demandent des prévisions sur les engagements. Dans le cas d’un éditeur B2C qui met en service plusieurs fois par an, il est aussi probable d’avoir des demandes de prévision sur le contenu de ces versions.
La planification de saison permet de répondre à ce besoin en donnant un horizon plus lointain que le sprint. C’est l’objet du deuxième chapitre de cette partie 5.
Coopérer pour plus de fluidité
Les équipes qui sont dans un contexte où les changements sont fréquents le savent bien. Elles sont fréquemment interrompues par des urgences, qui sont dans la culture de l’entreprise. Nous avons présenté plusieurs pistes pour garder de la fluidité dans le travail de l’équipe. Dans certains cas, il faut aller plus loin dans le flux. C’est l’objet du troisième chapitre qui montre l’ajout de limites Kanban à Scrum.
Coopérer à plusieurs équipes
Même si c’est mieux de commencer à petite échelle, il y a parfois des projets de grande taille qui nécessitent de la coopération entre plusieurs équipes. C’est l’objet du quatrième chapitre de traiter le sujet de l’agilité à grande échelle.
Coopérer pour améliorer les capacités de l’équipe
Et enfin, il y a la question sur la stratégie. Que veut-on faire avec l’agilité, jusqu’où aller ?
L’idée clé est de développer les capacités de l’équipe en fonction d’un objectif. L’objectif peut être appliqué sur le modèle Agile Fluency.
C’est à chaque équipe de trouver son chemin en coopérant pour définir les capacités à améliorer. Le cinquième chapitre présente une stratégie et un outil pour développer les capacités de l’équipe.
Est-ce que ce chemin mène à un endroit qui s’appelle encore Scrum ? Peu importe.
Si on se réfère au résultat donné aux utilisateurs, ces coopérations poussent à :
- donner bien avec les pratiques d’ingénierie (chapitre 1) ;
- décider quand donner avec la planification de saison (chapitre 2) ;
- donner sans à-coups avec Kanban appliqué sur Scrum (chapitre 3) ;
- donner à plus avec Scrum à plusieurs équipes (chapitre 4);
- réfléchir et s’améliorer avec le développement des capacités (chapitre 5).
Cette partie 5, dont vous avez ici l’introduction, lisez-la et donnez-moi votre feedback.