Mise à l'échelle : Pourquoi l'alignement organisationnel est essentiel et conseils pour y parvenir

Pour poursuivre la conversation avec Al, veuillez rejoindre et poster des questions au groupe Agile Product Management sur LinkedIn.

Q&A AVEC AL SHALLOWAY

Merci d'avoir posé d'excellentes questions pendant la session en direct ! Voici les réponses d'Al à plusieurs questions que nous n'avons pas pu aborder.

Q : Notre entreprise a récemment publié une offre d'emploi et décrit notre culture comme "...Rapide, en constante évolution et collaborative". J'ai dû m'arrêter et réfléchir - Comment la culture fait-elle que les équipes sont alignées ou désalignées au sein d'une organisation ?

R : La culture peut avoir un impact important sur le fait que l'entreprise récompense ou non les individus et/ou les héros. Si c'est le cas, cela aura tendance à nuire à l'alignement. Mais il faut d'abord comprendre ce qu'est la culture - un reflet des politiques de gestion de l'organisation. Si ce sujet vous intéresse, vous devriez lire Pourquoi ne pas se concentrer sur la culture d'une entreprise.

Q : Comment puis-je susciter l'adhésion à un outil qui nous aide à nous aligner sur le travail, à le prioriser et à le gérer dans toute mon organisation ?

R : Avant de parler de tout outil, il faut comprendre la relation entre l'amélioration d'une organisation et son utilisation des outils. De nombreuses entreprises se jettent sur l'utilisation d'un outil pour résoudre leur problème. Leur logique est la suivante : s'ils parviennent à mettre en place l'outil correctement, les gens suivront ensuite un processus efficace et bien défini. Malheureusement, cela suppose que l'outil fait bien les choses. En réalité, les entreprises doivent d'abord déterminer ce dont elles ont besoin, puis faire en sorte que l'outil réponde à ce besoin. Pour obtenir l'adhésion à un outil, vous devez montrer aux gens comment il créera de la visibilité pour réduire le gaspillage que crée votre processus actuel.

Q : Les membres de l'équipe doivent-ils pouvoir voir ce qui est aligné au niveau du portefeuille ?

R : C'est en fait une chose très importante à faire. C'est possible avec un outil comme Planview AgilePlace, mais la plupart des outils ne sont pas configurés de cette façon.

Q : Comment s'aligner sur les limites du WIP (work-in-process) ?

R : Décidez des limites d'encours par l'expérimentation. Tout d'abord, créez un tableau dans un outil comme Planview AgilePlace qui montre le flux de travail - afin que vous puissiez voir où les choses s'accumulent. Ensuite, fixez votre limite d'encours à ces points - en étant un peu plus petit que ce qu'ils sont maintenant. Si vous finissez par avoir des "bulles" dans votre flux de travail (c'est-à-dire des personnes prêtes mais rien dans leur file d'attente), alors votre limite d'encours est trop basse. Vous serez peut-être intéressé par ce webinaire Planview AgilePlace sur la définition et la gestion des encours.

Q : Mes responsables nous étouffent avec un leadership de type "commandement et contrôle", mais je pense qu'ils seraient plus efficaces pour développer Agile s'ils suivaient une approche de leadership serviteur. Comment puis-je les y amener ?

R : Le leadership serviteur devrait consister à chercher à voir ce qui est nécessaire et à apporter un soutien aux gens. Cela ne signifie pas recevoir des ordres des équipes. Les dirigeants doivent créer l'environnement dans lequel les personnes qui leur rendent des comptes peuvent travailler plus efficacement. Si vous commencez à parler de leadership serviteur à des personnes qui ont historiquement fait du commandement et du contrôle, elles auront probablement l'impression de ne plus avoir leur place et, même si elles en avaient une, de ne pas savoir quoi faire. Vous pourriez trouver ce blog intéressant : The Importance of Leadership and Management In Agile.

Q : Que pensez-vous de SAFe (Scaled Agile Framework) pour développer la méthode Agile au niveau organisationnel ?

R : Nous sommes des partenaires d'or, un contributeur à SAFe et je suis un ancien formateur SPC. Ainsi, parmi les méthodes définies, c'est celle que nous préférons. Ceci étant dit, nous ne l'utilisons pas hors de la boîte, pour ainsi dire. Nous considérons que l'utilisation des MVPs/MBIs est essentielle, et leur importance n'est pas explicitement rappelée dans SAFe. En outre, la décomposition dont nous avons discuté lors du webinaire est différente de l'épopée -> features -> stories de SAFe. Ainsi, lorsque nous faisons SAFe, nous avons tendance à superposer les concepts de gestion de produit abordés dans le webinaire à la méthodologie.

En tant que contributeurs il y a 4 ans à SAFe dans les domaines de ATDD, TDD et Kanban aux services partagés, nous avons tendance à être un peu en avance sur leurs versions annuelles. Ce que je veux dire ici, c'est qu'il faut vraiment utiliser SAFe comme un cadre, en ajoutant et en étendant selon les besoins. Les aspects clés de SAFe que nous apprécions sont qu'il adopte une vue d'ensemble, apprécie le Lean, apprécie la gestion et dispose d'un événement de planification solide qui est nécessaire pour les grandes organisations. Vous pouvez en savoir plus sur l'adaptation et l'extension de SAFe pour répondre à vos besoins ici.

Nous avons une approche alternative à SAFe où nous commençons par un cadre adapté aux besoins de notre client qui incorpore les bonnes choses de SAFe, mais se concentre sur la livraison de la valeur commerciale et la gestion agile des produits. Ce faisant, nous constatons qu'il est plus facile de l'adopter pour une organisation qui souhaite changer. Dans certaines organisations, seule une approche préétablie peut fonctionner, et nous aimons alors utiliser SAFe.

Q : Vous avez mentionné de nombreuses façons d'aborder le développement itératif, telles que Scrum, XP, Lean, SAFe, TDD, ATDD, et conception émergente. Pouvez-vous développer ?

R : Il faudrait un livre pour répondre à cette question, mais laissez-moi vous parler de ce à quoi je considère que chacun de ces outils sert, et comment j'aime les considérer.

• Scrum et XP : Je considère que Scrum est une très bonne approche d'équipe qui a été survendue comme un cadre capable de fonctionner au-delà de l'équipe. Scrum et XP se distinguent principalement l'un de l'autre par le fait que XP intègre des pratiques techniques (telles que TDD, ATDD et la conception émergente) et que Scrum ne le fait pas. Scrum et XP utilisent tous deux les itérations pour construire par étapes.
• TDD et ATDD : TDD permet une meilleure conception, une meilleure qualité du code et des tests automatisés du code d'un point de vue fonctionnel. L'ATDD permet de clarifier les exigences et de définir le comportement souhaité à un niveau élevé et de l'affiner au fil du temps. Pour plus d'informations sur l'ATDD/TDD, consultez le site Built-In Quality with Test-First. Bien qu'il fasse partie de la série de webinaires Tuning SAFe, il est pratiquement indépendant de SAFe lui-même.
• Notre propre approche est ce que nous appelons "l'agilité d'équipe". Bien que nous l'utilisions depuis des années, nous commençons tout juste à rédiger une définition plus formelle. Vous pouvez voir le début de ce ici.

Le Lean est à peu près le fondement de ce que nous faisons chez Net Objectives. Je parle de SAFe dans la réponse à une autre question de ce blog. Vous pouvez obtenir plus d'informations sur SAFe et la conception émergente à la page de ressources de notre webinaire .

DES RESSOURCES SUPPLÉMENTAIRES RÉFÉRENCÉES PENDANT LA SESSION :

• Comprendre le principe du plus court chemin pondéré
• Design Patterns Explained : Une nouvelle perspective sur la conception orientée objet , par Al Shalloway et James R Trott [livre].
• Les principes du flux de développement de produits : Lean Product Development de 2e génération, par Don Reinertsen [livre].
• Pour une liste complète des vidéos et des livres référencés pendant le webinaire, veuillez visiter cette page de ressources Net Objectives.
• Si vous voulez passer une journée à apprendre la gestion agile des produits, participez à un symposium sur la gestion agile des produits de Net Objectives.