Collaboration

Collaboration par l'exemple

La collaboration est nécessaire pour résoudre des problèmes complexes. J’ai toujours souffert du manque flagrant de collaboration entre les personnes. C’est professionnellement frustrant quand on a vécu un travail d’équipe efficace.

Pensez à la meilleure équipe dans laquelle vous avez travaillé, quelles étaient ses spécificités ?

Comment un Scrum Master peu aider les personnes, les équipes et les organisations à mieux collaborer ?

J’ai remarqué que si les personnes ont le choix, ils préfèrent ne pas collaborer. A partir de cette observation, je cherche toujours des expédients pour faire devenir la collaboration une nécessité.

La collaboration est une nécessité

Je pense que la collaboration dérive de la compréhension. Pensez à ce que vous êtes en train de faire, pourquoi vous êtes en train de le faire. Vous le faites parce que quelqu’un vous a communiqué une vision, une intention globale concernant le Produit ou le Projet ?

Les suivantes sont deux expériences que j’ai vécues et qu’ont aidé à améliorer la collaboration entre les personnes.

Exemple – Écriture collaborative

Lors d’une mission passée, en tant que Chef de Projet, j’ai eu à fournir un Project Plan. La complexité n’était pas dans le contenu, mais plutôt dans le fait qu’il fallait la collaboration de plusieurs personnes très occupées.

Une pratique commune dans cette organisation était d’envoyer le document par mail et attendre la réponse des différentes personnes contributrices. Comme vous pouvez l’imaginer, après un mois le sujet n’était toujours pas clos.

J’ai décidé d’organiser une session de travail collaboratif. J’ai préparé la salle, les outils de facilitation et j’ai collé au mur différents posters, chacun contenant un chapitre du document à discuter.

Les personnes sont entrées dans la salle de réunion et ont allumé leurs ordinateurs. Ignorant le manque de respect pour moi et mon travail, j’ai réussi à transférer l’attention vers les posters (pratique inconnue pour les participants). Nous avons établi un but et des règles communes pour la session de travail.

Je suis resté en silence, à côté d’un des posters vides. Quelqu’un a commencé à parler.

La magie à fait le reste quand les personnes ont commencé à se parler et ont oublié leurs portables pour se concentrer sur le même poster au mur. Les participants se sont concentrés sur le résultat, pas sur le chapitre à remplir. J’ai été stupéfait par la pensée non linéaire : souvent une discussion commençait à un endroit et finissait à un autre pour enfin revenir au début. Le fait d’avoir des supports physiques était clairement d’aide. Nous avons fait en deux heures ce que nous n’avons pas été capables de faire en un mois, grâce a une collaboration ouverte et à la facilitation. Et on s’est amusés.

Exemple – Collaboration entre Scrum Master

Quelque chose d’un peu plus difficile que de remplir un document… néanmoins les principes sont immuables.

Un Scrum Master n’existe pas uniquement pour servir une équipe Scrum. Éliminer les obstacles, enseigner et promouvoir Scrum est quelque chose qui doit être fait aussi au niveau organisationnel. C’est quelque chose qu’un Scrum Master seul peut difficilement faire dans des grandes organisations.

Quand je rencontre un nouveau Client, je cherche toujours les personnes qui ont envie de challenger le statuquo. Je parle de la magie de la collaboration ; j’offre ma connaissance de Scrum et mon expérience et je demande de l’aide pour comprendre la culture organisationnelle et d’autres aspects pratiques que je ne maitrise pas bien. Nous collaborons et nous apprenons les uns des autres.

Je commence par proposer des activités et je recherche des volontaires pour m’aider, de manière très simple et informelle. La collaboration entre moi et les employés, qui connaissent la culture d’entreprise est très importante.

Dans l’entreprise que j’aide actuellement nous avons créé une communauté ouverte à toutes les personnes ayant envie d’apprendre et expérimenter Scrum. Chaque mois le groupe s’auto-organise, grandit ensemble et fixe ses propres objectifs.

Nous avons créé un espace en ligne pour montrer les évènements passés et le matériel que nous avons conçu. Nous montrons que ce que nous faisons a un impact sur les autres, que nous nous aidons et que, parfois, nous galérons ensemble. Nous célébrons des petits succès ensemble et, devinez quoi ? Nous nous amusons !

Quelque exemple puissant du résultat de cette collaboration :

– la création d’un atelier : « initiation à Scrum ». Le résultat de la collaboration entre les employés formés à Scrum Professionnel et qui l’utilisent et moi-même pour aider au contenu et à la facilitation. Il en résulte un atelier très apprécié : les employés qui pratiquent Scrum sont plus efficaces et crédibles avec leur pairs qu’une personne extérieure.

– Imaginer des nouveaux produits : les employés de différents domaines ont imaginé des produits nouveaux et innovants (en combinant leurs connaissances sans barrières).

Je ressens que les participants ont compris que chacun compte, que tout est possible et que c’est en collaborant que nous pouvons obtenir d’excellents résultats.

Conclusions

La collaboration n’est pas naturelle – en tant que Scrum Master nous devons trouver des manières pour rendre la collaboration une nécessité.

La collaboration dérive de la compréhension – en tant que Scrum Master nous pouvons aider le Product Owner et l’Organisation à clarifier le pourquoi et les résultats attendus d’un Produit et à le partager largement.

Complexité – la pensée non linéaire est une particularité de la complexité. Soyez confortables avec les changements.

Scrum Master Facilitateur – étudier et se préparer pour faciliter les évènements Scrum, les réunions, les sessions de travail afin de stimuler la collaboration

Les Valeurs Scrum – en tant que Scrum Master, s’assurer de créer un espace dans lequel les personnes se sent en sécurité pour s’exprimer et expérimenter. Pour cela, les Valeurs Scrum et des règles de base (définies par les participants) sont une obligation. Oh, et s’assurer que les personnes s’amusent… on peut travailler sérieusement en s’amusant ! La partie difficile est que les personnes doivent oublier d’être dans leur entreprise et qui sont libre de toutes contraintes ! Par expérience je peux affirmer que si un tel environnement est créé, il se répandra dans l’organisation avec d’énormes bénéfices en termes de collaboration.

Références

Voici quelques livres que j’ai lu pour apprendre la facilitation, il y en a beaucoup et, si vous avez des bonnes références en français merci de les partager en commentaire !

Podcast - Etincelles de Scrum

Podcast – Scrum en Entreprise

Un nouveau épisode du podcast « Etincelles de Scrum » est disponible.

Scrum est facile à comprendre, difficile à maitriser.

J’ai enregistré cet épisode il y a quelque mois, chez mon client. Il s’agissait d’une session de sensibilisation à Scrum du management, principalement animée par la Scrum Team que j’aide dans l’application de Scrum.

J’ai trouvé très interessants les échanges, qui seront utiles aux novices comme aux confirmés.

Quelque mot clé que j’ai retenu : collaboration, transparence, complexité, product backlog, utilisateur final, valeur, amélioration continue, budget…

Estimer sa capacité lors du Sprint Planning dans un contexte mouvementé

Planning

Contexte

Votre Sprint s’achève. Votre incrément est terminé, vous avez codé proprement, vos batteries de test unitaires et tests d’intégration sont au vert clair, vous êtes fiers de votre travail. La Sprint Review se déroule sans accrocs. La Sprint Retrospective permet à l’équipe de trouver 1 ou 2 axes d’amélioration sans révolutionner le monde.

Bravo !

Vous enchaînez sur votre Sprint Planning, identifiant un sympathique Sprint Goal comme cible, une dizaine d’item du Product Backlog comme trajectoire et un joli Sprint Backlog pour y arriver.

Pendant ce temps, dans le bâtiment voisin, vos utilisateurs favoris (collaborateurs internes de l’entreprise) vont faire quelques tests fonctionnels, quand leurs obligations professionnelles quotidiennes leur en laissent le temps.

Il se trouve que ces tests fonctionnels leur font trouver des défauts assez graves pour mériter d’être traités « rapidement » plutôt que d’attendre le prochain Sprint. La Product Owner insiste, peut-être un peu lourdement, pour que des correctifs soient apportés dès le Sprint courant, bousculant fortement votre Sprint Backlog voire mettant en péril le sacro-saint Sprint Goal.

Et malheureusement, ce schéma se répète Sprint après Sprint.

Symptômes

Vous observez que les Sprint Planning deviennent très délicats car vous vous rendez-compte que vous avez énormément de difficultés à estimer la capacité réelle de travail de l’équipe de développement. Vos objectifs de Sprint sont également perturbés, bien trop souvent à votre goût.

L’équipe se trouve dans une position très inconfortable où elle n’arrive pas à maîtriser et stabiliser son Sprint Backlog.

Causes

En appliquant les « 5 why », vous comprenez que la première cause que vous identifiez à votre problème est le nombre très variable, mais jamais nul, d’anomalie à corriger en urgence, par suite des tests fonctionnels de vos utilisateurs du bâtiment voisin.

Pourquoi ? Parce qu’ils doivent tester après vous car les tests actuels sont incomplets

Pourquoi ? Parce que l’incrément n’est pas réellement terminé

Pourquoi ? Parce qu’il manque de faire les tests fonctionnels à l’intérieur du Sprint

Pourquoi ? Parce que l’équipe ne sait pas quels sont les tests fonctionnels pertinents à dérouler

Pourquoi ? Parce que la « Définitions Of Done » n’inclue pas le passage des tests fonctionnels, en tant que critères d’acceptation de chaque item, et encore moins leur automatisation et que rien n’est mis en œuvre pour que ces tests soient réalisés par l’équipe de développement pendant le Sprint.

Remèdes possibles

Le cadre Scrum nous aide à prendre conscience des freins de l’organisation, mais il nous laisse trouver l’approche qui convient le mieux à notre contexte pour faire évoluer progressivement l’organisation, tout en ayant le courage de respecter Scrum sans en modifier les règles.

Le premier pas consiste à enrichir la « Definition Of Done ». Celle-ci doit (petit à petit, soyons pragmatiques) amener à un niveau de qualité tel que l’incrément est réellement livrable et utilisable en production par l’utilisateur final, au plus tard à la fin du Sprint.

Maintenant, comment arriver à ce que l’équipe de développement exécute elle-même ces nouveaux tests et arriver au Saint Graal de l’incrément réellement terminé ?

Comme toujours, plusieurs options sont envisageables, en fonction du contexte qui est unique, mais en synthèse, la question revient à trouver un moyen pour que l’équipe de développement soit autonome dans l’exécution des tests.

Une première option est que l’expert métier lui-même soit intégré à l’équipe de développement, puisqu’il a une contribution critique pour obtenir un incrément terminé. Cette option est complètement alignée avec l’esprit du cadre Scrum qui révèle les problèmes issus du fonctionnement en silos, ici entre l’IT et le métier. La présence de l’expertise « métier » dans l’équipe permet de concevoir et exécuter les tests pertinents et juste au bon moment, par l’équipe. Le gain est évident pour l’équipe de développement qui renforce ses compétences, à condition que le nouveau membre de l’équipe accepte les règles du jeu et s’intègre bien dans l’équipe. Mais l’entreprise le paie pour sa compétence à traiter efficacement des « dossiers », pas forcément pour fabriquer un produit et si sa présence dans l’équipe est trop sporadique, il deviendra un goulot d’étranglement douloureux.

Une autre option est de restreindre le travail de l’équipe de développement pendant le Sprint à l’exécution voire l’automatisation des tests, mais pas à leur conception. La conception des tests se fait alors avant le Sprint, lors du raffinage des items du Product Backlog, en présence de l’expert métier et de l’équipe Scrum ou du moins des bons représentants. Lors du Sprint Planning, les items sont ainsi « prêts » à être réalisés et testés par l’équipe de développement qui dispose déjà des scénarios de tests (critères d’acceptation), créés en collaboration avec l’expert.

Il y a encore d’autres options à explorer telles que la montée en compétence (formation, mentoring…) du Product Owner ou de l’équipe de développement si elle en a l’appétence (profil de Business Analysts par exemple), afin de gagner en expertise et donc en autonomie sans perturber l’équipe Scrum par l’ajout de nouvelles personnes.

Vous pouvez penser à diminuer la durée des Sprint afin que les corrections des mêmes tests non passants puissent plus facilement attendre le Sprint suivant au lieu de perturber le Sprint courant qui arrive plus tôt. Mais ce remède symptomatique ne traite pas la cause racine du problème, en ne faisant que tolérer une implémentation de Scrum médiocre laissant s’installer l’habitude d’avoir des incréments « testables » mais toujours « non livrables ». Vous êtes alors voués à rentrer dans une spirale vous incitant à réduire de plus en plus la durée de vos Sprints, jusqu’à arriver à un point où les experts travailleront quotidiennement avec l’équipe de développement.

Conclusion

Le choix de la solution la plus pertinente dépend du contexte que vous seuls maîtrisez. Vous êtes les seuls à savoir ce qui est plus ou moins facilement faisable, ce que vous avez déjà réussi à faire. Alors maintenant, quelles autres options envisagez-vous ?