Quels sont les points négatifs des directeurs de développement en tant que Scrum Masters?

Il est communément admis que les chefs d'équipe ne devraient pas être des maîtres de mêlée, mais j'ai du mal à voir pourquoi. Pour le contexte, je suis un gestionnaire de développement d'applications avec 4 développeurs dans une équipe Scrum. Je viens d'un milieu Scrum Master et j'ai introduit Scrum dans l'organisation. J'ai construit l'équipe à partir de zéro et clairement indiqué que tout ce que je fais est de faciliter l'équipe et qu'ils prennent les décisions. En tant qu'équipe, nous sommes très ouverts - ils m'ont même fait taire pendant les stand-ups pendant un certain temps pour éliminer la sensation de «reportage» que nous commencions à ressentir. Un manque d'ouverture est généralement le plus gros argument contre le manager en tant que Scrum Master, mais bien géré, il est facilement surmonté avec la bonne culture.

Des entraîneurs de mêlée expérimentés m'ont prévenu qu'il s'agit d'une situation dangereuse et qu'il y a des risques «si les choses tournent mal». À mon avis, les 2 positions ne sont pas en conflit, dans les deux rôles, j'ai le même objectif pour l'équipe et les individus. Scrum résout les conflits au sein de l'équipe, qui pouvaient traditionnellement être un rôle de manager. La nature autogérée des sprints enlève la répartition du travail qu'un gestionnaire ferait traditionnellement.

Tout ce que je vois vraiment à ramasser en tant que gestionnaire de développement est de s'assurer que les besoins individuels sont satisfaits, les objectifs de carrière, le lieu de travail, etc. Une grande partie de cela concerne directement l'équipe, ou mon rôle de Scrum Master de toute façon.

Je comprends dans les grandes organisations comment cela pourrait être ingérable et un rôle distinct, mais pour une petite organisation, nous ne pourrions certainement pas justifier un autre Scrum Master ou Manager de développement.

Veuillez m'éclairer sur les pièges des responsables du développement en tant que Scrum Masters, à l'exclusion des points que j'ai soulevés ci-dessus et que j'ai déjà surmontés.

Essentiellement, vous avez un conflit d'intérêts. Le travail d'un manager est de respecter les délais. Le travail d'un Scrum Master est de s'assurer que les estimations sont aussi précises que possible et de travailler à un rythme durable. Un manager a tendance à vouloir plus de travail dans un sprint, et un Scrum Master a tendance à vouloir un montant qui peut être finalisé de manière réaliste, indépendamment des délais externes. Bien qu'un bon gestionnaire puisse équilibrer ce conflit, c'est beaucoup plus facile lorsque le travail est partagé entre deux personnes. Les managers sont généralement beaucoup mieux adaptés au rôle de Product Owner.

Il n'y a rien de mal à jouer le rôle de Scrum Master si personne dans votre équipe ne le connaît, mais votre équipe verra des avantages si vous abandonnez ce rôle après quelques mois. Il est important que ce rôle soit considéré comme un pair. Même les maîtres de mêlée non-cadres doivent souvent déménager après un certain temps car l'équipe commence à les traiter trop comme un manager.

Je crois que le principal problème est qu'en tant que manager, vous avez le pouvoir de dire à l'équipe quoi faire. Un Scrum Master n'a pas cette autorité en dehors de l'application des principes de Scrum.

Qu'est-ce que ça veut dire? L'apport du gestionnaire aura implicitement plus de poids. Vous ne le pensez peut-être pas, ou vous ne le voulez pas, mais à la fin de la journée, la carrière et le salaire de votre équipe dépendent en quelque sorte de vous. Et ils le savent. Et cela entache la relation.

Peux-tu encore le faire? Bien sûr. Vous avez juste besoin de travailler très dur pour renforcer que vous êtes un leader serviteur et que le top-down ne volera pas.

En fait, j'ai vu ce qui se passe quand un «responsable technique» s'implique trop dans la mécanique quotidienne d'un projet, et ce n'est pas joli. Dans notre cas, le manager en question n'était pas le scrum master mais essayait de coopter certaines de ces décisions; si nous n'avions pas vraiment eu de maître de mêlée séparé pour jouer la défense, cela aurait été bien plus douloureux.

(Soit dit en passant, ce n'était pas mon manager, donc je me sens assez objectif sur ce point.)

Je vais passer en revue ce que je considérais comme les principaux conflits d'intérêts; si vous ne pensez pas que l'un de ces éléments s'applique à votre situation, vous pouvez peut-être faire les deux. Mais assurez-vous de revérifier ces hypothèses régulièrement pour vous assurer de ne tomber dans aucun de ces pièges:

1. Les directeurs techniques sont généralement responsables d'un certain rôle au sein de plusieurs équipes. S'il ne s'agit que d'une seule équipe, il s'agit plus d'un "lead" que d'un "manager". Cette répartition des responsabilités signifie moins de temps avec l'équipe et moins de temps avec le projet / produit, et a tendance à conduire à une gestion de style "hit and run".

2. Les directeurs techniques ont de nombreuses autres fonctions de gestion dans l'entreprise. Ils doivent faire du coaching / de la formation, des évaluations de performance, des entretiens / du recrutement, une planification à long terme des infrastructures / ressources, etc. Cela peut facilement devenir un emploi à temps plein par lui-même et signifie qu'il reste très peu à dépenser pour faciliter.

3. Un horaire chargé peut également s'imposer à l'équipe; les directeurs techniques peuvent avoir besoin (ou vouloir) d'attirer des membres de l'équipe dans des réunions à ce que l'équipe considère comme un moment inopportun. C'est normalement le travail du Scrum Master de gérer et d'essayer d'éliminer les interruptions, mais il est impossible d'être objectif à ce sujet lorsque vous avez votre propre horaire à vous soucier. Les Scrum Masters ont rarement besoin de rencontrer séparément les membres de l'équipe car toutes ces réunions sont déjà pré-programmées (stand-up, rétrospectives, etc.)

4. Les responsables techniques doivent traiter les préoccupations transversales du projet et leur impulsion naturelle sera d'essayer de tout normaliser - bibliothèques, contrôle de source, algorithmes, dispositions, couleurs, etc. Bien que cela puisse être une bonne chose pour l'entreprise, cela ne laisse finalement personne pour aller au bout de ce que l'équipe veut faire, et ils peuvent avoir de très bonnes raisons de vouloir faire quelque chose différemment. Cela va à l'encontre des idéaux d '"amélioration continue" qui sous-tendent Scrum et des méthodologies similaires.

5. Les gestionnaires qui ont une expérience experte dans le rôle qu'ils gèrent auront leurs propres idées assez fortes sur la façon dont le travail devrait être fait et combien de temps il devrait prendre. Ce n'est pas une mauvaise chose en tant que manager , mais en tant que Scrum Master, cela signifie souvent que les membres de l'équipe sont biaisés dans des conceptions ou des estimations qu'ils n'auraient pas autrement acceptées - et ils en savent probablement plus que vous sur le problème à résoudre.

6. Les membres de l'équipe auront toujours du mal à faire la différence entre une demande et une commande. Ils ne vous le diront pas et ne s'en rendront peut-être même pas compte. Même si vous précisez que vous ne faites que demander et ne pas dire, dans leur esprit, vous êtes toujours leur manager et il y a des risques au niveau de la carrière à dire «non». C'est probablement le plus insidieux de tous les problèmes car il n'y a rien que vous puissiez faire à ce sujet - c'est leur attitude et non la vôtre qui compte.

Si vous êtes sûr de ne jamais tomber dans l'un de ces pièges, allez-y ... mais je le répète, assurez-vous de valider fréquemment vos hypothèses en parlant à votre équipe (et à d'autres équipes / managers!) et assurez-vous qu'ils ne se produisent pas d'une manière subtile ou inconsciente que vous ne remarquerez peut-être pas.

Sur une note positive, j'ajouterai que le fait que vous considérez le problème suffisamment important pour réellement poser la question signifie que vous êtes probablement assez bon dans les deux rôles. Prendre soin de l'équipe et pas seulement de vos propres ambitions professionnelles représente probablement plus de la moitié de ce qu'est une bonne gestion, dans mes livres de toute façon.

... mais être bon dans les deux ne signifie pas nécessairement que vous pouvez être bon dans les deux en même temps, tout le temps . Faites attention à ça.

Ce n'est pas de la religion et les règles de Scrum ne sont pas dogmatiques. S'il y a déjà eu un cas pour un rôle combiné de responsable RH / maître Srum, vous en avez fait un bon. Soyez à l'affût des pièges que vous avez mentionnés, mais il n'y aura jamais un seul ensemble de règles qui s'adaptera parfaitement à chaque situation.

Si votre équipe est à l'aise avec vous dans les deux rôles, il n'y a aucune raison de faire bouger les choses juste pour s'adapter aux règles d'un livre.

Le plus gros problème que je vois est la situation où l'équipe a un problème lié à vous, le manager. S'ils sont juniors ou manquent de confiance, ils peuvent avoir peur de s'exprimer lors des rétrospectives. Cela pourrait limiter l'efficacité des rétrospectives. Beaucoup de gens ont peur de dire "je sens que le manager est irréaliste" quand le manager est présent.

Alors, peut-être que vous vous excusez des rétrospectives pour résoudre ce problème. Maintenant, votre équipe fait des rétrospectives sans scrum master, ce qui limite potentiellement l'efficacité de la rétrospective.

Dans les deux cas, vous avez un impact négatif sur l'équipe.

Le principal problème que je vois est que vous envoyez des messages contradictoires à l'équipe au sujet de l'organisation de l'équipe.

Voici deux organisations d'équipe possibles. Les deux peuvent réussir. Ils sont différents. (Ce ne sont pas les seules options possibles.)

1. L'équipe a un chef officiellement désigné. Le chef d'équipe est ultimement responsable de la performance globale des équipes. Le chef d'équipe peut ne pas prendre toutes les décisions, mais le chef d'équipe a le dernier mot sur toutes les décisions.
2. L'équipe est auto-organisée et n'a pas de chef officiellement désigné. Tous les membres de l'équipe sont responsables de leur propre performance et de la performance globale des équipes. Le Scrum Master facilite le processus Scrum, mais n'est pas habilité à prendre des décisions unilatérales pour l'équipe.

Il semble que votre véritable structure d'équipe soit n ° 1, mais en utilisant la terminologie et plusieurs processus de Scrum, vous indiquez que la structure est n ° 2. Mon opinion est que le n ° 1 n'est pas Scrum.

Voici deux suggestions pour résoudre le conflit.

1. Continuez à faire les choses comme vous êtes, mais précisez que vous êtes le chef d'équipe et que vous ne suivez pas Scrum à 100%. Il serait probablement utile d'expliquer que, même si vous voyez l'intérêt de séparer les fonctions de manager et de scrum master, cela n'est pas faisable pour l'entreprise.
2. Remettez les responsabilités de Scrum Master, autant que possible, à quelqu'un d'autre. Même si vous devez encore conserver certaines responsabilités comme l'élimination des barrages routiers et la déviation des distractions du reste de l'organisation, il sera toujours utile que la plupart du travail du Scrum Master soit effectué par un pair.

Quels sont les points négatifs des directeurs de développement en tant que Scrum Masters?

Les responsables du développement sont embauchés pour:

• Résoudre les problèmes de développement .
• Surveiller et réduire la dette technique.
• Augmentez le personnel technique.

Leur expérience et leur expertise les prédisposent à se concentrer sur les questions techniques .

D'un autre côté, des chefs de projet / maîtres de mêlée sont embauchés pour;

• Assurer la réussite du projet.
• Attribuez des bogues / questions de travail et de triage aux ressources de développement appropriées.
• Collaborez avec l'équipe de développement pour éliminer tous les obstacles susceptibles de retarder l'achèvement du projet.
• Relayer l'état du projet à la haute direction.

• Lorsqu'un projet ou une entreprise atteint une certaine taille, il est inefficace et imprudent de demander à un responsable du développement d'effectuer les deux tâches.

• Un gestionnaire de développement devrait être enclin à faire des "plongées profondes" dans le code et / ou l'architecture, tandis qu'un chef de projet / maître de mêlée devrait toujours se préoccuper de la vision des choses à "50 000 pieds".

• La plupart des responsables du développement ont passé des années à développer du code. Les problèmes de développement leur sont très familiers.

  • Par conséquent, ils sont plus utiles lorsqu'ils résolvent des problèmes techniques.
• Les rôles de chef de projet / maître de mêlée nécessitent des personnes très organisées et très détaillées, mais pas super-techniques.
• Lorsque vous pouvez vous permettre de laisser ces personnes se spécialiser dans les domaines dans lesquels elles sont douées, l'entreprise est plus efficace.
• Et lorsque vous pouvez décharger les responsabilités liées à Scrum d'une plaque de responsable du développement, il / elle peut consacrer plus de temps aux problèmes techniques et à la réduction de la dette technique.

J'écouterais des entraîneurs de mêlée expérimentés. Il est possible que vous vous entraîniez très bien 99% du temps. Cependant, lorsque ce redoutable 1% arrive et que les rôles entrent en conflit, vous avez une chance de gâcher non seulement la relation d'un individu avec vous, mais le bien-être de toute l'équipe. Et après une erreur, votre rôle en tant que Scrum Master et Manager serait compromis.

Si j'étais vous, j'identifierais un membre de l'équipe qui a le potentiel pour être le maître de mêlée et je l'accompagnerais. J'ai toujours considéré un Scrum Master comme quelqu'un en qui l'équipe a confiance et qui comprend également le processus, l'entreprise et les trucs techniques effrayants. Si vous avez choisi une personne capable, un rôle de Scrum Master n'est pas (et même pas proche d'être) un emploi à temps plein.