Le manager architecte

Software developerA mes yeux, si un scrumMaster code à plein temps, il peut devenir trop impliqué dans les choix techniques. Cela risque de devenir super important pour lui que l'on prenne SA solution à ce problème. Si le scrumMaster est en plus supérieur hiérarchiquement, ses idées peuvent passer plus facilement. L'équipe prendra-t-elle la peine de contester ?

Si une idée provenant du manager est forcément acceptée, il vaut mieux qu'il ne code pas pour laisser l'équipe se construire. Il faut du débat à mon sens, sinon il n'y a plus de scrumMaster mais un architecte qui commande officieusement. Ce serait dommage en cherchant à se rapprocher des équipes d'aller à l'encontre de la promotion de l'équipe.

Au delà de la perte de recul, un scrum master qui code beaucoup a moins de temps pour les tâches de base de scrum mastering : la facilitation, la construction d'équipe, l'agilisation, la veille... Devenir aussi bon qu'un développeur "normal" me parait être un objectif inatteignable en développant à mi-temps.

Le développement comme zone de confort

Dans cet extrait de Slack[2], Tom DeMarco évoque les raisons pour lesquelles un manager a temps de mal à quitter le terrain.

Pourquoi un manager va compenser un manque de ressources en mettant la main à la pâte ?

Dans un environnement suffisamment sur-stressé, manager n'est pas un choix sûr. Seul le véritable travail -le travail bas-niveau, comme construire le produit- te protège. Donc, si vous vous mettez à manager même un peu, ce sera une activité à mi-temps. Le reste du temps, vous ferez du produit, vous ramènez de l'argent. Faire rentrer du cash est une option sûre; Ainsi, le temps passé à manager ne sera pas retenu contre vous, tant qu'il reste minimal. (...)

Nous nous assignons aussi du travail d'opérationnel pour fuir le challenge. Oui, je sais, nous aimons tous un bon défi, mais cela ne signifie pas que nous ne nous dégonflons parfois et ne cherchons pas un échappatoire. Les challenges du management sont décourageants : ils nous mènent vers un monde effroyablement intangible de relationnel, motivation, formation sociétale, conflit et résolution de conflits.

Dans mon cas, j'ai été promu à un poste de management juste après un poste technique où il n'y avait rien d'intangible. J'étais un architecte système juste avant ma promotion. Le monde du système est délicieusement noir ou blanc : une solution fonctionne, ou pas. (...)

Le management est tout en nuance. Pourquoi diable Maria est-elle si susceptible ? Qu'est ce que c'est que cette tension entre Armand et Elwood ? Danny cherche-t-il ailleurs, et que ferons-nous si c'est le cas ? La date de livraison est-elle équilibrée entre difficulté et faisabilité, ou tout le monde profite-t-il de ma naïveté ? Ai-je employé le bon ton lors de mon briefing ? (...)

Pendant que j'essayais encore de comprendre tout cela, un de mes architectes partit. J'ai pris sa place sans hésiter. Pff, quel soulagement. Non seulement j'étais manager, mais aussi capable de passer mes jours à accomplir du travail noir ou blanc. Cela semblait être le meilleur des mondes. C'était faux. Je fuyais juste les difficultés du management pour retourner à travail plus froid. C'était le soulagement de la fuite.

Je rejoins l'auteur sur ces points. Depuis que je suis ScrumMaster, je ne sais plus quoi dire au standup. J'accomplis très peu de choses au quotidien (de concret). Je n'ai plus ces petites victoires régulières à la résolution d'un bug ou au développement d'une fonctionnalité.

Le management est indispensable pour que tous les acteurs puissent travailler ensemble, mais il s'agit d'un travail de longue haleine, ingrat en plus. C'est peut être réellement pour avoir un peu de certitude que j'aime retourner coder avec l'équipe.

Les deux métiers ne sollicitent pas du tout les mêmes compétences. Chercher à les améliorer prend du temps. Choisir de coder revient à choisir de renoncer d'autant à la part manageriale et prendre le risque d'illustrer tristement le principe de Peter [5].

Un besoin de feedback

Techniquement, je n'ai pas le temps de développer, je change souvent de tâches et suis régulièrement interrompue. J'en suis à poser des réunions pour binômer par tranche d'une heure, de temps en temps. Sans elles, je verrai mon équipe quinze minutes par jour. Si je veux en savoir plus, je dois aller sur le terrain (go and see).

Sans jamais coder, je ne peux pas me rendre compte des obstacles rencontrés. C'est là que tout se passe. Au standup, ils sont rarement évoqués (quand c'est fini, on n'en parle plus...). Je ne peux pas proposer des idées naïves. Je ne peux pas challenger leurs habitudes. Je ne peux pas comprendre de mieux en mieux leur métier. Je ne peux pas dire que telle autre personne a justement le même besoin et a développé un outil. Je ne peux pas favoriser l'émergence de standards. Je n'aurais pas appris tel raccourci et n'aurait pas pu le remontrer à telle autre personne. Je n'aurais pas proposé de mauvaises idées. Je n'aurais pas proposé de bonnes idées. Je ne comprendrais pas leur quotidien. Je ne serais pas vraiment un membre de l'équipe et peut-être qu'ils ne me parleraient pas aussi franchement.

J'ai besoin de voir ce qu'il se passe pour leur donner du feedback, et vice versa. Je ne veux pas être dans une tour d'ivoire.

La difficulté est de le faire assez souvent pour en tirer de la valeur et assez rarement pour garder le point de vue extérieur. Il faut aller dans l'eau pour voir comment son équipe vit, mais aussi en sortir pour repérer les mouvements inutiles et avoir la vue d'ensemble.

Et vous, qu'en pensez-vous ?

Ressources