Etre chef d'équipe et développeur dans une équipe Scrum

Je gère une équipe de 6 personnes qui a récemment déménagé à Scrum.

Nous avons un Scrum Master (l'un des développeurs de l'équipe) et un Product Owner.

Étant donné que j'ai beaucoup de temps libre (parce que beaucoup de travail de gestion que je faisais est désormais effectué par le Scrum Master et le Product Owner), et comme je veux rester techniquement pertinent, je fais du travail de développement technique.

J'agis en tant que membre de l'équipe de développement, m'engage à certaines des histoires de chaque sprint et participe à toutes les réunions en tant que membre de l'équipe.

Penses-tu que c'est une bonne idée? Peut-elle contredire «l'auto-organisation» de l'équipe?

Lisez les réflexions de Roy Osherove sur le leadership d'équipe dans un monde agile sur 5whys.com

Il parle beaucoup des trois étapes clés qu'une équipe traverse au cours de son évolution de Waterfall à Scrum.

La phase de survie (où se trouvent la plupart des équipes que je vois) - dans laquelle l'équipe n'a pas le temps d'apprendre - nécessite un type de leadership plus commandement et contrôle pour créer ce temps d'apprentissage à partir de rien.

La phase d'apprentissage - où une équipe a le temps d'apprendre et l'utilise - nécessite un coach comme un leader, avec des éclats de contrôle lorsque les choses prendront trop de temps à apprendre à la dure (en choisissant aucun contrôle de source, par exemple)

Phase d'auto-organisation - où les équipes peuvent résoudre leurs propres problèmes - nécessite davantage un type de leader facilitateur, qui ne dit pas aux gens quoi faire, mais fournit simplement des contraintes et des objectifs finaux. L'équipe y arrivera seule.

Lorsque j'ai découvert les idées de Roy, à OpenVolcano '10 , je ne comprenais pas pourquoi mon équipe avait cessé de s'améliorer. Puis j'ai réalisé que l'équipe était passée de Survival à Learning et que je n'avais pas du tout changé mon style de management. Je l'ai fait et cela m'a beaucoup aidé.

Je suggère donc de déterminer laquelle de ces trois phases vous êtes et de gérer en conséquence.

Aussi, prenez une décision maintenant et soyez un leader ou un développeur. Ne tombez pas dans le piège de penser que vous avez du temps libre jusqu'à ce que vous soyez bien dans la phase d'auto-organisation. Et, si vous y arrivez, réalisez que vous êtes un bon chef d'équipe (c'est difficile ) et passez à une autre équipe plutôt que de vous réintégrer.

Les commentaires de pdr sont valides et je suis d'accord avec eux. Mais je ne pense pas qu'ils soient universels dans tous les cas.

Votre style de gestion déterminera dans quelle mesure ou si vous devriez même envisager de travailler dans deux rôles.
En tant que chef d'équipe, vous détenez l'autorité sur les performances et les décisions de type de carrière pour vos employés. Manié de manière incorrecte, la disparité de pouvoir entre vous et vos employeurs peut ruiner vos tentatives de faire partie de l'équipe de développement.

Tant que vous êtes conscient de cette disparité et que vous définissez clairement vos rôles, je pense que vous pouvez être à la fois manager et développeur. Je l'ai vu réussir à plusieurs reprises, et je travaille actuellement sur une équipe dans la même situation.

Il convient de noter que vous ne pouvez pas éliminer tous les effets de la disparité. Il y aura des moments où vous devrez vous mordre la langue et vous retenir d'un débat animé. Il y en aura d'autres lorsque vous aurez besoin de tirer la carte maîtresse et de souligner que la responsabilité ultime de l'équipe incombe à vous, donc vous faites un diktat.

Vous aurez besoin d'au moins deux développeurs solides et expérimentés dans votre équipe qui sont politiquement sécurisés. Leur rôle est de contrôler la disparité des pouvoirs et de vous appeler si les choses se déséquilibrent. Vous pouvez vous débrouiller avec un seul autre développeur puissant, mais en avoir un second fournit de l'objectivité au cas où vous seriez tous les deux bloqués sur un problème.

Je l'aime honnêtement quand mon supérieur immédiat se tient techniquement pertinent. Cela facilite leur compréhension de mes difficultés, et je pense que nous nous retrouvons avec une équipe plus performante.

J'ai déjà vécu une expérience similaire, dirigeant une équipe de 6 développeurs dans une équipe Scrum. Outre ce que pdr et GlenH7 ont mentionné, des choses qui ont aidé:

1. Le meilleur testeur de l'équipe AQ ​​était vraiment bon pour nous tenir responsables de la qualité de notre travail, y compris le travail que j'ai fait. Quand j'ai écrit du code buggé, elle m'a appelé dessus d'une manière qui serait difficile à faire pour un autre développeur.
2. Je faisais habituellement les démos de sprint, surtout quand nous avions de mauvais sprints. Depuis que je faisais une démonstration au PDG, c'était gênant quand les choses ne fonctionnaient pas. En plus de m'assurer que je comprenais les fonctionnalités développées par d'autres, cela signifiait également que mes trucs devaient être aussi solides que ceux des autres.
3. Je laisse les autres prendre des décisions. Mon expérience est différente de celle de GlenH7, j'ai toujours trouvé que c'était une erreur de tirer la carte maîtresse. Au lieu de cela, j'ai parlé des différentes conséquences des décisions et expliqué clairement à quel développeur travaillait sur quelque chose quelles étaient les conséquences pour la chose que je pensais être la "mauvaise" façon de faire quelque chose. Il y a plusieurs raisons à cela, mais la plus importante est qu'en tant que chef d'équipe, vous n'avez pas le temps de prendre toutes les décisions.
4. L'utilisation d'un produit comme Sonar peut rendre des choses comme la qualité du code plus objectives.