feeback scrumday2015

FEEDBACK

09/04/2015

SCRUMday 2015 – mon retour d’expérience

2

19/0

5/20

15

Jour 1 o KEYNOTE « Simple, but not simplistic » o Le plus petit pas, comment accélérer votre transformation agile en

passant de 1000 à 1 o Mangement et agilité o DevOps Mindstorm o Rallye Test Game

Jour 2 o KEYNOTE « The scaling Dilemma » o OPEN SPACE

o Remonter des indicateurs / donner de la visibilité à mon manager

o Transformation agile d’une entreprise en une semaine o Piloter une équipe agile transverse


3

19/0

5/20

15

FEEDBACK – SCRUMDAY 2015

Orateur : Dave SNOWDEN, est un universitaire Gallois, chercheur et consultant dont les travaux s’articulent autour de la théorie de la complexité, des modèles cognitifs permettant d’organiser et construire un savoir à partir d’expériences réalisées et vécues.


4

19/0

5/20

15

Travaux : Ses travaux autour du SENSEMAKING, procédé par lequel, nous donnons du sens à l’expérience, est implémenté à travers le modèle Cynefin pour lequel, il a effectué un exposé lors de cette Keynote d’ouverture du SCRUMDAY 2015

Propos : Le modèle Cynefin est la seule approche qui valide pour découvrir nos environnements et orienter les choix car il repose sur une base scientifique. Nos choix sont « logiques », « rationnels » et « intentionnés »; De plus, ce modèle décrit les différents types d’environnements « simple », « complexe », « compliqué », « chaotique », « désordonné ». Suivant le type d’environnements, il y a une corrélation entre causes et effets plus ou moins forte et qui seront ou non reproductibles pour amener soit une prise de conscience, une réorientation des objectifs fixés, une évolution vers un type d’environnement (plus ou moins complexe) en fonction de « nouveaux objectifs » à atteindre.

Feedback : Il n'y a pas de modèle parfait applicable à tout type d'environnement et l'Agilité à grande échelle n'est pas possible parce que cela nécessite une approche globale quand des systèmes ayant fait leur preuve existent. Il est donc relativement « simple » de naviguer d’un modèle à l’autre pour s’adapter, amener du changement ou répondre à des demandes ou besoins particuliers, mais cela n’est pas « simpliste » dans le sens où ces choix restent quand même orientés et régis par l’environnement dans lequel nous sommes et donc soumis à ses contraintes propres.


Contexte : Agiliser une grande organisation reste un chantier colossal avec une conduite du changement à mener.


5

19/0

5/20

15

Problématique : Trouver la meilleure "vélocité" pour impulser ce changement reste la clé de la réussite, parce que trop rapide donnera un sentiment de frustration ou de passage en force, et trop lentement ne donnera pas la visibilité nécessaire à la "survie" du projet.

Réponses : Définir les objectifs à atteindre et les délais pour y arriver. Eviter d'appliquer sans concertation et sans associer les différents acteurs toute méthodologie aussi bonne et populaire soit-elle. Il faut découper en étapes l'ensemble du processus, fonctionner par itération et à chacune des étapes, il faut récolter le feedback, mesurer l'impact du changement et adapter la méthode.

Feedback : Idéal pour embrayer une transformation agile de manière et méthodique et itérative. En partant du principe de la dichotomie, on peut observer le résultat escompté, évaluer les efforts à produire, puis "réduire" de moitié l'objectif à atteindre, dans un délai plus court et adapter les "nouveaux" efforts. Le but de ceci est de dégrossir l'objectif (de manière dichotomique), de minimiser les efforts associés, afin de rentrer dans un processus itératif plus simple à mettre en œuvre. On arrive ainsi à transformer une organiser de 1000 à fonctionner comme 1 seul individu

1 - Pour parcourir la distance totale, il faut d’abord en parcourir la moitié 2 – Pour parcourir la moitié de la distance, il faut en parcourir le quart 3 – Pour parcourir le quart de la distance, il faut en parcourir le huitièm 4 - … La distance représente l’agilisation de l’organisation et le Découpage en demi, quart, huitième,… correspond aux étapes


Contexte : Une entreprise dans le secteur de l’évènementiel qui dispose d’une plateforme de communication grand public et qui se rémunère sur les publicités que passent les annonceurs sur sa plateforme en retour de la visibilité qu’elle leur offre, fait le choix de "supprimer" la couche "manager" sur la vie / gestion de son équipe technique


6

19/0

5/20

15

Problématique: Le produit / la plateforme est développée et maintenue en interne par une équipe de développement pluridisciplinaire. Elle a en charge les nouveaux développements, la maintenance, le support, la R&D, un rôle consultatif sur le recrutement de nouvelles ressources de développements,… Des réussites ont été obtenues avec la mise en place de l’agilité, mais ils ont rapidement été confronté à la baisse de la productivité, baisse de la motivation de l’équipe,…

Réponses : Provoquer une remise en question de l’équipe, identifier les causes de la baisse de motivation (personnelles, professionnelles,…), identifier les points de blocage qui peuvent inhiber l’action de l’équipe, remettre l’équipe au centre de la problématique produit, Investir plus sur l’équipe

Feedback: Retour d’expérience intéressant d’une équipe agile sur le moyen terme. Bonne remise en cause de certaines pratiques managériales, mise en place d’outils de management répondant aux problématiques de l’équipe. La mise en œuvre de l’agilité reste vrai au niveau équipe de développement avec une proximité avec le directeur technique sur site mais l’équipe dirigeante reste « présente », sur un site distant

1 - Regarde maman, j’y arrive tout seul!

2 - Oui c’est bien Lucas, mais attention, il y a une bosse

devant toi… Reste concentré sur la route

3 - Bien mon garçon!! Ecoute ta mère: Elle donne de

bons conseils.

Le management dans l’agilité est assimilable à des parents qui s’assurent que leur progéniture est suffisamment encadrée pour faire du vélo sans grand danger. Une plus grand liberté est accordée,…dans les limites du cadre Défini entre management et collaborateurs.


Contexte : Atelier de présentation / découverte de la problématique DevOps. Sur tous les projets informatiques, il y a d’une part les développeurs responsables de la mise en œuvre du besoin client et les opérationnels sur lesquels reposent l’exploitation et la mise en production de l’application développée. Il n’est pas rare que ces 2 parties ne soient pas alignées le jour J parce qu’elles vont avoir des préoccupations différentes lors du déroulement du projet.

Développement

Qualité logicielle

DevOps

Opérations


7

19/0

5/20

15

Problématique: Sensibiliser sur ce qu’est le DevOps. Mettre en œuvre un cas pratique pour faire apparaitre les risques d’un cloisonnement entre développeurs et opérationnels, identifier les clés de la réussite d’un projet bien mené.

Réponses : Communiquer en amont sur les contours et les grandes options du développement mis en place, Créer une communauté DevOps au sein des projets, Avoir une équipe pluridisciplinaire intégrant à la fois des développeurs et des opérationnels partageant les mêmes problématiques liées à la vie du projet au quotidien

Feedback: Atelier ludique sur la construction d’un robot avec des légots par les opérationnels et développement du logiciel permettant de piloter le robot par les développeurs. Rapide prise de conscience sur la nécessité d’un échange avec Devs et Ops pour déterminer comment par exemple le robot prend l’information sur son environnement lors d'un déplacement: Capteur infrarouge? Distance parcourue?...

Le DevOps revient à tirer le meilleur parti de la triptyque « Développement », « Qualité logicielle » et « Opérations »

(comprendre exploitation) pour répondre au mieux à la problématique projet, donc assurer une satisfaction client

mais sans négliger les contraintes équipes (développement, qualité, opérationnel)


Contexte : L’agile à l’échelle d’une équipe qui produit un livrable tester unitairement et en intégration est courant. En général, à la sortie d’un sprint ou d’une version, on retombe sur des principes classiques du cycle en V : des semaines de qualification et de recette. Plus tard arrive cette phase et plus tard, les anomalies sont remontées alors que l’on se rapproche de la date de mise en production.

Sprint

Démonstration

RTG Anomalies liées au

RTG / retours démos

Analyses / Corrections


8

19/0

5/20

15

Problématique: Comment paralléliser les tests de qualification et de recette avec les sprints de développements (dans le cas de SCRUM) ou à la livraison d’une fonctionnalité si nous somme sur du flux continu (avec du Lean / KANBAN)?

Réponses : RTG permet d’identifier au plus tôt les tests à réaliser, d’élargir la base de testeurs (tous les types d’utilisateurs possibles du produit), déterminer le périmètre à tester (livret de tests). La phase de test prend l’allure d’un rallye à travers lequel, toute l’équipe de tests (développeurs, PO, client, contributeurs,…) va réaliser tous les cas de tests possibles. La présence des développeurs permet d’avoir un regard sur l’expérience utilisateur, mais également de donner des indications si des difficultés sont rencontrées.

Feedback: Un atelier en binôme intégré dans une équipe de 12 personnes avec un rôle précis pour chaque binôme. L’ensemble forme un système devant répondre à une problématique précise : 0 anomalies bloquantes. RTG est pour moi un moyen immédiat de répondre à une problématique projet des cas de tests non couverts par les longues semaines de qualification et de recette

Le Rallye Test Game permet de paralléliser les tests (anciennement de qualification et de recette) avec les sprints

réalisés. L’objectif étant de remonter très vite tout dysfonctionnement pour anticiper sa correction.

Avec une population la plus représentative possible des utilisateurs, tous les cas de tests existant sont plus

susceptibles d’être couverts


9

19/0

5/20

15


Orateur : Mary (avec TOM) POPENDIECK sont deux Agilistes ayant amené le Lean vers le monde de l’IT. Après une carrière dans l’IT (développeur, manager puis directeur produit), M. POPENDIECK s’est consacré à ses travaux qui s’articulent autour de l’Agilité pour les entreprises dans le domaine de l’IT, inspiré

par le Lean et traitant de la problématique de la scalabilité de l’Agile.


10

19/0

5/20

15

Travaux : Appliquer / décliner le Lean (né en 1972 chez TOYOTA après 25 ans de mise au point), au monde de l'IT. Le principe fondateur de Lean est de livrer des produits de qualité en juste-a-temps et avec zéro gaspillage. La déclinaison est le « Lean Development Software » pour lequel elle a écrit un livre en 2003.

Propos : Si l’Agile est bien pour les projets, l’Agile à l’échelle est forcément bien. Les entreprises sont organisées en silo et savent résoudre des problèmes propre à chaque silo. Par contre, si un problème est transverse, cela devient plus complexe à gérer. Le parallèle donc entre les Feature Team et les Component Team et leur capacité à résoudre différentes problématiques associées à une fonctionnalité (Feature) ou un composant (component) est donc établi. Faire de l’Agile à l’échelle reste lié à la qualité / composition des équipes, de l’entreprise, de ses objectifs, et des moyens donnés pour les atteindre.

Feedback Pour être plus complet, M. POPENDIECK propose de s’inspirer du modèle militaire pour la composition des équipes projet. Une compagnie est composée de pelotons, eux mêmes composées d’équipes. Chaque sous ensemble a des objectifs et un rôle bien défini. L’ensemble reste cohérent et fonctionnel par rapport à la mission confiée à la compagnie. Apporter l’agilité à l’échelle dans une entreprise se fait au final :

En comprenant l’effet souhaité par l’action de l’entreprise

En mesurant (en continue) quand est ce que cela peut être atteint

En apportant des orientations agiles progressivement


Définition : Méthode pour structurer des conversations et conférences; Fédérer des groupes de personnes (pouvant aller jusqu’à plus de 2000) à échanger sur des sujets importants / complexes,…

Objectif : Traiter un maximum de sujets en un temps record

Règles : Si à un moment donné vous vous rendez compte que vous n’êtes ni entrain d’apprendre, ni de transmettre une idée, cela veut dire que le moment est venu de partir à la recherche d’un autre sujet

4 principes Les personnes qui se présentent sont les bonnes Ce qui arrive est la seule chose qui pouvait arriver Ça commence quand ça commence quand c’est fini c’est fini.

Feedback J’ai participé à 2 séances

Projet agile : Fournir des indicateurs / donner de la visibilité à mon manager Transformation Agile en une semaine

J'ai proposé une thématique sur "Comment gérer l'activité d'une équipe qui doit alimenter les autres dans un SCRUM à grande échelle ?"


11

19/0

5/20

15


» Problématique : Sujet proposé par un participant présentant un contexte projet où une migration technique d’une brique de recherche doit être faite. Il y a une dimension « découverte », « montée en compétence » de l’équipe qui fait que l’engagement sur le délai et le périmètre est susceptible de bouger. Comment gérer cela en mode agile et remonter des indicateurs au plus tôt

» Assistance : Divers autres participants ayant rencontrés ce type de problématique ou disposant d’un feedback utile sur le sujet

» Feedback : Il est nécessaire dès le début d’avoir une équipe la plus en accord possible avec la dimension technologique du projet. Fonctionnant en Kanban avec un flux continu de fonctionnalités / Features entrant dans le pipe et ne pouvant être livré que quand elles ont passé le test final, il faut: ˃ Une période « probatoire » pendant laquelle l’équipe va

pouvoir s’étalonner par rapport à échantillon (lot) représentatif du projet global


12

19/0

5/20

15

o Mesure la vélocité de l’équipe / production de l’équipe sur une période

o Remonter les indicateurs qui sont la référence sur laquelle on pourra comparer avec les futures itérations

Par « itération », comprendre uniquement le cycle de production de reporting au management. Vu qu’avec du Kanban, la production de l’équipe est en continue, il reste possible sur demande ou à rythme régulier de produire les indicateurs sur l’avancement, la qualité, la vie de l’équipe,…

Cette dernière tache sera celle du SCRUM Master avec le burndown (gestion du RAF), le burnup (charge produite Vs charge globale et date d’atterissage des fonctionnalités), l’avancement, l’actualité et la vie de l’équipe,…


» Problématique: Dans une entreprise dépourvue de toute pratique agile, comment apporter un changement agile et en voir le résultat au

bout d’une semaine

» Assistance: Gros score de participation parce que le coté feedback rapide que proposait le sujet était très (trop) captivant

» Feedback: Agir sur un changement aussi radical dans un délai limité (1 semaine) ne peut se faire qu’en imposant un ensemble de pratiques

empruntées à l’agilité. Sur les collaborateurs en place, on laisse un choix ˃ S’adapter et se mettre en accord avec les nouveaux objectifs ˃ Quitter le navire

Se posera très rapidement les problématiques RH / contrats / fiches de postes / rôles / Management / évaluation des collaborateurs… On peut légitimement se dire que la dernière étape de l’agilité serait finalement de produire des contrats / fiches de poste / évaluation / rôle / management agiles, c’est-à-dire qui pourrait s'adapter au rythme des changements agiles, mais cela n’est viable que pour certains aspects cités (rôle, management, évaluation entre autres). Cependant, le coté contractuel et juridique posera un problème dans tous les cas. Finalement, on retiendra de cet échange que:

˃ Quand on impose un changement, les conséquences négatives reviennent très vite et sont néfastes au changement initialement voulu. Il y a même une régression par rapport à l'état initial

˃ L’agilité et la transition vers l’agilité doit s’accompagner de la prise en compte des problématiques des équipes en place qui le pratiqueront

˃ Il n’y a pas UNE AGILITE mais 50 NUANCES*

* Il y a eu une présentation dont le thème était « 50 nuances d’agilité ». Vidéo disponible bientôt sur infoq.com


13

19/0

5/20

15


» Problématique: Dans un écosystème où une équipe gère l’éditorial des sites, elle peut être amené suivant les cas à: ˃ Produire un site uniquement éditorial (en standalone) ˃ Produire un site en collaboration avec une équipe

responsable d’une couche service (application métier) ˃ Mettre à disposition de toute application métier (de

services) des modèles / fragments de pages pour gérer l’éditorial en provenance d’un CMS

» Assistance: Différents participants ayant cette problématique

d’agilité à l’échelle avec une équipe transverse qui peut selon les cas peut avoir un en effet entonnoir sur toute la production d’une version, étaient présents


14

19/0

5/20

15

Feedback

o Proposer une organisation en Component team Vs Feature team avec un Product Backlog commun et une instance de priorisation unique.

• Un seul flux de production,

• Un Product Backlog plus volumineux à gérer avec de grandes problématiques d’ordonnancement

o Faire deux (ou plusieurs) équipes pluridisciplinaires permettant de traiter l’exhaustivité des demandes sans dépendances externes

• Autant de Product Backlog et d’instances de priorisation qu’il y a d’équipes

• Créer des communautés pour fédérer et organiser les bonnes pratiques par domaine (Edito community, Gfx community, Architect community, Ops community,…)

Dans tous les cas, les conclusions apportées par cet échange rejoignent les problématiques traitées lors des KEYNOTE d’ouverture par Dave SNOWDEN et de fermeture du SCRUM Day par Mary POPENDIECK


» SCRUMDAY 2015 les 2 et 3 AVRIL à PARIS (DISNEYLAND) » DAVE SNOWDEN

˃ Framework Cynefin : http://cognitive-edge.com ˃ http://en.wikipedia.org/wiki/Dave_Snowden

» MARY POPENDIECK : ˃ http://www.poppendieck.com/ ˃ http://yowconference.com.au/slides/yow2014/Poppendieck-

ScalingDilemma.pdf

» INFOQ* : http://www.infoq.com » Le blog de Xébia : http://blog.xebia.fr/ » Les différents orateurs** et participants de ces

conférences / ateliers

* Les vidéos de toutes les présentations (hors ateliers) seront disponibles prochainement sur le site infoq * * Les noms des orateurs et entreprises concernées ont été volontairement tu. Je pourrai les fournir à la demande


15

19/0

5/20

15

http://en.wikipedia.org/wiki/Dave_Snowden

http://en.wikipedia.org/wiki/Dave_Snowden

http://www.poppendieck.com/

http://yowconference.com.au/slides/yow2014/Poppendieck-ScalingDilemma.pdf

http://yowconference.com.au/slides/yow2014/Poppendieck-ScalingDilemma.pdf

http://www.infoq.com/

http://blog.xebia.fr/

MERCI DE VOTRE ATTENTION

https://www.linkedin.com/pub/sagnon-joel/19/b44/2a8

https://twitter.com/jsagnon

JOËL SIELE SAGNON

SCRUM Master / Agile facilitateur

[email protected]


16

19/0

5/20

15




https://twitter.com/jsagnon

mailto:[email protected]

feeback scrumday2015

Technology