Ceci est un énergisant très efficace, et qui plaît à la plupart des publiques car il n'induit pas une forte mobilisation physique :D
Le principe est simple, mais il devient très challengeant au fil de l'égrenage des nombres.
Généralement, je commence par un mode "facile". Selon le nombre de participant, je choisis un chiffre butoir plus ou moins éloigné, pour que l'exercice reste dans une timebox raisonnable.
Le mode facile consiste à ce que chacun donne le nombre suivant à celui indiqué par son voisin (1,2,3,4,....). Généralement, je fais 2 tours de participant pour donner le rythme.
Le mode moyen consiste à remplacer les nombres pairs par un clap des mains (1, clap, 3, clap, 4, clap, 5, clap...). 2 tours de participant aussi.
Le mode difficile consiste à remplacer les nombres pairs par un clap, les multiples de 3 par 2 claps, et les nombres pairs et multiples de 3 par 3 claps.
(1, clap, clap clap, clap, 5, clap clap clap, 7, clap, clap clap, clap, 11, clap clap clap, 13, clap, clap clap, clap, 17,....).
Donner du rythme en tapant du pied pour inciter à l'accélération. L'équipe passe du dubitatif, à l'éclat de rire, pour finir au soutien de son favori.
Généralement, l'équipe est bien réveillée, et n'hésitez pas à leur donner quelques minutes pour refaire descendre l'adrénaline, pour que l'équipe soit bien concentrée pour la phase suivante.
Pascal OGil
mardi 29 novembre 2016
jeudi 24 novembre 2016
Retrospective : IceBreaker, mais pourquoi le faire?
La recommandation pour mener à bien une rétrospective se fait de mon point de vue en 5 étapes:
-- rappel des objectifs de la rétro
-- icebreaker
-- collecte des informations
-- brainstorming & plan d'action
-- Revue rapide de la rétro en vue de son amélioration
J'ai connu certains responsables ou "leader" qui ne passaient pas par la case Icebreaker. Les raisons soulevées sont nombreuses : l'équipe se connait, l'équipe est autonome, l'équipe n'en a pas besoin.
De mon point de vue, la réalité est un peu différente. Souvent, le principe n'est bien souvent pas bien compris, et les gens ne s'intéressent pas ou ne s'authorisent pas à une certaine variété, et restent dans la répétion, ou l'imitation.
Les icebreakers sont nombreux, et je serai tenté de dire, que vous n'êtes limités qu'à votre imagination.
Pour moi l'icebreaker répond à un principe simple, mais peuvent être utilisés à des fins plus subtiles.
Pour rappel, comme son nom l'indique, il est là pour briser la glace. L'équipe vient à une réunion, elle sait qu'elle va être sollicitée, mais prendre la parole face aux autres, en supporter le jugement, ....
La plupart des équipes que j'ai connu sont bien souvent "léthargiques" et attendent d'être menées, guidées. Bien souvent elle a besoin d'être activée pour déclencher une certaine dynamique.
Mais revenons tout d'abord aux "fins subtiles", laissant le but apparent de côté.
L'icebreaker peut être utilisée à des fins personnelles, ou dans un but de construire l'équipe (team building).
Parfois, quand je ne connais pas l'équipe, ou que je sens qu'il y a quelque chose qui cloche(?) dans l'attitude des gens, je lance un icebreaker de première approche.
Ces icebreakers me permettent d'avoir une première vision de l'état morale de l'équipe, voire de leur motivation, ou manque de motivation.
C'est une information très utile, pour orienter la manière dont vous allez conduire votre rétrospective. En effet, une équipe démotivée, étant là par la force des choses, il va falloir trouver les leviers pour que la rétrospective reste constructive, et éviter les éccueils du ressentiment.
Il existe plusieurs "outils" pour démarrer.
On peut utiliser le MVP, qui est plutôt simple. Motivé, Vacancier, Prisonnier. Vous pouvez ajouter les nuances que vous souhaitez. Chacun apporte un post it vierge, et le pose dans la case qui le concerne. Pas d'explication.
Cela permet de savoir si l'équipe vient contrainte, sans but, ou au contraire, très concerné par la rétrospective.
Le nikoniko, est simple d'utilisation aussi. Une colonne dans quelle situation vous sentez vous (travail intéressant, motivation, ....), et que pensez vous de l'équipe (bonne ambiance, bonne dynamique, ....). Chacun vient coller 2 post it de couleur (vert ou rouge), un dans chaque colonne.
Vous avez une photo plutôt fiable (si les gens jouent le jeu), vous permettant de connaître l'état d'esprit individuel d'une part, et la cohésion d'équipe d'autre part.
Il ne faut pas négliger le team building, le long des cérémonies agiles. Si on peut créer des souvenirs en communs, des "liants", qui permette de rendre la cohésion d'équipe plus forte il ne faut pas s'en priver.
Personnellement, il y a 2 approches à cela, et on va retrouver les thèmes classiques qui sont vis ma vie, et les énergisants
Ce sont les petits exercices qui permettent de manière simple, d'apprendre des choses sur ses équipiers.
Quelques exemples par exemple, chacun son tour, vient coller un post it, avec son film préféré, en expliquant pourquoi, ou quel film est ce?
On peut varier sur le plat préféré, le lieu de vacances préféré.
Un exercice rigolo à faire également concerne la situation géographique de chacun. Si globalement, l'éparpillement des gens est de 20km à la ronde. On peut imaginer indiquer que le centre de la pièce est le lieu de travail, on indique le nord, et à chacun de se mettre en position relative dans la pièce pour indiquer son lieu d'habitation.
On découvre alors que certains habitent à 2 pas ou au contraire à 1h de route.
La création de situation où on peut rire, où on voit les autres adopter des attitudes différentes, le fait de relevé un défi, typiquement où il faut être le meilleur, le challenge, ... tout cela crée aussi des souvenirs, et crée du liant entre les gens.
Internet regorge d'exemple, je vous laisse trouver ceux qui vous conviennent.
Le but de l'icebreaker a pour premier but de "réveiller" l'équipe, et surtout de démarrer une première expression sur des sujets non engageants.
Les gens parlent durant cet exercice devant tous, et chacun respecte la parole. Ca créée un sentiment de liberté, qui permettra ensuite d'avoir une phase d'expression libérée.
C'est un moment important pour l'animateur, où justement il faut veiller à ce que ce moment soit vraiment libre, qu'il n'y ait pas de jugement, mais plutôt qu'un intérêt/une écoute envers l'autre se créée.
Si suite à cet exercice les gens se sentent moqués, jugés.... l'exercice a perdu de son sens, et la partie expression libre sera compliquée.
Pas de soucis pour que cela reste un exercice amusant, mais la bienveillance et l'écoute reste des éléments primordiaux.
Il m'est arrivé de conduire des rétrospectives "stériles" où l'équipe avait besoin de laver son lave linge, ou de "pester" sur le management. Chacun s'explique, chacun donne son opinion, on partage, on créée des échanges, on essaye de rendre le fardeau plus simple à porter.
L'important c'est que malgré tout à la fin de l'exercice, même aucun plan d'amélioration n'est sorti, du fait de l'extériorisation des problèmes, le côté "vidage de sac" ait pu apporter une certaine sérénité à chacun.
En effet, le fait de pouvoir vider son sac, de partager son expérience, de voir que la personne n'est pas toute seule, qu'on la supporte, cela peut aussi resserrer les liens de l'équipe.
L'équipe doit en sortir apaisée, ou remontée, mais de manière positive (tous unis face), il faut essayer de tourner cela vers l'union, et pas le désespoir.
Ce n'est pas chose simple. Il convient d'avoir de vrais qualités humaines, et beaucoup de recul.
"Ok, voilà la situation, elle est compliquée, mais que fait on? Comment l'utilisons nous pour continuer à avancer? Vous venez tous les jours travailler, comment gérer la situation?"
Pascal Ogil
-- rappel des objectifs de la rétro
-- icebreaker
-- collecte des informations
-- brainstorming & plan d'action
-- Revue rapide de la rétro en vue de son amélioration
J'ai connu certains responsables ou "leader" qui ne passaient pas par la case Icebreaker. Les raisons soulevées sont nombreuses : l'équipe se connait, l'équipe est autonome, l'équipe n'en a pas besoin.
De mon point de vue, la réalité est un peu différente. Souvent, le principe n'est bien souvent pas bien compris, et les gens ne s'intéressent pas ou ne s'authorisent pas à une certaine variété, et restent dans la répétion, ou l'imitation.
Les icebreakers sont nombreux, et je serai tenté de dire, que vous n'êtes limités qu'à votre imagination.
Pour moi l'icebreaker répond à un principe simple, mais peuvent être utilisés à des fins plus subtiles.
Pour rappel, comme son nom l'indique, il est là pour briser la glace. L'équipe vient à une réunion, elle sait qu'elle va être sollicitée, mais prendre la parole face aux autres, en supporter le jugement, ....
La plupart des équipes que j'ai connu sont bien souvent "léthargiques" et attendent d'être menées, guidées. Bien souvent elle a besoin d'être activée pour déclencher une certaine dynamique.
LES FINS SUBTILES
Mais revenons tout d'abord aux "fins subtiles", laissant le but apparent de côté.
L'icebreaker peut être utilisée à des fins personnelles, ou dans un but de construire l'équipe (team building).
FINS PERSONNELLES
Parfois, quand je ne connais pas l'équipe, ou que je sens qu'il y a quelque chose qui cloche(?) dans l'attitude des gens, je lance un icebreaker de première approche.
Ces icebreakers me permettent d'avoir une première vision de l'état morale de l'équipe, voire de leur motivation, ou manque de motivation.
C'est une information très utile, pour orienter la manière dont vous allez conduire votre rétrospective. En effet, une équipe démotivée, étant là par la force des choses, il va falloir trouver les leviers pour que la rétrospective reste constructive, et éviter les éccueils du ressentiment.
Il existe plusieurs "outils" pour démarrer.
On peut utiliser le MVP, qui est plutôt simple. Motivé, Vacancier, Prisonnier. Vous pouvez ajouter les nuances que vous souhaitez. Chacun apporte un post it vierge, et le pose dans la case qui le concerne. Pas d'explication.
Cela permet de savoir si l'équipe vient contrainte, sans but, ou au contraire, très concerné par la rétrospective.
Le nikoniko, est simple d'utilisation aussi. Une colonne dans quelle situation vous sentez vous (travail intéressant, motivation, ....), et que pensez vous de l'équipe (bonne ambiance, bonne dynamique, ....). Chacun vient coller 2 post it de couleur (vert ou rouge), un dans chaque colonne.
Vous avez une photo plutôt fiable (si les gens jouent le jeu), vous permettant de connaître l'état d'esprit individuel d'une part, et la cohésion d'équipe d'autre part.
Team Building
Il ne faut pas négliger le team building, le long des cérémonies agiles. Si on peut créer des souvenirs en communs, des "liants", qui permette de rendre la cohésion d'équipe plus forte il ne faut pas s'en priver.
Personnellement, il y a 2 approches à cela, et on va retrouver les thèmes classiques qui sont vis ma vie, et les énergisants
Vis ma vie
Ce sont les petits exercices qui permettent de manière simple, d'apprendre des choses sur ses équipiers.
Quelques exemples par exemple, chacun son tour, vient coller un post it, avec son film préféré, en expliquant pourquoi, ou quel film est ce?
On peut varier sur le plat préféré, le lieu de vacances préféré.
Un exercice rigolo à faire également concerne la situation géographique de chacun. Si globalement, l'éparpillement des gens est de 20km à la ronde. On peut imaginer indiquer que le centre de la pièce est le lieu de travail, on indique le nord, et à chacun de se mettre en position relative dans la pièce pour indiquer son lieu d'habitation.
On découvre alors que certains habitent à 2 pas ou au contraire à 1h de route.
Energisant
La création de situation où on peut rire, où on voit les autres adopter des attitudes différentes, le fait de relevé un défi, typiquement où il faut être le meilleur, le challenge, ... tout cela crée aussi des souvenirs, et crée du liant entre les gens.
Internet regorge d'exemple, je vous laisse trouver ceux qui vous conviennent.
Fins avérées
Le but de l'icebreaker a pour premier but de "réveiller" l'équipe, et surtout de démarrer une première expression sur des sujets non engageants.
Les gens parlent durant cet exercice devant tous, et chacun respecte la parole. Ca créée un sentiment de liberté, qui permettra ensuite d'avoir une phase d'expression libérée.
C'est un moment important pour l'animateur, où justement il faut veiller à ce que ce moment soit vraiment libre, qu'il n'y ait pas de jugement, mais plutôt qu'un intérêt/une écoute envers l'autre se créée.
Si suite à cet exercice les gens se sentent moqués, jugés.... l'exercice a perdu de son sens, et la partie expression libre sera compliquée.
Pas de soucis pour que cela reste un exercice amusant, mais la bienveillance et l'écoute reste des éléments primordiaux.
Cas de démotivation
Il m'est arrivé de conduire des rétrospectives "stériles" où l'équipe avait besoin de laver son lave linge, ou de "pester" sur le management. Chacun s'explique, chacun donne son opinion, on partage, on créée des échanges, on essaye de rendre le fardeau plus simple à porter.
L'important c'est que malgré tout à la fin de l'exercice, même aucun plan d'amélioration n'est sorti, du fait de l'extériorisation des problèmes, le côté "vidage de sac" ait pu apporter une certaine sérénité à chacun.
En effet, le fait de pouvoir vider son sac, de partager son expérience, de voir que la personne n'est pas toute seule, qu'on la supporte, cela peut aussi resserrer les liens de l'équipe.
L'équipe doit en sortir apaisée, ou remontée, mais de manière positive (tous unis face), il faut essayer de tourner cela vers l'union, et pas le désespoir.
Ce n'est pas chose simple. Il convient d'avoir de vrais qualités humaines, et beaucoup de recul.
"Ok, voilà la situation, elle est compliquée, mais que fait on? Comment l'utilisons nous pour continuer à avancer? Vous venez tous les jours travailler, comment gérer la situation?"
Pascal Ogil
mardi 22 novembre 2016
Entreprise Agile
Entreprise Agile
Ces dernières années, un certain nombre d'entreprise voit échouer leur politique de développement logiciel, et en conséquence admire les modèles "émergeant" qui mettent en pratique l'agilité.
Après des années à vouloir se débarrasser de l'informatique, car trop coûteux, demandant trop de compétences changeantes, des plans de formation coûteux, les sociétés ont adoptés pour la plupart le mode forfait qui consiste à se débarrasser du projet et après un long effet tunnel découvrir un produit ne correspondant pas à leur attente.
Le coût d'achat du projet a bien été réduit, par contre le coût global, sans parler des dérives calendaires, ne sont rarement remontés dans les statistiques.
La honte de l'échec.
Les sociétés, face au mécontement de leur métier, face aux challenges de la concurrence, essayent de revenir à un mode plus collaboratif, et reprendre la main sur leur projet.
Mais après 20 ans, les personnes ont oublié comment travailler, et on retrouve sur les projets, une grande lacune dans la rigueur des spécifications, des tests, des recettes, des cas d'usages.
Les sociétés de service quant à elle, ont prospéré en vendant des profils qui ont comblé cette perte de compétence, le signe AMOA (assistance à maitrise d'ouvrage) est là pour en témoigner.
Les directeurs informatiques enjoignent leur équipe à travailler en agile pour améliorer la réussite de leur projet.
Mais en pratiquant une politique de l'autruche, et en occultant le constat que je fais ci dessus, qui restent des généralités, et sont bien en dessous des problèmes rencontrées par l'entreprise.
L'agilité n'est pas une baguette magique.
La recommandation que je ferai est de lancer un audit processus et méthode dans votre entreprise pour déterminer quelles sont les réelles problématiques que votre entreprise rencontre dans la livraison de ses services.
Peut être que l'agilité peut être une réponse en effet.
On parle beaucoup de transformation digitale. Il faut aussi parler de transformation agile. C'est une conduite de changement à mener.
Vos prestataires sont tous prêts à délivrer plus ou moins bien (convenons en), votre projet en agile (SCRUM par exemple). Par contre, vous, êtes vous prêts à en subir le cadre?
A mon sens, il y a plusieurs transformations à opérer, qui sont à des strates différentes, et qui sont des populations plus ou moins résistantes.
La strate la plus simple à convertir est la strate la plus opérationnelle.
1ere strate : le métier
A votre métier, si vous lui dites, qu'ils auront des demos régulièrement, une pleine visibilité sur ce qui est produit et quand, et qu'en plus ils pourront être impliqués dans le lotissement des fonctionnalités, j'ai peine à croire qu'ils résisteront à cet appel agile.Je ne dis pas que c'est simple. Ils auront besoin de cadre, de comprendre la structure, d'être rigoureux.
La transparence affichée en terme de vélocité, est aussi une contrainte, qu'ils doivent assimiler. Le timebox comporte une productivité max, et ils doivent être en mesure de prioriser leur backlog, et ne pourront pas pousser des choses en plus au delà de la capacité.
La backlog doit rester fourni, et doit être prête dans le cadre temps fourni. Ils épuisent la capacité de prod de l'équipe, si les éléments ne sont pas prêts, ou s'ils arrivent au fil de l'eau.
Ils doivent fournir des cas d'usage, et doivent participer aux tests dans la structure temps imposé.
C'est un contrat bi partite. L'équipe produit au mieux, s'adapte sans cesse, pour donner satisfaction, et se concentre sur la valeur métier, mais le cadre de fourniture des besoins doit être respecté.
2e strate, les équipes transverses, et les équipes en adhérence.
L'une des difficultés des équipes est de réussir à se synchroniser avec les autres équipes (exploitation, intégration, architecture, .... ou projet en adhérence).Ces équipes sont souvent pilotés par des jalons, des délais, et l'incertitude ne fait pas partie de leur quotidien.
Bien souvent, le rythme des équipes agiles est souvent un rythme soutenu, avec des livraisons fréquentes. Les équipes transverses ont souvent du mal à suvire le rythme et à s'adapter.
Les outils, les hommes ne sont pas préparés aux changements.
C'est un verrou difficile à déverouiller la plupart du temps, car ils ont souvent un poids important dans l'organisation, et demandent aux autres de s'adapter et pas l'inverse.
Il est possible de conduire un changement dans ces équipes également, en proposant une mise en place de Kanban IT, par exemple, et de mettre en place un diagramme cumulé de flux.
Ce diagramme permet de montrer quels sont les goulots d'étranglement en terme de traitement du livrable, et de pouvoir déclencher des actions de fluidification.
3e strate le pilotage & les managers
Pendant 20 ans, la bataille s'est mené sur l'interprétation de la bible cahier des charges, et de son implémentation complète, et sans réserve.Aujourd'hui, en agile, le projet se mène en coresponsabilité, et arriver en bout de projet avec la spécification initiale n'est plus un but en soi.
Le management par la terreur n'est plus adapté, il faut changer le mode de travail, et surtout le reporting induit par ce nouveau mode de travail.
Quels sont les bénéfices d'un projet agile? Est ce que cela n'est pas cela qu'il faut mesurer au final?
Je serai très vigileant sur la définition des KPIs à mettre en oeuvre. Ma première recommandation est que le projet étant en coresponsabilité, les KPIs doivent pouvoir adresser tous les acteurs du projet.
On challenge le prestataire, mais on challenge aussi les équipes en interne.
Les kpis les plus souvent demandés, sont autour de la qualité et de la vélocité.
Ce sont des kpis issus de l'ancien mode de fonctionnement.
Je ne parlerai pas réellement de vélocité, mais je suivrai plutôt un indicateur lié à la prédictabilité de l'équipe. On pointe du doigt une notion qui me paraît plus essentiel, que la vitesse pure de l'équipe.
J'aimerai voir la capacité d'agilité du client : est il à niveau dans ce qu'on attend d'un backlog (définition des US de qualité, à temps, priorisé). J'aime aussi ajouter une notion, qui permet de déterminer la vie du backlog.
Finalement, un backlog figé (en quantité et en priorité) représente aussi un échec de l'agilité, ou une application abusive de la méthode, alors qu'un waterfall suffirait.
J'aimerai voir la satisfaction client (métier). Est ce que ce qui a été demandé a été développé? Est ce que l'expérience utilisateur est à niveau? Est ce que le sprint apporte un niveau de valeur métier suffisant?
Il est envisageable d'avoir une notation permettant de valoriser, au delà de nos attentes.
La qualité doit être envisagé sur plusieurs niveaux : qualimétrie, couverture de TU, régressions, bug utilisateur, non respect de l'US.
Les managers des chefs de projet doivent donc se fier à de nouveaux indicateurs, et la consommation de budget doit être surveillée, mais doit relever d'une surveillance ratio budget/valeur apportée.
Il ne doit pas être envisagé seule, ou sur la création de telle ou telle fonctionnalité. Il faut avoir en tête investissement et retour sur investissement.
On ne peut pas imaginer de demander à des équipes de changer de manière de travailler, si les "surveillants" ne changent eux même pas d'habitude, et d'attitude.
Il est illusoire de penser d'effectuer un changement de culture aussi profond, en ne demandant qu'à la "strate" opérationnelle de modifier sa manière de travailler.
vendredi 18 novembre 2016
Lego4Scrum
Lego4Scrum a son propre site, mais je trouvais cela intéressant d'en faire un retour sur son utilisation.
J'utilise ce serious game, en fin de formation Scrum. Une fois que les formées possèdent les fondamentaux de Scrum, et qu'ils ont fait des exercices élémentaires pour chaque étape, il st vraiment intéressant to gérer un projet Scrum dans son ensemble.
Scrum concerne la production d'un produit, de manière itérative, et incrémentale.
Je pense que de bâtir une ville, est conforme à cette approche. Vous pouvez livrer bâtiment par bâtiment, ou vous pouvez livrer des améliorations de bâtiment. Ce qui permet d'avoir un sprint goal, et d'avoir plusieurs features par sprint.
Le propos de cet exercice est de vraiment comprendre pourquoi chaque "cérémonie" est importante, et qu'en est le but.
Généralement, je prépare avant l'exercice, un jeu de post it, avec l'ensemble des bâtiments possibles, et des choses qu'on peut trouver dans une ville agréable. J'essaye d'avoir de gros bâtiments (école, supermarché, maison, piscine, mairie,...), des choses moyennes (square, routes,....), et des petites constructions (lampadaire, bus, arrêt de bus, cabine téléphonique...).
Avant l'exercice je choisis 2 personnes, et nous faisons la priorisation du backlog. Généralement, nous faisons cela à l'aide d'un moscow (must have, should have, could have, wish to have).
Je prends une demi heure pour cela. C'est le bon moment pour le reste de l'équipe de faire une pause.
L'exercice prend environ 2h. Généralement, je choisis un PO et je fais des équipes de 3 ou 4 personnes (pas moins). On déroule 6 sprints, et tous les 2 sprint je fais tourner le PO. Les personnes qui veulent découvrir le rôle de PO le peuvent, et tout le monde peut jouer aux legos. Gardons le fun.
Je conserve quant à moi le rôle de Scrum Master, à moins que quelqu'un insiste pour me prendre le rôle. Dans cet exercice, le Scrum Master est gardien du temps, et vérifie que les cérémonies soient correctement menées. Il facilite également, en réamenageant la salle, fournissant les matériels nécessaires....
Un sprint contient 4 étapes:
J'utilise ce serious game, en fin de formation Scrum. Une fois que les formées possèdent les fondamentaux de Scrum, et qu'ils ont fait des exercices élémentaires pour chaque étape, il st vraiment intéressant to gérer un projet Scrum dans son ensemble.
Scrum concerne la production d'un produit, de manière itérative, et incrémentale.
Je pense que de bâtir une ville, est conforme à cette approche. Vous pouvez livrer bâtiment par bâtiment, ou vous pouvez livrer des améliorations de bâtiment. Ce qui permet d'avoir un sprint goal, et d'avoir plusieurs features par sprint.
Le propos de cet exercice est de vraiment comprendre pourquoi chaque "cérémonie" est importante, et qu'en est le but.
Généralement, je prépare avant l'exercice, un jeu de post it, avec l'ensemble des bâtiments possibles, et des choses qu'on peut trouver dans une ville agréable. J'essaye d'avoir de gros bâtiments (école, supermarché, maison, piscine, mairie,...), des choses moyennes (square, routes,....), et des petites constructions (lampadaire, bus, arrêt de bus, cabine téléphonique...).
Avant l'exercice je choisis 2 personnes, et nous faisons la priorisation du backlog. Généralement, nous faisons cela à l'aide d'un moscow (must have, should have, could have, wish to have).
Je prends une demi heure pour cela. C'est le bon moment pour le reste de l'équipe de faire une pause.
L'exercice prend environ 2h. Généralement, je choisis un PO et je fais des équipes de 3 ou 4 personnes (pas moins). On déroule 6 sprints, et tous les 2 sprint je fais tourner le PO. Les personnes qui veulent découvrir le rôle de PO le peuvent, et tout le monde peut jouer aux legos. Gardons le fun.
Je conserve quant à moi le rôle de Scrum Master, à moins que quelqu'un insiste pour me prendre le rôle. Dans cet exercice, le Scrum Master est gardien du temps, et vérifie que les cérémonies soient correctement menées. Il facilite également, en réamenageant la salle, fournissant les matériels nécessaires....
Un sprint contient 4 étapes:
- Sprint planning : 4 min
- Sprint : 7 min
- Sprint review : 4 min
- Sprint retrospective : 4 min
Sprint planning
Product owner choisit pour chaque équipe, un grand bâtiment et 2 autres features. C'est vraiment intéressant quand le PO prend un peu de temps pour broder une histoire, expliquer les raisons de ces choix (sécurité des enfants, ville propre, ville écolo, élections...).
L'équipe doit obtenir tous les détails nécessaires à l'élaboration. J'ai choisi de faire un poker planning malré tout, même si le temps est court. Cela leur permet par expérience d'évaluer leur capacité à prendre telle ou telle feature.
Sprint
Peu de choses à dire sur le sprint. L'équipe essaye de trouver sa manière de travailler. Généralement, le premier sprint est difficile. Il y a beaucoup de legos, ils ne voient pas comment s'organiser, ça patauge. C'est assez représentatif du premier sprint.
Je demande à l'équipe de ne construire que des façades, car le temps est trop court.
Dans le cas où l'équipe fini avant la fin du sprint, ils peuvent réclamer des features au PO. Pour ma part, je conseille à l'équipe d'améliorer la feature en cours, et surtout de bien préparer la démo. Il est important que l'équipe soit sensibilisé à la qualité.
Sprint Review
Généralement, l'équipe n'a pas en tête la démo, ni en quoi cela consiste. Les bâtiments sont prêts, mais pas forcément intégrés à la ville. L'histoire utilisateur n'existe pas, l'aspect "vendre" son travail n'existe pas.
Le PO doit jouer le jeu, et avoir une orientation utilisateur. Généralement, à la 1ere démo, le bâtiment est refusé, car l'équipe s'est concentrée sur des éléments structurels, alors que le PO avait fait des recommandations qui étaient importantes pour l'utilisation du bâtiment.
Cela rejoint la mentalité technique versus le besoin métier.
Il faut que l'équipe change d'état d'esprit, et comprenne qu'ils doivent construire quelque chose qui a de la valeur pour le PO, pas juste quelque chose qui soit techniquement chouette.
Exemple: l'équipe présente son square, avec des supers jeux, mais ils ont oublié les barrières autour. La préoccupation du PO était sur la sécurité du square. La feature est invalidée.
Sprint retrospective
La plupart des équipes, me disent que ce n'est pas utile, les temps sont trop courts, et de toute façon que se dire en 4min.
La rétro est obligatoire mais surtout très utile.
La plupart des erreurs faites dans le sprint, peuvent être évitées, certaines choses peuvent être améliorées. Vous pouvez aider l'équipe à leur faire comprendre ce qui pourrait être meilleur
- Posez la question de savoir quelle était la préoccupation du PO sur le sprint
- Prendre des notes pendant le sprint planning
- faire des maquettes, et les faire valider
- améliorer l'organisation de l'équipe (recherche de briques, construction, intégration,...)
- trier les briques pour être plus efficace
- Faire un inventaire pour savoir si ce que le PO demande est possible ou non, ou pouvoir lui faire des constructions
- Plus de qualité
Suivi
Généralement, je produis un graphique, présentant la vélocité de l'équipe par sprint. Cela leur permet de connaître leur vélocité, comparer de sprint en sprint, se challenger...
Cela permet également de voir si l'équipe arrive à trouver son rythme, ou au contraire, s'ils sont trop "fous" et désorganisés.
Debrieffing
Généralement, je fais un tour de table.
Ensuite j'effectue un retour sur ces sujets:
- Un grand succès, généralement on a une ville, et l'équipe au début ne se pensait pas capable d'aller aussi loin, et de créer un projet de zéro.
- Le graphique permet de voir rapidement quand l'équipe s'est stabilisé.
- Retrospective : partage sur les points d'améliorations trouvés par les équipes et conséquences réelles
- Démo : son importance, les discussions générées, la compréhension du besoin, les difficultés, la motivation qui en ressort, lié à la fierté d'avoir produit de nouvelles features.
- Planning : souligner l'importance de ce moment pour travailler sereinement, et avoir la certitude de bien partir.
- Sprint : souligner l'importance de l'auto organisation, sans un chef de projet, la capacité à résoudre les problèmes par eux même.
Ce serious game est intense, mais permet de bien appliquer la méthodo. Cela met bien en évidence l'importance de chaque "cérémonie" et l'importance de la communication.
Rappeler l'importance du daily meeting, malgré le fait que dans le jeu il n'était pas possible de le faire, rappeler les concepts principaux, et le pourquoi.
Ne minimaliser pas votre rôle, le travail de facilitation, de coaching, pour que le jeu maintienne un rythme soutenu n'est pas chose aisée.
QuickWin?
Quelle est la différence entre quickwin et petit pas? Normalement, ce n'est qu'une question de communication à propos d'un succès.
Quand vous travaillez à faire un changement important dans votre organisation, ou quand vous souhaitez essayer une nouvelle manière de travailler, ou encore quand vous souhaitez construire quelque chose de nouveau, je pense qu'il est vraiment difficile de tout planifié, et d'avoir des jalons prédéterminés fiables.
Vous avez toujours des forces externes, qui à tout moment, peuvent faire en sorte que quelque chose se passe mal. De ce que m'apprend l'agilité, je vous conseille d'essayer, d'inspecter le résultat, et d'adapter le processus. C'est la méthode des petits pas. Un enfant qui apprend à marcher.
Minimiser les risques, et gardez en tête que vous pouvez toujours changer quelque chose dans votre plan, pour redresser la barre vers la bonne direction.
En cela, certaines personnes aiment les quickwins. C'est un mot agréable à entendre. Nous produisons quelque chose sur lequel nous pouvons communiquer, et montrer notre succès. C'est bon pour la motivation, c'est bon se savoir que nous allons dans la bonne direction, que nous apportons de la valeur, et c'est bon à montrer à nos managers.
Mais rappelons nous, que le quickwin est un pas dans le mouvement. La valeur gagnée doit être utilisée pour effectuer les pas suivants. Comme le premier pas engendre une motricité, une force permettant de continuer le mouvement.
La valeur gagnée ne doit pas être un profit qui part intégralement dans la bourse de votre manager, comme un trésor gagné qui lui permet de justifier de ses propres résultats.
Un quickwin n'est pas la fin d'un process, mais c'est un pas utile pour démontrer que nous avons pris les bonnes décisions, et que nous avons trouvé l'énergie pour avancer.
Quand vous travaillez à faire un changement important dans votre organisation, ou quand vous souhaitez essayer une nouvelle manière de travailler, ou encore quand vous souhaitez construire quelque chose de nouveau, je pense qu'il est vraiment difficile de tout planifié, et d'avoir des jalons prédéterminés fiables.
Vous avez toujours des forces externes, qui à tout moment, peuvent faire en sorte que quelque chose se passe mal. De ce que m'apprend l'agilité, je vous conseille d'essayer, d'inspecter le résultat, et d'adapter le processus. C'est la méthode des petits pas. Un enfant qui apprend à marcher.
Minimiser les risques, et gardez en tête que vous pouvez toujours changer quelque chose dans votre plan, pour redresser la barre vers la bonne direction.
En cela, certaines personnes aiment les quickwins. C'est un mot agréable à entendre. Nous produisons quelque chose sur lequel nous pouvons communiquer, et montrer notre succès. C'est bon pour la motivation, c'est bon se savoir que nous allons dans la bonne direction, que nous apportons de la valeur, et c'est bon à montrer à nos managers.
Mais rappelons nous, que le quickwin est un pas dans le mouvement. La valeur gagnée doit être utilisée pour effectuer les pas suivants. Comme le premier pas engendre une motricité, une force permettant de continuer le mouvement.
La valeur gagnée ne doit pas être un profit qui part intégralement dans la bourse de votre manager, comme un trésor gagné qui lui permet de justifier de ses propres résultats.
Un quickwin n'est pas la fin d'un process, mais c'est un pas utile pour démontrer que nous avons pris les bonnes décisions, et que nous avons trouvé l'énergie pour avancer.
Je ne veux plus entendre le mot "agile"
Je ne veux plus entendre le mot "agile"
Titre choc, pour ce billet. C'est une réflexion que je me fais de plus en plus. Ne me parlez plus d'agile. En fait, n'employez plus le mot 'agile' en ma présence.
N'employez plus à tort et à travers comme la clef de résolution de toutes vos peines le mot "agile".
Ne pensez pas que utilisez le mot agile est une incantation qui balayera devant vous toutes vos incapacités.
J'aime l'agilité, je pense essayer de vivre les valeurs portées par le mot "agile", mais je ne les impose pas, et surtout je ne les impose pas à toutes les situations.
Certaines sont de bon sens, d'autres demandent une mise en oeuvre rigoureuse, dans un cadre donné.
J'utiliserai le terme "ils" pour désigner le groupe de personne qui veulent l'agilité en résolution de tous leurs maux.
Les "ils" ont tous entendu parler de l'agilité, les "ils" savent que c'est une méthode qui répond à des problématiques, à des situations.
C'est vrai, l'agilité est une pratique permettant de résoudre des problèmes complexes, dans un environnement fluctuant (dans une certaine mesure), et permettant de s'adapter, et d'accepter le changement.
Ce que les "ils" retiennent sont les mots adaptations, complexes et changement.
Moi je leur apporte les mots responsabilité, engagement, vision, rigueur, amélioration continue, changement de posture, collaboration, écoute, respect.
Trop souvent, les "ils" choisissent ce qui les arrange, et surtout ce qui ne leur demande que peu d'effort. La mise en oeuvre d'une pratique agile, est avant tout l'acceptation de mettre en place des règles de groupe, qui contraignent un cadre, afin que chacun puisse s'engager, en ayant en tête les règles du jeu.
L'abandon des règles de groupe, permet trop facilement aux "ils" de se déresponsabiliser face aux groupes, et de ne porter son engagement que sur sa portée individuelle.
De mon expérience, les "ils" sont dans le paradoxe constant. Les "ils" veulent un travail collaboratif leur permettant de faire porter l'effort sur un nombre de personnes, mais les "ils" ne délèguent pas. Faites à ma place, mais je veux le faire aussi par peur que cela ne soit pas bien fait, ou ne plus "être" aux commandes.
Cette technique désengage l'équipe qui ne perçoit pas sa capacité à se responsabiliser et à produire de la valeur.
Le changement est aussi un "mal du siècle". Là où la vertue de l'agile est de pouvoir s'adapter au changement, pour ne produire que de la valeur, continuellement, les "ils" perçoivent ce paradigme, comme la possibilité de ne pas définir, et de changer continuellement, et de profiter de la capacité d'adaptation proposé par l'agilité.
Malheureusement, une autre méthode existe depuis longtemps pour cela, et l'agile n'a pas la prétention de la supplanter : "A L'arrache".
Travailler de manière "agile" est un changement important. On ne remplace pas le chaos et une absence de méthode, en agitant un colifichet nommé "agilité".
Se rattraper aux branches quand on tombe, ce n'est pas être agile. Etre agile, c'est surtout mesurer le risque, l'accepter, trouver la meilleure solution pour surmonter l'obstacle, bâtir la solution en équipe, et enfin réussir à passer l'obstacle.
Je pense que les meilleurs "grimpeurs" (escalade libre notamment), sont des gens qui ont une préparation très importante, qui choisissent leur route de manière consciente, et basé sur une expérience en ayant mesuré les risques et en évaluant leur capacité à faire.
Cela leur demande des semaines de préparation, avant de s'engager sur une nouvelle voie d'escalade.
Tout commence avec la vision. La vision c'est ce qui porte l'équipe. Où va-t-on, pourquoi, et quelle valeur on en retire? (J'aborderai à un autre moment coût et valeur.)
Le plan permet de définir comment on y va, et de définir les règles de vie. Il faut des règles, comme un sport. Les règles définissent la fin de la partie, comment on mesure le succès, ce qui est permis, ....
L'engagement et la responsabilité sont 2 piliers importants. La responsabilité est une responsabilité morale mais c'est surtout une responsabilité collective. Tout succès, toute défaite est le fait de l'équipe. Quelqu'un qui n'a pas pu terminer sa tâche, relève de la responsabilité de l'équipe.
A-t-on sousestimé le travail? A-t-on surestimé la capacité à faire? A-t-on vérifié le bon niveau de compétence? A-t-on apporté toute l'aide nécessaire?
L'engagement est la capacité de chacun à s'investir pour les autres pour que le projet au global réussisse.
L'amélioration continue est la capacité à se critiquer, et à trouver les axes d'amélioration. Cela demande une capacité d'auto inspection, une capacité à critiquer de manière constructive, mais surtout c'est une ouverture vers les autres.
Partager ses propres problèmes, sans avoir peur d'être jugé. Etre capable d'écouter sans juger. Etre capable d'écouter, avoir une écoute active. Est ce que les "ils" savent encore écouter sans imposer leur expérience, leur point de vue?
Accepter le changement oui! Accepter son propre changement en premier lieu, déclencher le changement chez les autres.
Accepter le changement sur votre projet ne devient, ensuite que du bon sens. Pourquoi produire quelque chose qui n'a plus de valeur. Cela n'a pas de sens.
Avant de demander à travailler en mode "agile", trouver quelqu'un qui vous écoutera, qui vous aidera à fixer vos peines, qui écoutera votre projet, et qui expliquera ce qu'implique l'agilité.
Alors seulement, une fois que vous aurez mesurer les transformations nécessaires dans votre manière de travailler, engagez vous, et travaillez en agile.
Titre choc, pour ce billet. C'est une réflexion que je me fais de plus en plus. Ne me parlez plus d'agile. En fait, n'employez plus le mot 'agile' en ma présence.
N'employez plus à tort et à travers comme la clef de résolution de toutes vos peines le mot "agile".
Ne pensez pas que utilisez le mot agile est une incantation qui balayera devant vous toutes vos incapacités.
J'aime l'agilité, je pense essayer de vivre les valeurs portées par le mot "agile", mais je ne les impose pas, et surtout je ne les impose pas à toutes les situations.
Certaines sont de bon sens, d'autres demandent une mise en oeuvre rigoureuse, dans un cadre donné.
J'utiliserai le terme "ils" pour désigner le groupe de personne qui veulent l'agilité en résolution de tous leurs maux.
Les "ils" ont tous entendu parler de l'agilité, les "ils" savent que c'est une méthode qui répond à des problématiques, à des situations.
C'est vrai, l'agilité est une pratique permettant de résoudre des problèmes complexes, dans un environnement fluctuant (dans une certaine mesure), et permettant de s'adapter, et d'accepter le changement.
Ce que les "ils" retiennent sont les mots adaptations, complexes et changement.
Moi je leur apporte les mots responsabilité, engagement, vision, rigueur, amélioration continue, changement de posture, collaboration, écoute, respect.
Trop souvent, les "ils" choisissent ce qui les arrange, et surtout ce qui ne leur demande que peu d'effort. La mise en oeuvre d'une pratique agile, est avant tout l'acceptation de mettre en place des règles de groupe, qui contraignent un cadre, afin que chacun puisse s'engager, en ayant en tête les règles du jeu.
L'abandon des règles de groupe, permet trop facilement aux "ils" de se déresponsabiliser face aux groupes, et de ne porter son engagement que sur sa portée individuelle.
De mon expérience, les "ils" sont dans le paradoxe constant. Les "ils" veulent un travail collaboratif leur permettant de faire porter l'effort sur un nombre de personnes, mais les "ils" ne délèguent pas. Faites à ma place, mais je veux le faire aussi par peur que cela ne soit pas bien fait, ou ne plus "être" aux commandes.
Cette technique désengage l'équipe qui ne perçoit pas sa capacité à se responsabiliser et à produire de la valeur.
Le changement est aussi un "mal du siècle". Là où la vertue de l'agile est de pouvoir s'adapter au changement, pour ne produire que de la valeur, continuellement, les "ils" perçoivent ce paradigme, comme la possibilité de ne pas définir, et de changer continuellement, et de profiter de la capacité d'adaptation proposé par l'agilité.
Malheureusement, une autre méthode existe depuis longtemps pour cela, et l'agile n'a pas la prétention de la supplanter : "A L'arrache".
Travailler de manière "agile" est un changement important. On ne remplace pas le chaos et une absence de méthode, en agitant un colifichet nommé "agilité".
Se rattraper aux branches quand on tombe, ce n'est pas être agile. Etre agile, c'est surtout mesurer le risque, l'accepter, trouver la meilleure solution pour surmonter l'obstacle, bâtir la solution en équipe, et enfin réussir à passer l'obstacle.
Je pense que les meilleurs "grimpeurs" (escalade libre notamment), sont des gens qui ont une préparation très importante, qui choisissent leur route de manière consciente, et basé sur une expérience en ayant mesuré les risques et en évaluant leur capacité à faire.
Cela leur demande des semaines de préparation, avant de s'engager sur une nouvelle voie d'escalade.
Tout commence avec la vision. La vision c'est ce qui porte l'équipe. Où va-t-on, pourquoi, et quelle valeur on en retire? (J'aborderai à un autre moment coût et valeur.)
Le plan permet de définir comment on y va, et de définir les règles de vie. Il faut des règles, comme un sport. Les règles définissent la fin de la partie, comment on mesure le succès, ce qui est permis, ....
L'engagement et la responsabilité sont 2 piliers importants. La responsabilité est une responsabilité morale mais c'est surtout une responsabilité collective. Tout succès, toute défaite est le fait de l'équipe. Quelqu'un qui n'a pas pu terminer sa tâche, relève de la responsabilité de l'équipe.
A-t-on sousestimé le travail? A-t-on surestimé la capacité à faire? A-t-on vérifié le bon niveau de compétence? A-t-on apporté toute l'aide nécessaire?
L'engagement est la capacité de chacun à s'investir pour les autres pour que le projet au global réussisse.
L'amélioration continue est la capacité à se critiquer, et à trouver les axes d'amélioration. Cela demande une capacité d'auto inspection, une capacité à critiquer de manière constructive, mais surtout c'est une ouverture vers les autres.
Partager ses propres problèmes, sans avoir peur d'être jugé. Etre capable d'écouter sans juger. Etre capable d'écouter, avoir une écoute active. Est ce que les "ils" savent encore écouter sans imposer leur expérience, leur point de vue?
Accepter le changement oui! Accepter son propre changement en premier lieu, déclencher le changement chez les autres.
Accepter le changement sur votre projet ne devient, ensuite que du bon sens. Pourquoi produire quelque chose qui n'a plus de valeur. Cela n'a pas de sens.
Avant de demander à travailler en mode "agile", trouver quelqu'un qui vous écoutera, qui vous aidera à fixer vos peines, qui écoutera votre projet, et qui expliquera ce qu'implique l'agilité.
Alors seulement, une fois que vous aurez mesurer les transformations nécessaires dans votre manière de travailler, engagez vous, et travaillez en agile.
Inscription à :
Articles (Atom)