BT

Nouveau Early adopter ou innovator ? InfoQ a travaillé sur de nouvelles fonctionnalités pour vous. En savoir plus

Une véritable mise à l'échelle Agile - Keynote d'ouverture d'Henrik Kniberg à l'Agile Tour Bangkok

| par Shane Hastie Suivre 11 Abonnés , traduit par Olivier My Suivre 0 Abonnés le 09 déc. 2015. Durée de lecture estimée: 4 minutes |

Henrik Kniberg, auteur du Minibook InfoQ “Scrum and XP from the Trenches”, a donné la keynote d'ouverture de la conférence Agile Tour Bangkok en novembre dernier en Thaïlande. Son sujet était intitulé "Une véritable mise à l'échelle Agile".

Il a commencé par affirmer que nous savons comment appliquer les techniques agiles au niveau de l'équipe individuelle, ainsi qu'au niveau de plusieurs équipes travaillant ensemble. Aller au-delà pour pouvoir appliquer un grand nombre d'équipes à un problème/une initiative unique est bien plus difficile et est fréquemment très mal fait.

Il a exploré ce que "la mise à l'échelle agile" signifiait vraiment et a challengé le besoin des organisations à se mettre à l'échelle - cela est souvent entrepris sans compréhension du pourquoi et des impacts éventuels de la mise à l'échelle. Il a présenté l'image suivante des risques et coûts potentiels de la mise à l'échelle :

Il dit qu'il y a trois éléments qui ont besoin d'être compris pour mettre à l'échelle de manière efficace :

  • Comment "découper l'éléphant"
  • Les structures d'équipe
  • Les boucles de feedback
  • Comment garder les équipes synchronisées et alignées
  • Comment s'attaquer aux dépendances entre équipes

Se tromper sur ces éléments entraîne des résultats loin d'être optimaux, et mène souvent au désastre.

Adressant la question du "Découpage de l'Eléphant", il a challengé le concept de MVP (minimum viable product) et a suggéré d'utiliser une séquence de Produit testable/utilisable/aimable au plus tôt à la place, comme montré dans cette image :

Sur le challenge de la structure d'équipe, il a déclaré que les feature teams étaient meilleures que les component teams, mais qu'il y avait un risque de nouveaux silos se formant autour des feature teams. Donc, un mode hybride combinant des feature teams avec certains aspects des component teams serait souvent nécessaire dans des organisations avec des tas de technologies, grosses et complexes.

C'est également une approche pour aider à réduire l'impact des dépendances entre équipes, où les équipes concentrées sur les activités internes traitent le client en contact avec les équipes comme leurs clients. Cette "équipe plateforme" responsabilise les équipes et change l'approche de gestion des dépendances avec un couplage lâche et un alignement étroit entre les équipes.

Il a présenté quelques directives pour la formation d'équipe :

  • Les équipes devraient être de 3-9 personnes
  • Les équipes devraient être relativement stables, à plein temps et colocalisées
  • Les équipes ont besoin d'une mission claire autour de laquelle s'aligner
  • Elles devraient avoir un bon champ de vision de leurs clients (internes ou externes)
  • Elles ont besoin de moyens pour prioriser les demandes client - cela pourrait être un rôle de Product Owner ou de directives stratégiques claires de prise de décision
  • Les équipes ont besoin d'être polyvalentes et d'avoir toutes les compétences nécessaires pour produire de la valeur à leurs clients
  • Les équipes devraient être autonomes pour ne pas être bloquées à attendre d'autres équipes ou individus.

La mise à l'échelle nécessite l'implémentation de boucles de feedback additionnelles. Les boucles de feedback au niveau équipe sont bien comprises et construites dans les processus agiles (intégration continue, réunions quotidiennes, planification d'itération, rétrospectives, démonstration...). Pour mettre à l'échelle au-delà d'équipes individuelles, il y a un besoin d'ajouter des boucles de feedback supplémentaires :

Ces boucles de feedback supplémentaires nécessitent une synchronisation entre équipes. Cela peut prendre la forme de réunions quotidiennes de synchronisation (comme les Scrums de Scrum), des démos hebdomadaires, des événements mensuels de planification dans une grande salle, etc. D'une manière ou d'une autre, les équipes ont besoin de se rencontrer régulièrement pour résoudre les dépendances, évaluer le produit intégré, mettre à jour les plans, et prendre des décisions. Cela devient plus facile si toutes les équipes ont les mêmes longueurs d'itération.

Il a déclaré que l'Intégration Continue est absolument critique pour garder le travail des équipes multiples à une haute qualité et pour rendre visible immédiatement les dépendances. La Livraison Continue est utile, mais pas obligatoire, c'est une extension qui permet un feedback rapide du client.

Il expliqua que dans les larges adoptions agiles, le rôle du leadership était vital au succès. Indépendamment du nom donné au rôle, il y a besoin d'avoir du leadership et une direction autour de la technologie, du produit et de la conception. Les leaders créent des environnements où l'autonomie alignée peut être atteinte.

Il a résumé avec un rappel que l'agilité est un continuum et un voyage continu, pas une destination. Trouver le "sweet spot" de la planification et de l'architecture suffisante est primordial pour une adoption agile réussie, à tout niveau de mise à l'échelle.

Il a résumé son propos avec les points suivants :

La véritable mise à l'échelle agile - A emporter

  • Mettre à l'échelle fait mal
    Gardez les choses aussi petites que possible
  • L'agilité est un moyen, pas un objectif
    N'allez pas dans l'Agilité en mode Jihad. Ne jetez pas les pratiques qui marchent
  • Il n'y a pas de "bonne" ou "mauvaise" façon
    Que des compromis
  • Il n'existe pas d'approche unique
    Mais plein de bonnes pratiques
  • Construisez des boucles de feedback à tous les niveaux
    Qui vous donneront de meilleurs produits et une organisation qui s'auto-améliore

Evaluer cet article

Pertinence
Style

Bonjour étranger!

Vous devez créer un compte InfoQ ou cliquez sur pour déposer des commentaires. Mais il y a bien d'autres avantages à s'enregistrer.

Tirez le meilleur d'InfoQ

Donnez-nous votre avis

Html autorisé: a,b,br,blockquote,i,li,pre,u,ul,p

M'envoyer un email pour toute réponse à l'un de mes messages dans ce sujet
Commentaires de la Communauté

Html autorisé: a,b,br,blockquote,i,li,pre,u,ul,p

M'envoyer un email pour toute réponse à l'un de mes messages dans ce sujet

Html autorisé: a,b,br,blockquote,i,li,pre,u,ul,p

M'envoyer un email pour toute réponse à l'un de mes messages dans ce sujet

Discuter

Se connecter à InfoQ pour interagir sur ce qui vous importe le plus.


Récupérer votre mot de passe

Follow

Suivre vos sujets et éditeurs favoris

Bref aperçu des points saillants de l'industrie et sur le site.

Like

More signal, less noise

Créez votre propre flux en choisissant les sujets que vous souhaitez lire et les éditeurs dont vous désirez suivre les nouvelles.

Notifications

Restez à jour

Paramétrez vos notifications et ne ratez pas le contenu qui vous importe

BT