La Livraison Agile Disciplinée (Diciplined Agile Delivery – DAD) : leadership, compléments sur les Rôles et personnalisation

Le Leadership

• Les trois rôles de leadership
  • Nous nous référons souvent au chef d’équipe (Team Lead), au propriétaire du produit (Product Owner – PO) et au propriétaire de l’architecture (Architecture Owner – AO) en tant que triumvirat de leadership de l’équipe.
  • Voir figure 4.4 Points de vue sur les trois rôles de leadership page 67
  • Le propriétaire du produit se concentre sur la construction du bon produit, le propriétaire de l’architecture sur la construction correcte du produit et le chef d’équipe sur sa construction rapide.
  • Ces trois priorités doivent être équilibrées grâce à une collaboration étroite entre les personnes occupant ces 3 rôles.
• Lorsque les équipes sont novices en matière d’agilité, la place centrale peut s’avérer assez petite au début, mais au fil du temps, les personnes occupant ces trois rôles de leadership, et plus important encore l’ensemble de l’équipe elle-même, aideront à la développer.
• Avons-nous vraiment besoin des rôles Scrum ?
  • Dans les années 1990, quand Scrum a été créé, c’était un monde différent.
    • Nous étions habitués à travailler dans des silos spécialisés, à créer des logiciels à partir de documents, et nous ne savions pas vraiment comment et quand collaborer, d’où la nécessité pour un scrum master de rassembler de force les membres de l’équipe, les unifiant derrière un objectif d’équipe.
  • De nos jours, de nombreux jeunes développeurs n’ont jamais travaillé dans un environnement cloisonné.
    • Ils n’ont pas besoin d’un rôle désigné au sein de l’équipe pour garantir une collaboration efficace.
  • De même, pourquoi avons-nous besoin d’un Product Owner formel entre l’équipe et le reste de nos parties prenantes ?
    • Ce degré de séparation augmente les risques de malentendus et limite les possibilités des équipes de développer de l’empathie pour les personnes pour lesquelles elles construisent la solution.
  • Aux débuts de Scrum, il était difficile d’avoir accès aux parties prenantes, c’est pourquoi le Product Owner “obligatoire” a été créé.
    • Il est plus communément admis de nos jours d’avoir un accès direct à toutes les parties prenantes et, espérons-le, une participation active des parties prenantes.
• Dans Agile Discipliné (Disciplined Agile), nous devons constamment rappeler aux équipes que le contexte compte et que le choix est bon.
  • Comme tout dans DA, les rôles que nous décrivons sont de “bonnes idées” qui peuvent ou non avoir du sens pour vous.
  • Dans l’objectif du processus “Former une équipe”, nous vous encourageons à considérer les rôles qui ont du sens pour votre équipe.
    • Si vous êtes novice en matière d’agilité et qu’il y a peu de résistance organisationnelle au changement, alors vous voudrez probablement adopter les rôles DAD classiques.
    • Si votre maturité et vos capacités agiles sont plus avancées, ou si l’adoption de nouveaux rôles serait trop perturbatrice, vous souhaiterez peut-être adapter les rôles en conséquence.

Adaptation des Rôles

• Adapter les rôles de l’équipe DAD à votre organisation
  • Comme nous l’avons mentionné précédemment, vous construisez vos équipes à partir des personnes que vous avez à disposition.
  • De nombreuses organisations constatent qu’elles ne peuvent pas doter certains des rôles, ou que certains des rôles DAD ne correspondent tout simplement pas bien à leur culture existante.
    • En conséquence, ils trouvent qu’ils doivent adapter les rôles pour refléter la situation dans laquelle ils se trouvent.
    • L’adaptation des rôles peut s’avérer être une pente dangereuse car nous avons constaté que les rôles DAD fonctionnent très bien dans la pratique, de sorte que toute personnalisation que vous faites augmente probablement le risque encouru par l’équipe.
    • Le tableau 4.1 présente les options d’adaptation pour les rôles principaux et les risques associés.
• DAD et rôles traditionnels
  • Les puristes agiles
    • De nombreux puristes agiles insisteront pour que les rôles traditionnels tels que chef de projet, analyste commercial (BA), gestionnaire de ressources et bien d’autres disparaissent avec agile.
      • Bien que cela puisse arriver à long terme, ce n’est pas pratique à court terme.
      • L’élimination des rôles traditionnels au début de votre transformation agile est révolutionnaire et se traduit souvent par une résistance à l’adoption agile et sape celle-ci.
    • Nous privilégions une approche plus évolutive, moins disruptive, respectueuse des personnes et de leurs aspirations professionnelles.
      • Alors que l’agilité nécessite différentes manières de travailler, les compétences et la rigueur des spécialités traditionnelles sont toujours extrêmement précieuses.
      • Les chefs de projet comprennent la gestion des risques, les stratégies d’estimation et la planification des versions.
      • Les analystes commerciaux de formation classique ou certifiés apportent une riche boîte à outils d’options de modélisation (dont beaucoup sont décrites dans l’objectif “Explorer la portée”).
      • Dire que nous n’avons pas besoin de chefs de projet ou d’analystes d’affaires est une vision myope, naïve et irrespectueuse envers ces professions.
• Rôles DAD
  • Cela dit, les principaux rôles DAD sont extrêmement efficaces dans la pratique.
    • Lorsque nous travaillons avec des organisations pour améliorer leur façon de travailler (Way of Working – WoW), nous aidons autant de personnes que possible à passer de leurs rôles traditionnels existants à des rôles DAD, qu’ils trouvent souvent plus épanouissants dans la pratique.
      • La figure 4.5 illustre les options courantes pour plusieurs rôles traditionnels.
    • Ce que nous montrons, ce sont des généralisations, et il est important de reconnaître que les gens choisiront leur propre cheminement de carrière en fonction de leurs propres préférences et désirs – tout le monde a des options de carrière en agile.
  • L’important est de reconnaître que chacun peut trouver sa place dans une organisation agile s’il est prêt à apprendre une nouvelle façon de travailler (WoW) et à évoluer vers de nouveaux rôles.

Options de personnalisation pour les rôles principaux

• Pour les différentes options possibles voir page 69
• Options de personnalisation
  • Propriétaire de l’architecture (AO)
    • Architecte applications/solutions.
    • Un architecte traditionnel ne travaille pas de manière aussi collaborative qu’un propriétaire d’architecture, il court donc le risque de voir sa vision mal comprise ou ignorée par l’équipe.
    • Aucun propriétaire d’architecture.
    • Sans quelqu’un dans le rôle de propriétaire de l’architecture, l’équipe doit collaborer activement pour identifier une stratégie architecturale par elle-même, ce qui a tendance à faire en sorte que l’équipe manque des préoccupations architecturales et en paie le prix plus tard dans le cycle de vie avec une augmentation des retouches.
  • Propriétaire du produit (PO)
    • Analyste d’affaires.
      • Les analystes commerciaux n’ont généralement pas le pouvoir de décision d’un propriétaire de produit, ils deviennent donc un goulet d’étranglement lorsque l’équipe a besoin de prendre une décision rapidement.
      • Les analystes métier ont également tendance à privilégier la production de la documentation des exigences plutôt que la collaboration directe avec les membres de l’équipe.
  • Parties prenantes et Membres de l’équipe
    • Participation active des parties prenantes.
    • Les membres de l’équipe travaillent directement avec les parties prenantes pour comprendre leurs besoins et obtenir des commentaires sur leur travail.
    • L’équipe aura besoin d’un moyen d’identifier et de travailler sur une vision cohérente, sinon elle risque d’être tirée dans plusieurs directions.
  • Partie prenante
    • Personas.
      • Bien qu’il y ait toujours des parties prenantes, vous n’y avez peut-être pas accès, ou plus précisément, vous n’avez pas accès à l’ensemble de celles-ci.
      • Les personas sont des personnages fictifs qui représentent des classes de parties prenantes.
      • Les personas permettent à l’équipe de parler en termes de ces personnes fictives et d’explorer comment ces personnes interagiraient avec la solution.
• Chef d’équipe
  • Maître de mêlée (Scrum Master).
    • Nous avons eu des résultats mitigés avec les scrum masters dans les équipes, principalement parce que la désignation Certified Scrum Master® (CSM) nécessite très peu d’efforts pour l’obtenir.
    • Par conséquent, nous vous suggérons de confier ce rôle à un scrum master senior qualifié, et pas seulement à un CSM.
  • Chef de projet.
    • En attribuant du travail à des personnes puis en les surveillant, un chef de projet annulera la capacité d’une équipe à bénéficier de l’auto-organisation et diminuera très probablement la sécurité psychologique de l’équipe.
    • Cela dit, un pourcentage important de chefs de projet sont disposés et capables d’abandonner les stratégies de commandement et de contrôle au profit d’une approche de servant leadership.
  • Pas de chef d’équipe.
    • Nous avons vu des équipes véritablement auto-organisées qui n’ont pas besoin d’un chef d’équipe.
    • Il y a toujours eu des équipes qui travaillent ensemble depuis longtemps où les gens choisissent de s’occuper de ce qui serait normalement des responsabilités de chef d’équipe selon les besoins, comme tout autre type de travail.
• Membre de l’équipe
• Spécialistes.
  • Comme nous l’avons dit plus tôt, si vous n’avez que des spécialistes, c’est à partir de cela que vous construisez votre équipe.
• Figure 4.5 Transitions courantes des rôles traditionnels aux rôles DAD p70

En résumé

• DAD définit cinq rôles principaux (chef d’équipe, propriétaire du produit, membre de l’équipe, propriétaire de l’architecture et partie prenante) qui apparaissent dans toutes les équipes.
  • Dans de nombreuses situations, les équipes s’appuieront sur des personnes occupant des rôles de soutien (spécialistes, experts du domaine, experts techniques, testeurs indépendants ou intégrateurs) selon les besoins et selon les besoins.
  • Les rôles de DAD sont censés être, comme tout le reste, un point de départ suggéré.
    • Vous pouvez avoir des raisons valables d’adapter les rôles à votre organisation.
  • Avec les rôles, comme pour tout le reste, faites de votre mieux dans la situation à laquelle vous êtes confronté et efforcez-vous de vous améliorer avec le temps.

Article suivant

• Agile Discipliné (Diciplined Agile – DA) : Objectifs de processus, vue d’ensemble

Articles précédents

• La Livraison Agile Disciplinée (Disciplined Agile Delivery – DAD) en bref
• La Livraison Agile Disciplinée (Diciplined Agile Delivery – DAD : les Rôles principaux / Partie prenante
• La Livraison Agile Disciplinée (Diciplined Agile Delivery – DAD : les Rôles principaux / Propriétaire du Produit (Product Owner – PO)
• La Livraison Agile Disciplinée (Diciplined Agile Delivery – DAD) : les Rôles principaux / Membre de l’équipe (Team Member)
• La Livraison Agile Disciplinée (Diciplined Agile Delivery – DAD : les Rôles principaux / Chef d’équipe (Team Lead)
• La Livraison Agile Disciplinée (Diciplined Agile Delivery – DAD : les Rôles principaux / Propriétaire de l’architecture (Architecture Owner – AO)
• La Livraison Agile Disciplinée (Diciplined Agile Delivery – DAD : les Rôles de soutien potentiels

Article général

• Agile Discipliné (Disciplined Agile – DA)

Créé le 25/12/2022.