Agilité, n’oublions pas les valeurs

Agilité, n’oublions pas les valeurs

Deux expériences client contradictoires :

● Application quasi stricte des cérémoniels Scrum

● Application adaptée des principes du manifeste l’agile

Quels sont les effets observés ?

Quels pièges peuvent être évités ?

Agilité, n’oublions pas les valeurs

[REX]L’agilité au détriment de l’équipe et du

projet

Le contexte du projet

● Intranet d’une grande entreprise● 120 000 utilisateurs possibles, 2000

simultanés● En place depuis 2011● La cellule de développement vend ses

prestations aux autres divisions du groupe● Projet développé pour sa première version

en 6 mois

Coté technique

● Portail Liferay très customisé● Important code legacy● Equipe permanente de 3 à 8 développeurs

sur la partie socle● 1 à 3 module(s) développés simultanément

avec des équipes réduites (1 à 3 développeur(s))

Agilité

● Mise en place depuis le début● Tous les rôles scrum présents : scrum

master, product owner, développeurs● Rôles supplémentaires : experts, testeurs,

directeur de projet● Tous les rituels scrum présents et adaptés

au fonctionnement de la cellule

Et pourtant ...

● Une équipe frustrée et sous pression● Un scrum master démotivé● Un turn over important● Des retards de livraison et de nombreux

bugs● Une PO tendue et surbookée● Une dette technique croissante et mal

surveillée

Comment en arrive-t-on là ?

Les rituels sont importants pour structurer l’équipe et son fonctionnement!

Mais que se passe-t-il lorsque les valeurs qu’ils véhiculent sont oubliées en chemin ?

Le plan

1. Le Sprint2. Le Stand Up3. Le Sprint Planning4. La Sprint Review5. La rétrospective6. Conclusion

Le sprint

Le but d’un sprint est de livrer un incrément du produit dans une période de temps courte afin d’en maîtriser la complexité technique et fonctionnelle. Pour cela :

● Le but du sprint ne peut être modifié ● La composition de l'équipe reste constante ● La qualité n'est pas négociable

Pendant un an le sonar du projet pointait sur une mauvaise url!

On ne s’en est rendu compte qu’au hasard d’une absence de la PO et donc d’US dans le sprint : le seul moment où l’équipe a été autorisée à faire de la qualimétrie… Le score était descendu à 47% de conformation aux règles !

Le sprint

● La liste d'items est sujette à négociations entre le PO et l'équipe de développement.

L’équipe de développement n’est pas consultée pour le choix des US, ne connaît pas sa capacité de production et ne connaît pas non plus le but du sprint quand il commence…

Ce manque de visibilité provoque du stress dans l’équipe qui ne sait plus comment prioriser et s’organiser !

Le plan

1. Le Sprint2. Le Stand Up3. Le Sprint Planning4. La Sprint Review5. La rétrospective6. Conclusion

Le stand up

● Synchronisation de l’équipe

Les interventions lors du stand up tiennent plus de l’interrogation orale sur les temps de développement...

● Évaluation de l’avancement vers le but de l’itération

Le chiffrage estimé est le chiffrage obligatoire, le dépasser c’est mettre le sprint en danger parce qu’il est complet à quasiment 100%Trop de dépassements provoquent une convocation seul à seul avec le scrum master...

Le stand up

● Collecte d’informations nécessaires à l’auto-organisation● Inspection et adaptation

En cas de problème, le scrum master exige l’intervention d’un expert

( sorte de pompier qui est supposé sauver le chiffrage et navigue d’un dev à l’autre toute la journée pour sauver les meubles )

Les devs sont infantilisés et humiliés dans leur façon de travailler, le stress de dépasser le chiffrage est omniprésent.

L’intervention systématique des experts ralentit l’apprentissage sur les technos et le produit et réduit l’efficacité de l’équipe !

Le plan

1. Le Sprint2. Le Stand Up3. Le Sprint Planning4. La Sprint Review5. La rétrospective6. Conclusion

Le sprint planning

Le but de la réunion de planification d’itération est que le PO et l’équipe trouvent ensemble le but du sprint et son organisation.

L’équipe chiffre les US proposées par le PO à l’aide du backlog priorisé, du dernier incrément réalisé et de la capacité de production du prochain sprint.

● Le backlog n’est pas priorisé, la PO attend le chiffrage pour faire un choix budgétaire, pour cela elle rédige une cinquantaine d’US!

○ Elle est fatiguée et tendue en permanence○ Quand elle est absente, plus rien n’avance○ Les US sont souvent de qualité très moyenne

Le sprint planning

● L’équipe ne dispose pas du dernier incrément ni de la capacité de production du prochain sprint…

● Au bout de 3 ou 4 heures tout le monde se désintéresse un peu ce qui impacte fortement la qualité des chiffrages !

L’équipe détermine ensuite le but du sprint et le découpage des tâches pour le début du sprint.

● Le choix des US traitées dans le sprint est laissé entièrement au choix de la PO qui le communique souvent 2 à 3 jours après le début du sprint

Ce manque de visibilité stresse l’équipe et le scrum master qui est obligé de “mendier” les US et de combler les “trous” avec des anomalies datant souvent de plusieurs mois (backlog séparé).

Le plan

1. Le Sprint2. Le Stand Up3. Le Sprint Planning4. La Sprint Review5. La rétrospective6. Conclusion

La sprint review

Le but de la revue est de présenter les items sélectionnés en début de sprint et de les valider avec le PO.

● Toutes les US possibles, même non testées sont présentées, l’important est d’en présenter un MAXIMUM

L’équipe présente les items réalisés puis fait le bilan du sprint avec le PO et remet à jour le backlog.

● Un grand nombre de bugs et de manques sont soulevés○ la PO est blasée la plupart du temps, quelquefois en colère ○ le SM a manifestement envie de disparaître sous terre, il soupire tout

le long des démos en notant toutes les remarques

La sprint review

L’équipe fait ensuite le point sur l’avancement du projet avec toutes les parties prenantes, et ajuste la planification du projet en fonction des opportunités découvertes.

● A la fin de la review aucun bilan n’est fait, le backlog n’est pas présenté… En réalité tout le monde s’enfuit, satisfait si aucun clash n’a eu lieu…

● Aucune visibilité n’est donnée sur l’évolution du produit. Tout le monde s’en plaint systématiquement, le directeur de projet en tête … La motivation d’arriver au bout du sprint suivant baisse baisse baisse….

● Le principe est de noter tous les bugs qui seront corrigés dans la tâche retour de démo, pour future validation lors d’un sprint de recette. Les retours de démo ne sont pas comptabilisés dans les US de départ ! Jackpot !!

Le plan

1. Le Sprint2. Le Stand Up3. Le Sprint Planning4. La Sprint Review5. La rétrospective6. Conclusion

La rétrospective

Au début systématique à la fin de chaque sprint, elle a été abandonnée petit à petit sur décision du scrum master

Elle réunit toute l’équipe, PO compris

● Seule l’équipe de développement, les experts, les testeurs et le scrum master étaient conviés

● La rétrospective sert en réalité de défouloir aux développeurs, fatigués de la pression mise sur eux. En particulier à l’encontre du PO et du directeur de projet… C’est une suite de coups de gueule….

La rétrospective

L’inspection de l’itération précédente pour déterminer les éléments à garder, ceux à améliorer.

● Le SM qui en a marre de se battre contre des moulins à vent, hausse les épaules la plupart du temps…

Cela conduit à l’élaboration d’un plan d’action d’améliorations pour l’itération suivante

● C’est un moment d’euphorie passagère pour les devs, certaines fois des décisions sensées ont même été prises dans un grand élan de bonne volonté générale !

La rétrospective

● Les plans d’actions proposés sont ignorés quand ils concernent la hiérarchie de la cellule ou les relations avec le client, ce qui conduit à plus de frustration de l’équipe…!

● Les plans d’action concernant le fonctionnement de l’équipe sont oubliés après quelques jours en règle générale, et jamais rappelés…. L’équipe est démotivée, et il n’y a aucun lead sur le sujet : les experts sont concernés mais trop débordés pour s’en occuper….

Le plan

1. Le Sprint2. Le Stand Up3. Le Sprint Planning4. La Sprint Review5. La rétrospective6. Conclusion

Conclusion

Les valeurs de transparence, d’inspection et d’adaptation doivent rester au centre des préoccupations de l’équipe.

Le but des rituels est de rappeler ces valeurs et de les remettre au coeur du processus du développement à chaque moment clé. Ils n’ont pas de valeur intrinsèque!

Ce que montre l’expérience chez mon client c’est que lorsqu’on cesse de s’adapter, de surveiller, et de communiquer, malgré les rituels, on ne fait pas d’agilité.

Questions

?

[REX] L’agilité au service de l’équipe et du projet

Sommaire

ContextePourquoi changer ?

Agilité vue par l’équipeComment initier le changement ?

De Scrum à ScrumBanQuelles sont les adaptations apportées ?

BilanNos difficultés, nos réussites...

Contexte

ProjetContexte projet

ÉquipeConfiguration de l’équipe

CascadePourquoi changer ?

Projet

Extranet d’une grande entreprise

En place depuis 2003

Fonctionnel complexe

Données confidentielles

Utilisé à l’échelle internationale

Point de communication (clients/internes)

Victime de son succès

Équipe

8 personnes

Équipe polyvalente

Hiérarchie non impliquée

Organisation historique

Interne/Prestataires

Cascade

Au bout de 10 ans …

Manque de réflexion

Dette technique

Manque de communication

Équipe frustrée, sous pression

Échec mal vécu

Des retards de livraisons

Turn over non maîtrisé

CP surbookée et tendue

Agilité vue par l’équipe

AgileLes valeurs

ScrumLes piliers et les pratiques

KanbanLes principes et les pratiques

Agile

Rétrospective

Mobiliser l’équipe

Communication saine

Amélioration continue

Produit

ÉQUIPE

PRODUIT

COLLABORATION

ADAPTATION

Scrum

Pratiques :Sprint planning

Sprint

Stand Up

Sprint review

Sprint retrospective

DOD, Scope, etc…

Trop stricte !

TRANSPARENCE

INSPECTION

ADAPTATION

Kanban

Pratiques :Visualiser les flux

Limiter WIP

Gérer le débit

Expliciter le processus

Boucles de rétroaction

Améliorer la collaboration

Évoluer expérimentalement

Trop souple !

TRAVAIL EN COURS

CHANGEMENT

RESPECTER

LEADERSHIP

De Scrum à ScrumBan

Sprint planningObjectif, mise en place, effet

Sprint

Stand up

Sprint review

Retrospective

Sprint planning 1/3

L’équipe connaît

sa capacité et le but à atteindre

Sprint planning 2/3

Tous les mercredis - Durée : 30 minutes - animée à tour de rôle

Préparation :

Renseignement du temps hors développement

Déroulement :

PO présente les fonctionnalités

Mise à jour des indicateurs de complexités

Chiffrage collectif en jour homme idéal

L’équipe ajoute une à une les “issues” au Sprint

Lancement du sprint

Sprint planning 3/3

Réussites :

Meilleure visibilité et communication

Mise en place de tâches d’analyse

Mise en place de pair programming

Maîtrise des risques et des complexités

Difficultés :

Problème du chiffrage en jour homme

Débordements maîtrisés par le maître du temps

De Scrum à ScrumBan

Sprint planning

SprintObjectif, mise en place, effet

Stand up

Sprint review

Retrospective

Sprint 1/3

L’équipe s’auto-organise

car elle sait ce qu’elle fait

et pourquoi elle le fait !

Sprint 2/3

KANBAN

Expliciter le processus en place

Issues attribuées

DEVIN PROGRESS

TO BE VALIDATED

VALIDATION IN PROGRESS REOPENED DONEOPEN

Cycle de recette croisée

BLOCKED

Sprint 2/3

KANBAN

Gérer les flux

Issues attribuées

DEVIN PROGRESS

TO BE VALIDATED

VALIDATION IN PROGRESS REOPENED DONEOPEN

Cycle de recette croisée

BLOCKED

Issues non

attribuées

Issues non attribuées

(sauf sireopened)

Issues attribuées

Sprint 2/3

KANBAN

Commencer par ce que vous faîtes maintenant

Issues attribuées

DEVIN PROGRESS

TO BE VALIDATED

VALIDATION IN PROGRESS REOPENED DONEOPEN

Cycle de recette croisée

BLOCKED

Issues non

attribuées

Issues non attribuées

(sauf sireopened)

Issues attribuées

- +

+

PRIORITY

PRIO

RIT

Y

Sprint 2/3

KANBAN

Gérer les changements de périmètre

Issues attribuées

DEVIN PROGRESS

TO BE VALIDATED

VALIDATION IN PROGRESS REOPENED DONEOPEN

Cycle de recette croisée

BLOCKED

Issues non

attribuées

Issues non attribuées

(sauf sireopened)

Issues attribuées

- +

+

PRIORITY

PRIO

RIT

Y

Versions Mineures

Version Majeures

Limit WIP

Sprint 3/3

Réussites :

L’équipe est devenue auto-organisée

La CP moins surbookée et donc moins tendue

Meilleure visibilité des flux

Émergence d’une dynamique d’équipe

Difficultés :

Goulots d’étranglements résiduels

De Scrum à ScrumBan

Sprint planning

Sprint

Stand upObjectif, mise en place, effet

Sprint review

Retrospective

Stand up 1/3

Synchronisation de l'équipe et évaluation de l’avancement vers le but de l’itération

Stand up 2/3

Point de vu émergeant :

S'intéresser au travail de l’équipe doit être normal donc

pourquoi en faire une cérémonie ?

Pas de daily standup

Transparence :

Tous les jours, chacun renseigne son temps passé

Board % d’avancement des “issues”

Stand up 3/3

Réussites :

Transparence quant à l’avancement des tâches

Communication informelle mais efficace

Entraide et réduction des dépassements

Difficultés :

Manque d'intérêt de la part de certains membres

De Scrum à ScrumBan

Sprint planning

Sprint

Stand up

Sprint reviewObjectif, mise en place, effet

Retrospective

Sprint review 1/3

Collecter le feedback des parties prenantes !

Sprint review 2/3

Échec

Que faire lorsque la DEMO se transforme en règlement

de compte entre les parties prenantes et les POs ?

Pas de DEMO

Protéger l’équipe

Definition Of Done

Cycle de recette croisée intégrée dans le sprint

Sprint review 3/3

Réussites :

Une équipe moins exposée donc moins stressée

Difficultés :

Une bonne implication mais la perte de l’engagement...

De Scrum à ScrumBan

Sprint planning

Sprint

Stand up

Sprint review

RetrospectiveObjectif, mise en place, effet

Retrospective 1/3

Amélioration continue

via la mise en place de boucles de rétroaction

Retrospective 2/3

Pour nous la rétrospective

se déroulait en deux temps

Retrospective 2/3

Petites boucles de rétroactionAprès chaque sprint avant le sprint planning

Durée : 30 minutes

Déroulement :

● Vérification du temps renseigné par l’équipe

● Point sur la vélocité de l’équipe

● Revue de toutes les “issues”

● Revue des causes de dépassement

● Mise en place d’actions concrètes

Retrospective 2/3

Petites boucles de rétroaction

Réussites :

Refactoring ciblé grâce aux causes de dépassement

Identification des points forts et faibles de chacun

Facilitation du transfert de compétences

Meilleure maîtrise des risques

Difficultés :

Débordements => Timebox 5min/issue

Retrospective 2/3

Grandes boucles de rétroactionTous les 10 sprints

Durée : 2 heures

Préparation individuelle :

● Des indicateurs quantitatifs, qualitatifs, collaboratifs,

temporels et de vélocité

Déroulement collectif :

● Soumission et vote des thèmes soumis

● Revue de chacun des thèmes

● Définition de plans d’actions

Retrospective 2/3

Grandes boucles de rétroaction

Réussites :

Matière à réflexion via des indicateurs factuels

Meilleure capacité à prendre du recul

Meilleure maîtrise des sujets dont on ignore les métriques

Difficultés :

Trop d’indicateurs pour être pleinement exploités...

Retrospective 3/3

Petites boucles de rétroactionAugmenter l’efficacité de l’équipe

Grandes boucles de rétroactionÉviter l'essoufflement de l’équipe

Bilan

ScrumBanDu recueil du besoin à la mise en production

Nos difficultésLe principal danger de l’agilité

Nos réussitesLes bienfaits de l’agilité

A retenirS’il n’y avait qu’une chose à retenir que serait-elle?

ScrumBan

Nos difficultés

Au niveau des individus :

L’agilité met l’humain en avant ce qui peut exacerber les

conflits existants entre les individus !

Les valeurs agiles :

L’équipe doit puiser ses forces dans les valeurs agiles

afin de mettre de coté les conflits en faveur de l’équipe et

du produit !

Nos réussites

Au niveau de l’équipe

● Meilleure intégration des nouveaux

● Veille et refonte technique

● Transfert de compétences

Au niveau du produit

● Livraisons plus fréquentes

● Meilleure vision du fonctionnel

A retenir

Adopter les valeurs agiles !

Adapter continuellement vos pratiques à votre contexte !

Questions

?