Une équipe agile mature nécessite-t-elle une gestion?

Après un récent débat houleux sur Scrum, j'ai réalisé que mon problème est que je considère la gestion comme une activité tout à fait inutile et redondante dans une équipe entièrement agile. Je crois qu'une équipe Agile mature ne nécessite aucune gestion ni aucun processus de prise de décision non technique que ce soit. À mes yeux (apparemment égarés), il est plus qu'évident que le seul apte et capable de gérer une équipe de développement mature est leur coach (qui est le collègue le plus compétent sur le plan technique avec des compétences de communication appropriées). Je ne peux pas imaginer comment un Scrum master peut contribuer à une telle équipe.

J'ai beaucoup de difficulté à réaliser et à comprendre la valeur de telles choses dans Scrum et le manager en tant que quelqu'un qui n'est pas un développeur vétéran mais qui est bien qualifié pour planifier les cycles de production lorsqu'un coach existe dans l'équipe. Qu'est ce que ça veut dire? Comment diable une personne sans compétences de développement peut-elle gérer une équipe hautement technique? Peut-être que la gestion ici signifie autre chose?

Je vois la gestion comme une perte de temps totale et un sous-produit de l'immaturité. À ma connaissance, une équipe mature est entièrement autogérée. Apparemment, je me trompe car beaucoup de gens formidables disent le contraire, mais je ne peux pas me convaincre.

Vous faites plusieurs erreurs ici.

Le premier suppose qu'un Scrum Master est un manager. Ils ne sont pas. Ils sont essentiellement un administrateur-facilitateur. Ils s'assurent que les choses se produisent sur le calendrier Scrum, mais ils n'ont pas à vous dire comment, si vous êtes une équipe Agile pleinement mature. Cela arrive surtout juste.

Mais ils ne surveillent pas la qualité de votre travail et ne signent pas vos vacances ou quelque chose comme ça. Ils ne gèrent pas non plus le produit ou le projet; cela est fait par d'autres personnes.

La plus grosse erreur que vous faites est de supposer que vous pouvez vous éloigner de la situation que vous avez décrite dans d'autres questions ("Les développeurs sont loin d'être capables de faire des pratiques de programmation agiles pour le moment. Pas de tests unitaires, pas de programmation de paires, pas de CI ( hein? qu'est-ce que c'est?) ... vous avez l'idée. ") à" l'équipe Agile pleinement mature "du jour au lendemain. Ce n'est tout simplement pas possible. Oublie. N'essayez même pas.

Si vous souhaitez obtenir des résultats du jour au lendemain, recherchez des approches de gestion de projet plus structurées. Et embaucher des gestionnaires.

Si l'entreprise veut que vous soyez agile, cela prend du temps, il faut un changement de culture. Et oui, au début, quand vous êtes au stade d'amélioration chaotique , cela va nécessiter une gestion. Que ce soit un individu ou un groupe, quelqu'un va devoir prendre des décisions.

Vous avez besoin d'une personne ou d'un groupe pour avoir une vue d'ensemble, expliquer la situation actuelle aux développeurs et à l'entreprise, et expliquer les options que vous avez pour l'amélioration, déterminer ce dont l'entreprise a besoin, puis guider les gens à travers il.

Il faudra beaucoup de temps avant que vous puissiez vous appeler une équipe Agile pleinement mature et vous gérer vous-même. La plupart des équipes n'y arrivent jamais.

À ma connaissance, une équipe mature est entièrement autogérée.

Supposons un instant que vous ayez raison. Je ne sais pas d'une manière ou d'une autre, alors n'en parlons pas.

Le problème vient du fait que même une équipe autogérée se retrouve avec quelqu'un avec de bonnes compétences sociales et politiques qui peuvent représenter l'équipe dans d'autres départements. Quelqu'un qui garde la trace de ce que tout le monde fait, quand il prend des vacances, etc. Quelqu'un qui s'occupe des conneries et du budget RH. Quelqu'un qui se dispute avec les groupes QA et PM pour que le reste de l'équipe n'ait pas à le faire. Quelqu'un qui assure la médiation des inévitables querelles interpersonnelles entre les développeurs. Quelqu'un pour planifier des réunions et garder le moral.

Cette personne est un manager.

• Vous arrivez à la maison un jour et vous payez le chèque ne ...
• Vous voulez prendre un congé, mais l'équipe est trop occupée et depuis un an ...
• Votre femme ou votre enfant est malade et a besoin que vous réduisiez à 20 heures par semaine
  pendant 6 mois.
• Le département des finances a appelé à une réduction budgétaire et quelqu'un doit y aller.
• La machine à café est tombée en panne et personne ne peut la réparer.
• Votre équipe est si bonne qu'il n'y a aucun défaut à corriger et aucune fonctionnalité à ajouter, vous n'avez plus de travail - que faire maintenant.
• Le client ne paiera pas pour le travail effectué
• Le client veut plus de travail que vous ne pouvez en faire et est prêt à payer pour cela.

Je ne vois rien dans cette liste qui ne m'est pas arrivé dans ma carrière. Je ne vois rien dans cette liste qui nécessite des compétences hautement techniques. Je vois beaucoup de choses dans cette liste qui nécessitent des compétences spécifiques que, franchement, la plupart des développeurs n'ont pas, et les bons gestionnaires, peu importe ce qu'ils ont géré par le passé.

Arrêtez les gestionnaires d'ensachage - reconnaissez que vous avez un ensemble de compétences et qu'ils ont un ensemble différent. Toutes ces compétences sont nécessaires dans toute organisation. Vous ferez leur travail aussi bien qu'ils feront le vôtre. Il est rare d'avoir quelqu'un de bien dans les deux emplois, il est plus rare d'avoir quelqu'un de bien dans les deux qui peut faire les deux simultanément. Ce qui se passe sans mangeoire, c'est que les choses s'érodent lentement dans un état de dysfonctionnement. Si vous êtes chanceux, il est reconnu assez tôt, un gestionnaire est embauché, et tout d'un coup, les problèmes disparaissent comme par magie, et vous êtes laissé pour continuer le travail pour lequel vous êtes payé plutôt que de faire de la politique de bureau idiote (parlant de expérience ici).

Je vois la gestion comme une perte de temps totale et un sous-produit de l'immaturité.

Sensationnel. Vous n'avez pas travaillé avec de bons managers récemment, n'est-ce pas? (Nous avons tous travaillé avec les mauvais).

J'ai parfois vu des gens commettre l'erreur de supposer que tout ce qu'ils ne comprenaient pas pleinement était facile.

(Les gens d'affaires sont particulièrement coupables de cela - avez-vous déjà reçu des spécifications de mauvaise qualité ET un délai fixé dans la pierre?)

Dans la plupart des entreprises, l'équipe de développement fait partie d'un ensemble plus vaste. Les managers existent comme interface entre l'équipe et le reste de l'entreprise. Un bon gestionnaire travaillera cette relation dans les deux sens, s'assurant que l'équipe obtient ce dont elle a besoin (exigences, espace de bureau, nouveaux ordinateurs, reconnaissance, bonus, etc.) ainsi que la communication des priorités (en constante évolution) qui sortent du bureau du coin .

Le coin bureau existe pour de nombreuses raisons, dont la plupart ne sont pas pertinentes pour ce poste.

N'oubliez pas que la plupart des gestionnaires prennent les meilleures décisions possibles avec les informations à leur disposition qui peuvent ne pas être les mêmes que celles dont vous disposez .

Si vous aviez une équipe de développement pleinement mature qui faisait partie d'une entreprise pleinement mature qui avait des clients pleinement matures et que rien n'avait changé, vous pourriez éventuellement éliminer le besoin de la plupart des gestionnaires. Le terme pour cela est l' utopie .

Bonne chance avec ça.

ps - lire Ne vous appelez pas programmeur - d'excellents conseils et explique mieux que moi comment le reste du monde des affaires nous considère.

Le travail d'un scrum master ou d'un manager en général n'est pas d'agir comme un suzerain dictatorial. Le travail d'un manager est de s'assurer que son équipe est bien installée pour réussir au sein de l'entreprise. Cela inclut l'embauche des bonnes personnes, l'obtention du bon équipement et le maintien d'une vision stratégique du produit. Un manager doit être comme un juge de ligne, en gardant les détails et les détails qui ne sont pas importants pour le succès d'une équipe d'interférer avec leur progression.

Une partie du problème est que "Scrum Master" est probablement le rôle le moins précisément intitulé de toute l'histoire. "Scrum Facilitator" serait un peu plus précis, mais comme quelqu'un l'a souligné plus tôt, le travail de SM n'est pas de gérer l'équipe mais de faire disparaître les problèmes afin que l'équipe (autogérée) puisse continuer son travail. Oui, le Scrum Master est également responsable de s'assurer que la mêlée se produit: les tâches sont mises à jour avec les heures restantes, les stand-ups sont maintenus et ajoutent de la valeur, les burn-downs sont mis à jour et la vitesse est suivie, etc., mais c'est toujours un coaching et rôle de facilitateur et non de gestionnaire.

Une autre partie du problème est que les gens dans les bureaux du coin veulent connaître les réponses à des questions comme "quand puis-je expédier le logiciel?" et "quelles fonctionnalités contiendra-t-il?" et ils ont l'habitude de pouvoir poser ces questions à un «chef de projet» et d'obtenir des réponses avec de nombreux diagrammes de Gantt d'aspect impressionnant et peu ou pas de mention de choses inconfortables comme le cône d'incertitude.

Sous Scrum, il est possible de commencer avec une liste approximative des fonctionnalités "volonté", "pourrait" et "ne sera pas" pour une date de livraison donnée, mais il y a certainement un rôle pour quelqu'un - probablement le maître de mêlée - en gardant le coin bureau à jour avec les changements inévitables dans ces listes au fil du temps. Je suis tenté de considérer cette activité, ainsi que le traitement des commentaires qui en résultent et la gestion des nouvelles demandes de fonctionnalités comme une «gestion», bien que la gestion soit différente de ce que beaucoup, beaucoup de chefs de projet auraient pu faire dans le passé.

Si vous pensez qu'aucune gestion n'est nécessaire, qui exécutera les tâches organisationnelles suivantes, qui répondra dans les situations suivantes?

• de nouveaux clients doivent être trouvés. Comment vendez-vous vos produits? Comment faites-vous de la publicité?
• les matériaux doivent être achetés, les fournisseurs doivent être trouvés
• des discussions diplomatiques avec d'autres entreprises, des banques ou un bureau du gouvernement doivent être menées

Je fais partie d'une petite équipe sans manager et ça marche. Pourquoi? Honnêtement, je ne sais pas.

Ma meilleure supposition est que cela dépend du type de personne que vous êtes. Certaines personnes «sont» des ordinateurs, elles doivent donc être alimentées par un processus. D'autres personnes sont des "programmeurs" et ont la capacité de créer leur propre monde et structure à partir de rien.

Je dois créer un système ou être asservi par un autre homme; Je ne raisonnerai pas et je ne comparerai pas: mon métier est de créer.--William Blake

EDIT en réponse au commentaire de glenatron:
c'est plus qu'une simple équipe de développement. Nous avons un PDG, une réceptionniste qui répond au téléphone et un informaticien. Nous communiquons directement avec les clients par e-mail, téléphone ou réunions. Notre activité principale est de créer notre propre produit et de le vendre, plutôt que de rechercher des contrats. Mais il y a aussi des contrats.

J'y ai pensé plus et ce sont les raisons pour lesquelles je pense que cela fonctionne:
1. Nous créons principalement notre propre produit plutôt que de créer quelqu'un d'autre.
2. Nous avons une éthique de travail cohérente et indépendante sans surveillance.
3. Nous avons une connaissance du domaine.
4. Chance. Une poignée de personnes qui s'entendent et travaillent bien ensemble.

Quelqu'un a mentionné que la société Valve n'avait pas de direction non plus. Valve crée son propre produit plutôt que celui de quelqu'un d'autre. Je pense qu'une entreprise de produits se prête mieux à l'autogestion. Il n'y a aucun risque de suivre un chemin différent de celui auquel le client s'attend car vous êtes le client. Dans une entreprise de jeux, cela est particulièrement vrai. Rendez votre jeu amusant.

Vous ne pouvez pas gérer votre façon de vous amuser. Vous ne pouvez pas gérer votre chemin vers la création originale de l'art.