Catégories: JIRA

Votre entreprise est un écosystème de services interdépendants avec un système adaptatif complexe. 

Un tas de compagnies ont commencé leur voyage d’augmenter leur agilité avec Scrum. Cela n’a pas résolu tous leurs problèmes. Le Kanban permet aux organisations de faire évoluer leurs systèmes de prestation de services vers une agilité commerciale mature. 

Comme indiqué dans How Kanban Saved Agile, le Scrum pur est extrêmement rare. Scrumbut (étiquette dénigrante qui a été engendrée par de nombreuses organisations rapportant qu’ils font du Scrum, sans pour autant respecter les normes …) d’autre part, est extrêmement commun.

Pour ne pas être qualifié de Scrumbut, votre entreprise a besoin de :

+ Equipe de développement interfonctionnel de 7 +/- 2 personnes – TOUTES les compétences requises pour livrer des projets sont présentes dans l’équipe – il n’y a pas de dépendance externe à l’équipe;  

+ Une source de demande sans contraintes de capacité: le Product Owner est le client ET membre à temps plein de l’équipe;

+ Les sprints durent un mois ou moins, commencent par le démarrage d’une nouvelle demande du propriétaire du produit et se terminent par la livraison d’augmentations de produit potentiellement livrables, suivies d’une rétrospective sur la façon de faire le meilleur sprint suivant;

+ «Potentiellement livrable» signifie que la décision de savoir si la livraison  est réellement une décision des affaires. Tout le travail technique est fait;  

+ Si tout le travail technique requis pour livrer n’est pas fait, alors le Sprint est un Sprint échoué;

+ Le Scrum Master est un leader serviteur et un éducateur Scrum pour toute l’organisation. 
 

Combien d’organisations connaissez-vous avec les équipes Scrum qui répondent à toutes les exigences ci-dessus? Je n’en connais pas. 
 
Alors, quelle est la solution? Abandonner le Scrum? Sommes-nous toujours en train d’obtenir des avantages du Scrumbut? Reconnaissons ce qui se passe vraiment avec de vraies équipes dans le monde réel et appelons cela Scrum. Reportons-nous à la check-list ci-dessus comme « Scrum idéal ». 

 
Voici quelques raisons expliquant pourquoi ajouter des couches de dimensionnement Agile autour des équipes :

+ Les équipes ne sont pas entièrement inter fonctionnelles;
 
+ Les équipes ont des dépendances externes et opaques;  

+ Un grand nombre de ces dépendances sont des services partagés avec de multiples sources de demande et des capacités limitées – souvent surchargées;  

+ Les dépendances externes peuvent être d’autres équipes-la demande des autres équipes apparaît dans leur carnet de commandes, priorisé par leurs propres propriétaires de produits;

+ De nombreuses dépendances ne jouent pas du tout les mêmes règles: certaines résident dans une autre partie de l’organisation, avec des structures et des forces politiques différentes;  

+ Les Product owner représentent un éventail de multiples sources de demande, avec des attentes de niveau de service, des origines stratégiques, un degré de clarté, une urgence et des forces politiques différents qui les poussent vers l’organisation de livraison;  

+ Les backlogs produits sont principalement constitués de solutions définies par les parties prenantes et traduites par les pseudo-Product Owner en pseudo-user stories – comment ils y arrivent est opaque, le «floue front end» – et quelque part ici un engagement de livraison floue était déjà fabriqué;  

+ Le travail d’un sprint comprend tout le travail que peuvent accomplir les équipes non inter fonctionnelles – alors que toutes les équipes sont «exécutées», elles sont livrées à un groupe d’équipes ou à des étapes de processus assez bien défini au niveau organisationnel mais en dehors de l’influence des équipes);  

+ Les décisions de livraison sont prises en fonction des contraintes imposées par la technologie, les systèmes et leurs porteurs (pour des raisons historiquement bonnes);  

+ Les équipes sont «faites» à la fin de chaque Sprint, mais beaucoup de travail reste à faire avant que leur travail «fait» soit potentiellement livrable;  

+ Les Scrum Master sont tenus collectivement responsables des livrables collectifs des équipes et de leur capacité à coordonner et à intégrer l’équipe – la responsabilisation par le comité se traduit par le fait que personne n’est réellement responsable. Les cadres intermédiaires se démènent pour ramasser les pièces parce qu’ils sont réellement responsables des résultats livrés. 

De manière générale, les méthodes de dimensionnement Agile visent à appliquer des enveloppes Agiles plus grandes autour de grappes d’équipes Agiles afin de rétablir une certaine structure hiérarchique nécessaire pour gérer les interdépendances décrites ci-dessus. Qu’il s’agisse d’un train de lancement ou d’un Nexus, ou autre chose, l’idée est qu’il existe une «équipe d’équipes agile» qui gère les interdépendances de plusieurs équipes plus petites. Tant que le nombre total de personnes ne dépasse pas le nombre de Dunbar (~ 150), le groupe de Dunbar est dédié et inter fonctionnel, il y a une équipe gérant les interdépendances dans le groupe de Dunbar, il n’y a pas de dépendances en dehors du groupe et il y a une certaine cadence (1-3 mois) de livraison intégrée – c’est toujours « Agile ». Tout cela jusqu’à ce qu’un groupe Dunbar (et seulement jusqu’à présent) permette à l’entreprise de rester «Agile» – Agile dimensionné. Tout cela est censé être plus réaliste que le Scrum idéal (avec peut-être une superposition de Scrum de Scrums et Scrum de Scrum de Scrums). Ça ne l’est pas. Combien d’organisations connaissez-vous qui peuvent se permettre d’avoir ~ 150 personnes 100% dédiées à un seul produit?  

Comment le Kanban règle-t-il ce problème? Votre entreprise est un système adaptatif complexe. Vous y introduisez un système Kanban tel qu’il est probable que le système adaptatif complexe soit stimulé pour s’améliorer. L’approche de la pensée systémique pour introduire le Kanban est pourrait avoir du succès: 

1. Comprenez le but du système – identifiez explicitement les services que vous fournissez, à qui vous les fournissez et pourquoi; 
2. Comprendre les choses au sujet de la prestation de service dont les gens ne sont pas satisfaits aujourd’hui – à la fois ceux dont les besoins sont traités par le service et ceux qui font le travail de prestation de service; 
3. Définir les sources de la demande – ce dont vos clients se soucient et pourquoi; 
4. Décrivez la capacité de votre système à satisfaire ces exigences; 
5. Cartographier le flux de travail des éléments de valeur reconnaissable par le client, en commençant par un besoin connu du client et en terminant par le besoin de franchir les étapes de la découverte des connaissances primaires (équipes Scrum quelque part au milieu, vers la fin) , ne pas boucler les flux de valeurs; 
6. Découvrez les classes de service – il existe des schémas sur la façon dont les différents types de travail circulent dans votre système (ils ne sont pas arbitrairement décidés par les pseudo-Product Owners), quels sont-ils? Regroupez-les, ce sont des classes de services et leur connaissance permet une gestion des risques puissante; 
7. Avec tout ce qui précède en tant qu’entrée, concevez le système Kanban pour le service; 
8. Apprenez à faire les étapes 2 à 7 et commencez à l’appliquer directement à votre propre contexte dans une classe Kanban System Design; 
9. Socialiser et déployer (apprendre en participant à une masterclass de coaching professionnel Kanban); 

< li>Mettre en place des cadences de rétroaction en boucle pour une évolution continue: apprenez les 7 cadences kanban et commencez à appliquer à votre propre contexte dans une classe de professionnels de la gestion Kanban; 

10. Répétez l’opération avec tous les services interdépendants de votre organisation.  

Certains outils informatiques existent pour matérialiser les tableaux de Kanban. C’est le cas par exemple de JIRA un produit Atlassian. 

Pour savoir comment kanbaniser son projet avec JIRA vous pouvez consulter l’article suivant … 

Pour les Agilistes qui ont lu jusqu’ici et ne comprennent toujours pas, vous pouvez lire: 
 
14 choses que tout agiliste devrait savoir sur Kanban de Travis Birch : 

1. La méthode Kanban ne concerne pas la transformation. Du moins pas la marque radicale et profonde de transformation Satir J-Curve qui a été tentée dans de nombreuses organisations. Trop souvent avec l’approche radicale, il y a suffisamment de résistance au changement et suffisamment de chaos pour que les dirigeants de l’organisation perdent patience face à l’initiative de changement avant que le système ait une chance de se rétablir.  
2. En outre (et dangereusement), beaucoup de soi-disant champions du changement ne sont pas conscients que Satir était un psychothérapeute et que sa méthode J-Curve a été employée pour changer l’identité de ses clients, les briser et les reconstruire. Ce qui est important ici, c’est que Satir était un professionnel de la psychologie travaillant avec des clients volontaires pour les aider à se transformer en les gens qu’ils voulaient être. Ce n’est pas le cas de la plupart des professionnels du savoir. Les travailleurs du savoir ont tendance à ne pas rechercher ce type de service auprès des gestionnaires et des entraîneurs. Une version plus brutale de cette technique a été employée pour transformer les adolescents en soldats mortels.  
3. Au lieu de la transformation profonde de la courbe J, la méthode Kanban propose de petites expériences rapides en courbe J. Cette approche du changement provoque moins de résistance, évite les périodes prolongées de raclée dans le chaos et les tests sévères de la patience du leadership. Les petites expériences en J-Curve bien conçues produisent juste assez de stress organisationnel pour stimuler le changement sans tomber dans le chaos profond et le désespoir et forcer la régression d’une organisation à des niveaux inférieurs de confiance et de maturité.  
4. La méthode Kanban est un système de gestion pour la conception et l’évolution des services interdépendants d’une organisation. Ces services sont souvent composés de plusieurs équipes Scrum, de services partagés, de gestionnaires, de cadres supérieurs et de spécialistes et sont souvent eux-mêmes desservis par d’autres services. Chaque service est livré via un système d’étapes de découverte des connaissances (plutôt que de transfert). Voyez plus ici.  
5. La conception d’un système détermine l’aptitude à l’emploi, le flux de valeur et la qualité du service (comme le démontre l’expérience Red Bead de Deming). Il ne s’agit pas d’équipes performantes. Il s’agit de la performance du système.  
6. La transparence du système permet aux travailleurs du savoir de s’auto-organiser autour du travail parce qu’ils comprennent le système et ont la certitude de savoir quoi faire pour fournir le service. 
7. Les gestionnaires Kanban sont des gestionnaires de systèmes, pas des gestionnaires de personnes et non des coachs. 
    
8. Le Kanban au niveau de l’équipe est en fait une forme de kanban proto-kanban encore, mais à l’état immature, un rendu incomplet d’un système de prestation de services. 
    
9. Un système Kanban est un système de traction. La capacité du système est calibrée pour un débit optimal. De nouveaux travaux entrent dans le système lorsqu’il y a une capacité suffisante pour absorber le nouveau travail sans surcharger le système et perturber le flux. La demande est équilibrée par rapport à la capacité. 
    
10. Toute demande est potentiellement réfutable. Lorsqu’il y a une capacité dans le système à commencer de nouveaux travaux, les sources de la demande collaborent pour déterminer quel est le travail le plus important à commencer et le système est réapprovisionné. 
11.  
    Décider de la marche à suivre est basé sur une évaluation des risques économique et transparente. 
     
12. Une fois que le système est réapprovisionné et qu’il existe un engagement à fournir le travail nouvellement commencé, les risques sont gérés avec des politiques explicites telles que les classes de service, les limites de work-in-process, les critères de pull-readiness, les boucles de rétroaction et les métriques pertinentes vitesse d’équipe). 
     
13. Le délai moyen d’exécution du projet ou de la fonction jusqu’à l’achèvement est une mesure de base. L’amélioration du système entraîne une réduction à la fois du délai et de la variabilité du délai. Les prévisions de livraison sont basées sur des données de délais historiques. Les délais sont également gérés avec des données de délai (c’est-à-dire décider quand commencer quelque chose). 
     
14. Tout ce qui précède est la responsabilité de la direction. Cela devrait laisser peu de capacité de gestion pour surveiller la performance individuelle et la vitesse du point de l’histoire des équipes (nombre de billes blanches). Un signe d’un système kanban mûr est que les gestionnaires ont amélioré leur comportement et sont axés sur l’amélioration du système et que les travailleurs du savoir sont libres de s’organiser autour du travail en tant que professionnels adultes qualifiés.