Les 4 phases de transformation agile

4 phases de la transition agile sont des patterns que j’ai pu voir émerger les 10 dernières années. Celles-ci peuvent se résumer à la représentation ci-dessus.

Phases of an agile transitionPhase 1: préparer le terrain

Dans les structures actuelles, l’apparence est structurée mais la consistance est tout autre (plus paraître qu’être):

  • pas ou peu de coordination
  • pas ou peu de gestion budgétaire
  • pas ou peu de vision
  • pas ou peu de structure
  • les rôles ne sont pas clairs
  • les interactions entre les acteurs ne sont pas clairs
  • les résultats ne sont pas mesurés
  • l’important c’est le budget et le pouvoir qu’il confère au management
  • le management ne s’intéresse peu ou pas aux opérations (les gens qui créent de la valeur)
L’objectif de la  phase 1 est d’apporter de la structure et de la consistance:
  • livrer à chaque fois même si c’est mal conçu, mal fait, ne correspondant à rien…. simplement livrer.
  • tirer les conclusions de la livraison et corriger le tir.
  • impliquer les participants au projet: les développeurs, le client (le métier), les utilisateurs (les clients du métier), le management.
  • commencer un projet avec un vrai business case (objectif, budget, critères d’acceptation, gouvernance, liste des participants, rôles et responsabilité).
  • dédier une équipe par projet (100 jours/h correspond à 4 semaine de travail pour 5 personnes).
  • si le projet n’est pas qualifié, ne pas le commencer.
  • si le projet n’a pas de client ou d’utilisateurs, ne pas le commencer.
  • si le client n’est pas sponsor, ne pas le commencer.
  • si le projet n’a pas de responsable (project leader, gestionnaire de projet, product owner), ne pas le commencer.
  • si le gestionnaire de projet est un comptable (PMO) ou un chef de chantier (chef de projet), ne pas le commencer.
  • si les risques ne sont pas identifiés, ne pas le commencer.
Résultats:
  • vous augmentez la productivité des équipes de manière magistrale uniquement en apportant de la consistance.
  • les équipes expérimentent l’autonomie et sortent progressivement d’une relation « client-fournisseur » néfaste pour entrer dans une collaboration « partenaire ».

Phase 2 : faire du Scrum

Faire du Scrum n’est pas chose facile car cela nécessite de la rigueur et une sorte de discipline:

  • respect des boîtes de temps
  • respect des personnes
  • les sprints pas perturbés
  • des rôles clairement définis
  • une vision produit (ou projet)
  • des scrum masters formés (c’est quand même eux qui doivent coacher leur équipe)
  • des product owners formés (nommer un AMOA ou un Business Analyst PO ne fait pas de lui un Product Owner)
  • un PO qui ne fait pas les tests d’acceptance (c’est pas son job).
  • des parties prenantes comprennent les règles du jeu « scrum »
  • des mesures de progrès
  • des mesures des empêchements (oubliez vos COPROJ, COPIL, tout est prévu dans scrum)
  • des mesures de gestion des capacités, etc…
  • un Sprint contient l’ensemble des réunions nécessaires pour la conduite d’un développement réussi.
  • toutes réunions non-planifiée est à considérer comme une distraction consommant le budget du projet
  • et, pour finir, une feuille de route claire et transparente
des pièges à éviter:
  • ne pas accepter de changement de fonctionnalité pendant le Sprint.
  • pendant le sprint, les seuls changement acceptables sont ceux détectés par la Development Team.
  • les autres seront pris en compte pour le Sprint suivant.
  • gérer la dette technique ou les bugs. Bien souvent les équipes de développement prennent en charge les bugs issus de leur développement antérieur et c’est bien ainsi. Cependant, cette gestion doit être contrôlée et mesurée de sorte qu’elle n’affecte pas la livraison de l’incrément de produit en fin de Sprint et, celle-ci permettra d’apporter les actions correctrices nécessaire pour éviter de retomber dans un développement de qualité misérable.
  • le cadrage est une affaire d’équipe et cela ne prend pas plus de 4 heures. Si le PO passe des jours et des jours à courir les bureaux et les réunions pour faire plaisir à toutes les parties prenantes, cela prouve seulement que celui-ci n’a pas de vision du produit et qu’il est fort à parier que votre projet sera inconsistent. Au lieu de cela, organisez un atelier avec toutes les parties prenantes y compris l’équipe de développement est planifiez votre premier Sprint. Le reste suivra.
  • Si toutefois, vous n’obtenez pas de résultat (vision, product backlog, roadmap), posez-vous la question s’il est vraiment  nécessaire de faire le projet.
  • portez toute la charge du projet sur les seules épaules du Scrum Master ou du Product Owner est une catastrophe. Un projet en mode Scrum nécessite l’engagement de toutes les parties.
  • donner l’autorité du projet à un architecte ou un Tech Lead donnera un livraison technique. Mettez-vous à la place de votre client qui attend de voir quelque chose, de donner son avis, de partager. Comment pourrait-il le faire devant des diagrammes UML que personne ne lit? La discussion est toujours fonctionnelle car la technique appartient à l’équipe. Celle-ci sait quoi faire et n’a pas à passer son temps à se justifier. Faite simple! Le dernier moment responsable est et sera toujours le code.
  • ne rien livrer est une catastrophe. La livraison permet la discussion avec les utilisateurs. Livrez à chaque Sprint des items « done ».
  • ne pas impliquer les utilisateurs. Trop souvent les équipes se contentent du « métier » comme client sans s’intéresser aux utilisateurs. Un bon exemple sont les User Stories: regardez votre Product Backlog est lisez les User Stories pour voir combien de personae sont disponibles (les personae sont les « en tant que …. ») et assurez vous que chacune dispose d’un représentant de chair-et-de-sang qui sera présent au moins lors des Revues.
  • il n’y a pas de demi-Scrum! Les rôles, les boîtes de temps, les artefacts, la transparence, l’inspection et l’adaptation, un Daily non respecté sont un rythme, une nouvelle routine, vous donnant la possibilité de concrétiser votre développement. Une revue qui est une démonstration où la Scrum Team montre le résultat du temps passé est une injure aux clients. Bref, scrum c’est simple, c’est léger, c’est facile et cela vaut le coup de le faire correctement.
  • avoir différentes équipes travaillant sur le même Product Backlog mais en séquence. Je m’explique: vous avez une équipe qui s’occupe du cadrage pendant un ou plusieurs mois (on peut l’appeler l’équipe PO) qui passe le relai à l’équipe Conception qui prépare toutes les stories, qui passe le relai à l’équipe réalisation (les esclaves en somme). C’est du vécu! et cela n’a rien à voir avec Scrum mais c’est une scrumisation d’une méthode sans nom permettant de consommer du budget sans réaliser quoi que soit!
  • Jira (ou tout autre outil) utilisé pour la transparence. Si vous avez utilisé Jira, vous savez que cet outil est très intéressant et exessivement paramétrable. Cette complexité n’est d’aucune utilité pour assurer une bonne transparence. Et, comme souvent, les données repassent dans Excel pour transformation (du rouge au vert), celles-ci sont souvent inconsistantes. Jira sert à la coordination.
  • pour la transparence rien de mieux que le tableau bien affiché dans l’open space avec des tickets montrant l’avancement, les tâches planifiées (product et sprint backlog, bugs, évolutions, anomalies) et les tâches non-planifiées (qui étonnamment consomment beaucoup de temps de l’équipe et n’apparaissent jamais dans Jira).
Résultats:
  • le tableau rassemble l’ensemble des indicateurs de suivi du projet.
  • Les managers ne viennent plus vous déranger toutes les 5 minutes pour un statut et peuvent passer le voir en temps réel.
  • Les clients viennent vous dire bonjour et voient l’avancement.
  • Le stress retombe peut à peu.
  • les développeurs discutent toute la journée devant les tickets affichés sur le tableau.
  • les daily se passent devant le tableau et on se congratule sur les items « done » de la journée.
  • les demandes inopinées venant de tous les outils de communication convergent vers le Product Owner et ne dérange plus les développeurs.
  • le Scrum Master visualise les goulots d’étranglement et les bloqueurs de l’équipe.
  • Le Product Owner sait dire « non ».
  • on fait des réunions hebdomadaire de priorisation de Business Value avec les clients qui sont contents de comprendre le contexte de développement.
  • des métriques simples de suivis de projet sont mis en place (burndown pour faciliter la négociation des changements pour une livraison à date fixe), l’impédiment backlog qui quantifie la perte de temps sur des activités non prévues.
  • Bref, la Scrum team est structurée, le client (métier) et les utilisateurs sont impliqués, le management met en place le nécessaire pour que les objectifs soient respectés et se chargent de la gestion du risque.

Phase 3: devenir Agile

Comme dans l’approche SHU HA RI, une fois que la discipline est installée on peut commencer par ouvrir ou élargir le cadre:

  • tous les acteurs sont impliqués
  • la distance est réduite (plus de back)
  • les équipes s’autogèrent
  • le management n’est plus indispensable et les décisions sont prises par la base.
  • le recrutement est fait par la base.
  • la direction se concentre sur la stratégie en impliquant les Product Owners et les Scrum Masters
  • le CODIR est organisé en utilisant la gouvernance scrum: le DG ou PDG est PO, la ou le DRH est Scrum Master de l’organisation
  • il n’y a plus de silos fonctionnels, les participants s’organisent en communauté, guildes ou ce que voulez dans le but de transmettre la connaissance acquise et aider leurs collègues à progresser
  • les consultants externes sont utilisés ponctuellement et uniquement à des missions d’expertise et de partage de compétence. (le savoir est dans l’entreprise)
  • la communication est fluide et personne n’a plus peur de faire des erreurs
  • les budgets sont opportunistes et aident le développement de solutions et pas le contraire
  • les rôles et fonctions sont opportunistes en fonction des nouvelles compétences émergentes
  • il n’y a plus personne en mode « survie »
  • l’innovation est permanente
  • l’entreprise est centrée sur son personnel et pas ses clients
  • il n’y a plus de client mais des partenaires
  • on ne parle plus d’agilité. On est agile!

Phase 4: over the fence!

Au delà de la barrière, la structure se réinvente tous les jours et devient agnostique.C’est le RI!

Vous pouvez sauter les étapes si vous voulez. Mais est-ce que les autres le pourront? Est-ce que vos collègues le pourront?

Conclusion

Une transition est une approche par phases. Plus votre structure est importante, plus vos phases sont importantes.

Une transition agile est un changement de culture qui ne peut pas se faire dans la douceur. Comprenez-moi bien, cela ne signifie pas que celle-ci est forcée. Cela signifie qu’il y a beaucoup de résistances à faire tomber de manière respectueuses.

Certains de mes collègues appellent ces résistances un CPU, un programme dormant, j’aime à utiliser la métaphore de l’ADN. Mélanger une démarche pragmatique et une démarche cartésienne nécessite beaucoup de temps, de courage, de persévérance. Il en est de même de l’intégration de concepts asiatiques (Toyota) dans une culture européenne.

Dans son livre « Maverick », Ricardo Semler racontait qu’en cherchant des solutions pour changer la façon de travailler de son entreprise, celui-ci est aller sur le port pour regarder les entreprises japonaises s’organiser. Il a pu assister un matin à une séance de gymnastique collective où tous les employés s’employaient à faire une sorte de Tai Chi. Il s’est dit: « Nous sommes brésiliens, pas japonais. Cela ne marchera pas. Créons notre propre façon de faire! ».

la bise

Pierre

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s