Agile Tour Microsoft

Nous étions plusieurs astronautes de la galaxie Eleven Labs à nous rendre le 5 décembre dernier à l'Agile Tour organisé par Microsoft dans ses propres locaux.

Nous avons donc pu assister à différentes conférences et plusieurs ateliers autour de l'agilité et de ses différentes applications. Petit résumé des découvertes ci-dessous !

SOMMAIRE

1. COM en entreprise
2. Delegation Board for PO & Agile Teams
3. De développeur à Scrum Master, une transition évidente ?
4. Le scrum est une fenêtre (ou bien un mur)
5. Emotional Assertiveness: the power to access our agile mindset
6. The cost of Fear: how to make brave decisions
7. Boostez vos Backlog Grooming / Refinement avec l’Example Mapping

COM en entreprise

L'enjeu de ce premier atelier animé par Natalia HELIE-SHILOVA était de comprendre l'importance de la communication transversale entre les différents services d'une entreprise. Ce qui peut se transposer dans notre quotidien par la communication entre les différentes équipes de nos projets agiles.

L'atelier consistait en la répartition des participants en cinq groupes, représentant des villes.

Chaque ville avait pour objectif de réunir une équipe de dix personnes composée d'un certain nombre de profils parmi les suivants : boss, SEO, financier, marketing et développeur. Le tout en partant d'une enveloppe contenant aléatoirement dix de ces profils.

La première étape consistait à échanger entre villes par papier des profils dont nous avions besoin et d'autres que nous étions prêts à donner, afin de se mettre d'accord sur un échange.

Mais au bout d'une dizaine de minutes, aucune ville n'avait réussi à réunir les 10 membres définis de son équipe.

La seconde étape, après un feedback de chaque table sur le vécu des échanges, points négatifs principalement, a été de repartir à la recherche des profils manquants.

Cinq minutes plus tard, deux villes sur les cinq avaient réussi à constituer des équipes complètes.

Nos impressions

Maeva : Être constamment dans l’attente d’une confirmation ou ne pas être notifié d'un refus ont été très frustrant. La plupart du temps nous tablions sur le fait que l'autre équipe allait respecter son engagement. Une bonne cohésion inter-équipes fonctionne uniquement si les gens sont de bonne foi. Nous avons pensé à mentir pour obtenir ce que nous souhaitions, mais cela risquait de dégrader la collaboration et potentiellement mettre en péril notre projet : si nous avions de nouveau besoin de l’autre équipe en question, ils auraient refusé de nous aider.

Le parallèle avec l'agile est assez intéressant, puisque tout dans le processus pousse les équipes à communiquer entre elles et à être transparents.

Jérémy : Très intéressante entrée en matière, cet atelier nous a permis d’expérimenter les affres de la communication inter-équipes. Si cela ressemblait beaucoup à un jeu presque gagné d’avance à l’issu de la première itération de dix minutes, la seconde itération à été beaucoup plus stressante (et frustrante) : impossible de récupérer la dernière carte manquante à notre équipe.

La mise en lumière par cet atelier des difficultés de communication entre les équipes était évidente, entre absence de réponse et absence de confirmation, impossible d’avancer.

Delegation Board for PO & Agile Teams

Introduction au "Management 3.0" par Rafik MEKKI, avec sa mise en pratique du "Delegation Board".

L'idée du Delegation Board est d'inscrire sur un tableau les grandes actions de son projet agile. Cela peut être la rédaction d'une US, la priorisation des US, le challenge client, le choix des participants aux rétrospectives, etc.

Les 7 niveaux définis par le Delegation Board sont les suivants :

1. Dire : prendre la décision et le dire à l'équipe
2. Vendre : convaincre les gens sur la décision à prendre
3. Consulter : consulter l'équipe avant de prendre la décision
4. S'entendre : prendre des décisions avec l'équipe
5. Conseiller : influencer mais la décision est prise par l'équipe
6. Enquêter : demander des retours suite à la décision de l'équipe
7. Déléguer : aucune influence, délégation à toute l'équipe

L'idée pendant cet atelier a donc été d'effectuer un "Delegation poker" avec son équipe afin de définir, pour chaque membre, les niveaux de délégations souhaités. À main levée, tout le monde a donc voté pour les 5 tâches définies. Par ailleurs, des cartes dédiées existent pour effectuer le chiffrage du Delegation Board.

Nos impressions :

Maeva : La mise en place d'une Delegation Board au lancement d'un projet est une idée très intéressante. Elle permet de donner une voix égale à tout le monde et d'engager l'équipe complète dans le choix des différents niveaux de délégation alloués aux tâches. Ce qui responsabilise chacun à son niveau sur ses propres actions et facilite la légitimité dans les prises de décision par la suite d'un acteur.

Je pense aussi que cette technique peut permettre à un projet de sortir la tête de l'eau si celui-ci arrive à un moment critique où plus personne n'est d'accord sur les prochains jalons à poser.

Jérémy : Atelier très intéressant à la fois dans son intérêt et dans sa simplicité. Définir précisément les rôles de chacun n’est pas forcément facile, le faire dans des conditions permettant l’échange et le débat encore moins.

Grâce au Delegation Board cependant, il est facile de se concerter pour poser exactement quelles doivent être les responsabilités de chacun et ainsi éviter les verrouillages classique que l’on retrouve régulièrement dans une équipe.

De développeur à Scrum Master, une transition évidente ?

Cette conférence présentée par Caroline AUPERT était un REX sur la transition du métier de développeur à celui de Scrum Master. Centré d’abord sur la transition, Caroline à pu nous expliquer à travers son expérience, que cela n’a pas toujours été facile.

Les différences avec le métier de développeur sont nombreuses et apportent beaucoup d'interrogations : comment savoir à court terme que l’on remplit bien son rôle ? Comment expliquer aux autres développeurs de l’équipe qu’un Scrum Master peut les aider autrement qu’en les aidant à coder ? Enfin, et c’est sûrement la question qui à trouvé le plus d’écho dans la salle, que faire de ses journées quand il n’y a pas de meeting Scrum ?

Les réponses à ces question peuvent sembler évidentes pour ceux qui auraient le recul de l'expérience, elles le sont beaucoup moins pour un Scrum Master junior.

Outre les différences évidentes avec son métier, Caroline nous a exposé les difficultés qu’elle a pu rencontrer. Les petites phrases bien senties de certains collègues, les passages à vide à se demander quoi faire et comment se former pour s'améliorer à pratiquer le Scrum Mastering.

Au final, ce fut un REX très intéressant, de nombreux développeurs dans la salle se sont identifiés aux expériences partagées.

Nos impressions :

Jérémy : En temps que développeur et Scrum Master, cette conférence m’a beaucoup parlé. Le retour d’expérience concernant la transition entre Scrum Master à mi-temps et Scrum Master à plein temps était notamment très intéressant, répondant à des questions que je me posais depuis quelque temps.

Les difficultés que Caroline a exposées étaient elles aussi éclairantes sur ce que peut traverser un futur Scrum Master. Pas d'obstacle infranchissable certes, malgré certaines choses particulièrement troublantes. Par exemple les propos de certains de ses collègues, mélangeant moqueries et misogynie, à l’encontre de quelqu’un qui a pourtant changé de coeur de métier pour une fonction qui n’est là que pour les aider...

Renaud : Je suis développeur de formation et j’ai un bon moment aspiré à devenir scrum master, je n’y ai d’ailleurs pas renoncé. C'était la présentation la plus attendue pour moi. Ce qui m’a le plus marqué dans cette présentation, hormis son parcours, était justement la fameuse question : "On fait quoi quand on n’a pas de meeting ?".

C’est exactement ce qui m’a toujours bloqué, je me suis toujours dit "tu vas te tourner les pouces et en plus tu vas devoir faire croire à tes collègues que tu travailles".

Mais en fait le rôle de scrum master ne se réduit pas juste à régler des situations bloquantes ou à organiser les différentes réunions. C’est aussi d'aller à la rencontre des différents services, discuter avec eux pour être bien immergé dans le contexte de l'entreprise, penser à l'amélioration du déroulement d’un projet, etc.

En bref, elle a évoqué beaucoup de choses auxquelles je n'avais jamais pensé et qui m’ont conforté dans l’idée que "Mais Scrum Master, c’est définitivement un vrai métier !". Et plutôt tentant en plus !

Le scrum est une fenêtre (ou bien un mur)

Baptiste LeCOCQ nous a présenté dans cette conférence un retour d'expérience sur la mise en œuvre du Scrum dans son équipe de développement.

Il a pu nous expliquer que dans un premier temps, leur implémentation "à la lettre" de la célèbre méthode Scrum a certes apporté son lot d'avantages, mais aussi avec quelques inconvénients au passage. Augmentation de la dette technique, évolutions trop complexes à mettre en place… Le temps de la remise en question vient donc au bout d'un an et une solution semble se dessiner : le Scrum en feature-team. Malheureusement, la sub-division en plus petite équipe n'a visiblement pas résolu leurs différentes problématiques. Ils se lancent alors dans la conception de “LEUR organisation”.

Groupe de pair-programming, communication entre les développeurs et avec le client en continu. Bref, un manifesto des plus simples qui semble bien loin de la rigidité du Scrum… en apparence. Effectivement, en conclusion de sa présentation, Baptiste nous montre qu'en effet, chaque élément important de leur nouvelle organisation se rapproche des pierres angulaires du Scrum. Ainsi, sous des formes légèrement différentes, son équipe pratiquait le Daily meeting et autres rétrospectives de fin de sprint.

Nos impressions :

Jérémy : Une présentation des plus éclairantes sur la mise en place by the book du Scrum, qui pose en définitive plus de problèmes qu'elle n'apporte de solutions.

On pourra aussi noter le ton caustique et plein de suspense de la conférence, qui nous accroche jusqu'au bout, ne laissant deviner que tardivement le “happy-ending”.

Emotional Assertiveness : the power to access our agile mindset

L'idée de cette conférence donnée par Amy WHICKER, est que chaque fois que nous avons une émotion, qu'on pourrait qualifier de bonne ou de mauvaise, c'est un opportunité d'en tirer quelque chose.

Si on fait le parallèle, le principe même de l'agilité est d'apprendre de nos actions, bonnes comme mauvaises. Pourquoi, de ce fait, en plus de se donner le choix d'apprendre chacun des uns et des autres, ne pas se donner le pouvoir d'apprendre des émotions de chacun dans l'équipe ?

D'autant plus qu'engager les autres dans la résolution d'un problème existant donne un respect et une appartenance à toutes les personnes concernées.

Petit fun fact en chiffres, il apparait qu'aujourd’hui en France, 69% des salariés ne se sentent pas concernés par leur travail. Rien que ça...

Par groupe de 2-3 personnes nous avons échangé autour des émotions ressenties à la suite d’une réunion où la collaboration s’est mal passée, puis sur une récente situation professionnelle qui a déclenché chez nous une émotion inconfortable. Que peut-on apprendre de cette émotion et comment la transformer pour la rendre plus confortable et surtout, constructive ?

Nos impressions

Maeva : J’ai beau avoir eu un intérêt certain pour le sujet de la conférence, je l’ai trouvé relativement éloigné du principe de l’agilité.

Il était tout de même rassurant de se dire qu’être frustrée ou énervée par une situation au travail est le lot commun des mortels. Cependant au lieu de se laisser guider par l’émotion, il est essentiel de savoir recentrer ce sentiment sur le projet et non soi-même, afin d'en discuter et le transformer en action positive. Un peu comme le fonctionnement de l’agile sur le partage et la transparence.

The cost of Fear : how to make brave decisions

Oana JUNCU, speaker de cette conférence, est arrivée masquée au micro.

Elle a introduit son sujet en énonçant un principe commun à tout un chacun : nos peurs inconscientes deviennent des filtres que nous nous imposons pour se protéger et ne plus être “nous-même”.

Les émotions ont la priorité sur l’intelligence de par notre physiologie. En effet, le cerveau limbique, centre de nos émotions, a la priorité sur notre néocortex qui va être lui le centre du raisonnement et de la compréhension.

Dans nos projets, c’est un peu la même chose : nous utilisons régulièrement inconsciemment des masques et filtres dans nos communications (“il faut”, “on doit”, …) pour se protéger ou se déresponsabiliser.

À cause de cette peur instaurée, nous n’allons pas prendre de risques, ou alors être sûrs de contrôler ces derniers avant de se lancer. Ce qui empêche créativité ou innovation de s’exprimer.

L’idée est donc de concilier compréhension de la peur du risque, et but commun entre les différentes équipes, afin de pouvoir arriver à l'enchainement suivant :

• Identifier le risque business ;
• Lister cinq raisons pour lesquelles ce risque nous fait peur ;
• Trouver des idées pour répondre à ces peurs ;
• Cerner les bénéfices espérés si nous suivons cette idée.

Nos impressions :

Maeva : Malgré la redondance entre la théorie et la mise en pratique qui n’avait pas de valeur ajoutée à mon sens lors de cet atelier, il était intéressant de mettre en lumière le coût que peut avoir la peur de prendre des risques dans un projet à cause d'un potentiel échec. On le voit d’ailleurs tous les jours dans les entreprises qui nous entourent : rester dans sa zone de confort au lieu d’innover porte plus préjudice sur le long terme que ça n'apporte de bénéfices.

Jérémy : Beaucoup d’originalité dans cet atelier, traitant d’un sujet qui nous impacte tous les jours : la peur et ses conséquences. La gestion du risque et la peur que ce dernier entraîne est bien souvent source de blocage au sein d’un projet, il était très intéressant de pouvoir travailler sur les racines de nos réactions primaires, pourtant bien naturelles, et ainsi viser à les contrôler.

Boostez vos Backlog Grooming / Refinement avec l’Example Mapping

Jean-Pierre LAMBERT est intervenu à l’Agile Tour pour nous présenter l’Example Mapping et surtout nous le faire mettre en pratique avec des cas concrets qu’il avait préparé.

Le principe de l’Example Mapping, qui arrive en amont de la validation et de l’estimation des user stories, est de structurer avec une méthodologie bien définie la réflexion permettant d’aboutir à une clarification et validation des critères d’acceptance.

Nous nous sommes donc retrouvés avec quatre bloc-notes de couleurs différentes :

• Un pour définir la story à décortiquer
• Un pour définir les règles et contraintes liées à cette US
• Un pour représenter les exemples qui sont associés à ces critères d’acceptance, afin de matérialiser plus concrètements pour chacun ces règles
• Un pour les questions qui ont été posées mais qui n’ont pas pu avoir de réponses de la part de l’équipe

Nous sommes ensuite partis d’une US donnée dans un contexte, pour en définir ce que nous estimions être la ou les règles, puis les différents exemples pour chaque règle.

Cette technique permet de mettre en lumière quand une US soulève beaucoup de questions sans réponses, et donc qu'elle n’est potentiellement pas prête à être embarquée.

Elle permet également de se rendre compte qua'une US est trop complexe et pourrait être découpée en plusieurs stories, car elle embarque trop de règles et de contraintes à la fois.

Les différents exemples associés aux règles permettent quant à eux de mieux visualiser les différents cas à envisager. Mais aussi parfois de réaliser qu’une contrainte supplémentaire n’avait pas été envisagée jusqu’à maintenant.

Nos impressions :

Maeva : Nous étions beaucoup trop à participer à cet atelier, ce qui de mon point de vue a gâché l’expérience et ne m’a pas permis à ce moment là d’apprécier la méthodologie proposée et de la comprendre clairement.

Cependant le principe de l’example mapping est intéressant. On a tendance à prendre des raccourcis quand on a la tête dans les sprints qui défilent, et à faire le backlog refinement au même moment que le planning poker par exemple. Ce qui en fait un point de rendez-vous souvent à rallonge et plus pénible que pratique.

D'un autre côté quand on prend un temps dédié à une réunion de backlog refinement ou grooming, sans méthodologie particulière, cela ne permet pas toujours de couvrir le scope entier des US les plus complexes, traitées au même titre que les autres stories.

Il ne me semble pas intéressant de se servir de l'Example Mapping pour tout un sprint backlog, cela serait beaucoup trop fastidieux car relativement long à dérouler, pour peu de ROI. Mais il reste une excellente méthodologie au cas par cas pour les users stories les plus ambigües.

Conclusion

Voilà pour nos retours sur les conférences auxquelles nous avons pu assister, merci de nous avoir lus ! On espère que ça vous aura apporté autant qu'à nous :)