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.
Réponses:
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.
la source
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.
la source
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:
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".
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.
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.)
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.
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.
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.
la source
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.
la source
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.
la source
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.)
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.
la source
Les responsables du développement sont embauchés pour:
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;
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.
la source
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.
la source