Comment les architectes peuvent-ils travailler avec des équipes Scrum auto-organisées?

Une organisation avec un certain nombre d'équipes Scrum agiles dispose également d'un petit groupe de personnes nommées «architectes d'entreprise». Le groupe EA agit en tant que contrôle et gardien de la qualité et du respect des décisions. Cela conduit à des chevauchements entre la décision d'équipe et les décisions d'EE.

Par exemple, l'équipe peut vouloir utiliser la bibliothèque X ou utiliser REST au lieu de SOAP, mais l'EA n'approuve pas cela.

Maintenant, cela peut entraîner de la frustration lorsque les décisions de l'équipe sont annulées. Pris assez loin, cela peut potentiellement conduire à une situation où le peuple EA "prend" tout le pouvoir et l'équipe finit par se sentir démotivée et pas très agile du tout.

Les guides Scrum ont ceci à dire à ce sujet:

Auto-organisation: personne (pas même le Scrum Master) ne dit à l'équipe de développement comment transformer le backlog de produit en incréments de fonctionnalités potentiellement libérables.

Est-ce raisonnable? Faut-il dissoudre l'équipe EA? Les équipes doivent-elles refuser ou simplement se conformer?

Une équipe de développement est composée de 3 à 9 personnes aux compétences transversales qui effectuent le travail réel

Scrum Master devrait inviter "Enterprise Architect" à faire partie de l'équipe de projet. La communication entre l'architecte et les programmeurs serait alors excellente.

Le choix de la technologie utilisée fait partie des exigences du logiciel, ce qui signifie que cela fait partie de la demande de fonctionnalité que vous n'utilisez pas certaines technologies, quelle qu'en soit la raison.

Les architectes parlent pour les systèmes et la base de code parce que les systèmes et la base de code ne peuvent pas parler d'eux-mêmes. Avoir un architecte est généralement dans l'intérêt à long terme d'une entreprise, en particulier celle qui s'appuie sur un logiciel qui est construit en interne.

Les architectes ne disent pas aux développeurs comment transformer l'arriéré en incréments (sprints), ils disent quelles technologies peuvent et ne peuvent pas être utilisées. Vous confondez deux problèmes différents.

La solution est de ne rien changer. Si vos équipes sont frustrées parce que les architectes sont trop restrictifs ou trop autoritaires, c'est un problème de personnel qui n'a rien à voir avec SCRUM et devrait être abordé avec les parties prenantes de l'entreprise comme un problème de satisfaction des employés et, si possible, le résultat net ("Il nous faut x%plus de temps pour développer des fonctionnalités ycar l'architecte zne nous laissera pas utiliser Turbo Pascal.")

Ce genre de chose est nécessaire pour maintenir l'équilibre entre le besoin d'une grande équipe pour mener à bien le projet et la nécessité de garder des équipes agiles petites.

Généralement, la «mêlée de chefs d'équipe» est composée d'un membre élu dans chacune des petites équipes. Cela donne une certaine nature d'auto-organisation, ainsi qu'une certaine forme de représentation afin que les décisions prises par le groupe de haut niveau soient acceptées par le groupe agile.

Pour votre scénario particulier, quelque chose devrait être fait pour arrêter la démotivation de l'équipe agile, mais probablement pas une rébellion ou une simple acceptation. L'équipe doit se rendre compte que vous êtes là pour créer de bons logiciels, pas pour vous plier aux idéaux. Avoir un tas d'équipes différentes utilisant chacune des technologies différentes pour faire des choses similaires dans le même projet va conduire à un pire logiciel. Avoir un tas d'équipes différentes utilisant des normes de codage différentes dans le même projet va conduire à un logiciel pire.

Vous aurez donc besoin d' un moyen de parvenir à un consensus sur la façon dont le projet va fonctionner. La mêlée de chef d'équipe est utilisée à d'autres endroits de manière efficace. Vous devrez peut-être faire quelque chose différemment ou chercher à savoir pourquoi votre groupe ne le fait pas efficacement.

La question est: Quelle est la raison pour laquelle cette équipe d'architectes existe? La seule raison pour laquelle je peux penser est d'imposer l'interopérabilité entre les différentes équipes. Ou les équipes travaillent sur différentes parties d'un seul produit et cette équipe d'architectes existe pour que chaque partie fonctionne ensemble.

Je ne pense vraiment pas que ce schéma puisse bien fonctionner dans un environnement agile, pour les raisons exactes que vous dites. Les différentes équipes devraient être autonomes, de même que leurs entrées et sorties. Donc, contraindre leurs sorties ne devrait faire partie que des exigences d'entrée. Mais ces contraintes doivent être raisonnables. Quelque chose comme "Ne pas utiliser la bibliothèque X" n'est pas une bonne exigence, mais dire "Doit limiter le nombre de bibliothèques tierces utilisées au minimum" ou "Ajouter de nouvelles bibliothèques, qui ne sont pas utilisées dans d'autres équipes, devrait être limité." devrait être bien.

Ensuite, je dissolvais l'équipe d'architectes dans toutes les équipes et j'utilisais leur expertise dans les questions d'architecture. En faisant partie de l'équipe, ils seront en mesure de mieux voir les problèmes rencontrés par l'équipe et pourraient avoir de meilleures idées ou des opinions plus éclairées sur la modification des éléments fondamentaux de l'architecture. Il convient également d'encourager les architectes des équipes à communiquer afin de garantir la cohérence de l'architecture entre les équipes.

Le groupe de Scaled Agile Framework en parle très bien. La plupart d'entre nous traitons au niveau de l'équipe, mais lors de la mise à l'échelle, nous devons reconnaître qu'il y a également des rôles à jouer au niveau du programme et du portefeuille. Les décisions architecturales doivent être prises dans toute l'organisation, et cela devrait alimenter ce qui se passe aux niveaux inférieurs de l'organisation. Il n'y a rien de mal à avoir des décisions architecturales!

À ce sujet, le récent livre de Dean Leffingwell sur les exigences logicielles agiles est une bonne lecture sur ce sujet, je l'ai lu moi-même.

Nous avons également plusieurs équipes agiles (certaines font du Kanban, d'autres du Scrum) et des architectes. Les architectes sont responsables de l'infrastructure qui couvre tous nos produits (bibliothèques d'assistance, authentification, infrastructure de construction), etc. Ils prennent des décisions techniques, mais mettent également en œuvre des choses, principalement des composants d'infrastructure.

Cela fonctionne bien et il n'y a généralement pas de conflit. Je crois qu'un point crucial est:

Les architectes n'ont aucune autorité officielle sur les équipes et ne peuvent pas simplement les annuler. Normalement, les architectes prennent des décisions qui s'appliquent à tous les produits et les équipes prennent des décisions pour leur produit. En cas de conflit, l'architecte et l'équipe doivent simplement parvenir à un accord ou passer à la gestion (bien que cela se produise rarement).

Je pense qu'il est vraiment important de faire des architectes et des développeurs des pairs. Les deux travaillent vers un objectif commun, juste dans des domaines différents. Si personne ne peut simplement "passer outre" l'autre, la coopération sera meilleure.

Je ne vois aucun conflit ici. D'après ce que je comprends, tout ce que EA (comme un titre pompeux je pense que c'est) est censé faire est QA. Tout le monde devrait en être conscient.

Vous devez considérer que dans toute méthodologie de développement (qui mérite d'être considérée comme une), la collecte des exigences est une étape cruciale, qu'elle soit itérative ou initiale.

Certaines de ces exigences sont définies par la politique de l'entreprise. Et ceux-ci établissent les règles de base:

• L'équipe devra les respecter comme pour toute autre exigence. La contestation de la politique est alors tout simplement en dehors de la portée du projet et doit être traitée séparément.
• Le travail de l'EA est de faire respecter ces exigences et non d'imposer leur fantaisie personnelle. Ils n'aiment pas X alors c'est leur opinion personnelle. Ni plus ni moins. Traitez-le comme toute autre opinion. Cependant, si l'EA peut montrer que l'utilisation de X viole une exigence existante, alors ils ont tout à fait le droit d'interdire l'utilisation de X et s'ils connaissent une alternative viable et que l'équipe ne le sait pas, alors c'est leur droit de la faire respecter.

Mais de toute façon, une exigence est satisfaite ou non. Si cette détermination est difficile à faire, alors l'exigence fait défaut et vous devez la réitérer pour devenir vraiment testable (dans un sens plus large). Vous devez gérer cela comme toute réitération d'exigence.

Votre architecte ne doit pas annuler les décisions prises par vos équipes agiles. Votre architecte doit les inclure dans les exigences / histoires transmises aux équipes. Ils doivent tenir les équipes à jour lorsque le paysage du projet change et que de nouvelles exigences d'interopérabilité sont introduites.

Les architectes qui donnent des ordres et examinent les décisions techniques sont un défaut culturel. Ils se considèrent comme le «patron» plutôt que de simplement maintenir un objectif / vision partagé et de garder des équipes distinctes sur la même page. Les méthodologies agiles sont basées sur la communication et le contact. Lorsque vos architectes ne s'impliquent qu'après la prise de décisions, ils échouent à l'agilité.

Martin, je pense que vous avez peut-être une idée fausse du fonctionnement d'une équipe auto-organisée dans son environnement.

Vous avez cité le Scrum Guide: "Personne (pas même le Scrum Master) ne dit à l'équipe de développement comment transformer le backlog de produit en incréments de fonctionnalités potentiellement libérables."

Ce n'est pas une licence pour l'équipe Scrum de faire ce qu'elle veut (tant qu'elle livre) sans tenir compte des besoins technologiques et commerciaux de l'entreprise dans son ensemble, et des besoins des autres équipes.

Bien sûr, les parties prenantes peuvent abuser de leur influence. C'est l'un des défis de la collaboration, et ce n'est certainement pas limité à l'EE. Mais la collaboration ne s'arrête pas aux limites de l'équipe.

Waterfall ou Scrum (cela ressemble à mélanger deux, ce qui ne fonctionnera pas), cela me semble être une couche de gestion assez inutile en premier lieu. Les gardiens des décisions technologiques devraient être des développeurs principaux, le directeur général du développement dont le travail devrait être d'empêcher les préférences des développeurs de transformer votre application en une hydre de choix technologiques, et quel que soit le budget de payer la facture potentielle.

Rien ne continue de m'abasourdir comme des non-développeurs ayant réellement le culot de prendre des décisions technologiques sans même consulter les personnes réelles qui doivent subir les conséquences de ces décisions.