2024-02-07 16:43:00
Moi.
Publicité
(Image : Stefan Mintert )
Stefan Mintert travaille avec ses clients pour améliorer la culture d’entreprise en matière de développement de logiciels. Il voit actuellement le plus grand potentiel dans le leadership ; quel que soit le niveau hiérarchique. Il s’est donné pour mission d’exploiter ce potentiel après un parcours professionnel comportant quelques changements de cap. Issu d’une formation en informatique avec plusieurs années d’expérience en conseil, il a d’abord fondé sa propre société de développement de logiciels. Il a découvert que le leadership s’apprend et que les bons modèles sont rares. Il est devenu évident que le plus grand besoin de soutien de la part de ses clients dans le développement de logiciels n’était pas la production de code, mais le leadership. Il était donc clair pour lui que l’objectif de son entreprise Kutura était d’améliorer le leadership afin que les personnes qui développent les produits puissent se développer et se développer. Stefan écrit pour Heise en tant que pigiste de longue date pour iX depuis 1994.
Aujourd’hui, j’aimerais écrire sur les personnes ou les rôles qui appartiennent réellement à une équipe.
Selon le Guide Scrum, une équipe Scrum se compose de :
- Propriétaire du produit
- Scrum Master et
- Développeurs
Le manifeste agile stipule que les développeurs et les hommes d’affaires travaillent ensemble au quotidien comme principe du développement logiciel agile.
Pour moi, ces deux points ne sont pas compatibles. Je pense que la définition de l’équipe est un défaut dans la conception Scrum. Comment ça se fait?
Dans toute collaboration, des frictions ou des conflits surgissent parfois. Une partie du développement ultérieur des personnes travaillant ensemble réside dans le fait qu’elles apprennent à gérer les frictions et les conflits.
Dans Scrum, la rétrospective est l’événement phare au cours duquel une équipe améliore sa collaboration. Si les développeurs, fidèles au manifeste agile, travaillent quotidiennement avec les gens d’affaires, la question se pose de savoir dans quelle mesure la collaboration entre ces deux groupes doit être améliorée. Pas dans la rétrospective, car elle est réservée à l’équipe Scrum.
Si vous ignorez la définition de l’équipe Scrum et comprenez une équipe comme l’ensemble des personnes qui travaillent ensemble sur le produit, il s’ensuit que les hommes d’affaires participent également à la rétrospective.
Peut-être qu’avec cette compréhension de l’équipe, le groupe sera trop grand. Ensuite, à mon avis, il n’y a rien de mal à faire une rétro avec l’équipe Scrum et une rétro cross-team avec un plus grand groupe de participants. Il est intéressant de noter qu’avec cette compréhension, il n’y aurait pas de Scrum à une seule équipe.
Qu’est-ce que cela signifie pour les développeurs ?
La conséquence la plus importante pour certains développeurs est qu’ils ne peuvent pas se cacher derrière leur propriétaire de produit. J’ai notamment observé le fait de se cacher lorsque les développeurs voient le productowner comme une interface « vers l’extérieur ». Selon la compréhension présentée ici, les « outsiders » font partie de l’équipe dans laquelle travaillent les développeurs ; mais il n’existe alors aucune fonction d’interface que le propriétaire du produit pourrait assumer.
Les conséquences sont extrêmement vastes, et je suis convaincu que l’une d’entre elles est la suivante : l’agilité est améliorée.
Quiconque s’oppose maintenant au fait que le Guide Scrum dit très clairementIl est juste que le Scrum Master doive lutter contre la mentalité de silo. Il est écrit littéralement « Supprimer les barrières entre les parties prenantes et les équipes Scrum ». Mais il indique également que la rétrospective est un événement de l’équipe Scrum. Aucun étranger n’est impliqué. C’est ce que j’appelle une barrière.
De plus, ce blog ne s’adresse pas aux Scrum Masters, mais aux développeurs de logiciels. Sans leur contribution, l’agilité ne peut pas fonctionner et conduit plutôt à une fabrique de fonctionnalités dans laquelle les développeurs traitent uniquement les tickets jetés de l’extérieur dans leur silo.
Et c’est pourquoi je suggère que les développeurs de logiciels qui souhaitent échapper à l’usine de fonctionnalités considèrent les hommes d’affaires et les autres parties prenantes comme faisant partie de leur équipe et les traitent de cette façon.
Au revoir. Stéphane
(moi)
#Équipe #Scrum #contre #équipe #Agile #heise #ligne
1707424845
