Contexte
L’utilisation d’un cadre de travail agile tel que Scrum rentre souvent en opposition avec les paradigmes présents dans les organisations. Il ne s’agit pas d’appliquer de nouvelles méthodes de gestion de projet pour faire un peu plus de la même chose, en un peu mieux ou un peu plus rapide mais de changement des modèles mentaux chez les protagonistes et de transformation de la vision de l’organisation du travail.
Ces changements de modèles mentaux vont concerner tous les protagonistes. Vous savez déjà que le Product Owner n’est pas un nouveau titre pour un Chef de Projet MOA ou un chef des Business Analysts, et que le Scrum Master n’est pas un nouveau titre pour un Chef de Projet MOE.
Mais qu’en est-il du Développeur ? Doit-il lui aussi changer de modèles mentaux lorsqu’il intègre une équipe Scrum ?
Le « Bon » développeur traditionnel
La mission du développeur traditionnel, travaillant dans une organisation silotée, consiste à coder un programme informatique correspondant à une description qui lui est souvent fournie de manière plus ou moins détaillée sous forme de cahier des charges / expressions des besoins / spécifications fonctionnelles.
Bien évidemment, le niveau de détail n’est jamais le bon. Soit la documentation va trop dans le détail, jusqu’à décrire une solution, soit la documentation est considérée trop vague pour que le développeur sache ce qu’il doit produire. Dans les 2 cas, la documentation fera de nombreux allers-retours entre les acteurs pour arriver à un consensus.
Le bon développeur mettra ensuite en œuvre son expertise technique pour produire un code informatique d’aussi bonne qualité que possible dans les délais impartis pour respecter au mieux les plans. Les plannings étant toujours très tendus, il est évident que la meilleure option est que chaque développeur se concentre sur la technologie qu’il maitrise le plus. Puis il passera le relais à un autre expert pour continuer le travail avant que le produit n’atteigne les mains de l’utilisateur.
Enfin, le très bon développeur sera l’expert senior, le héros reconnu par tous que l’on appelle pour débloquer le problème technique et sauver l’équipe d’un risque de dérive de planning.
Quelques mois plus tard, où en sommes-nous ? Nous avons un bassin d’experts, ayant chacun approfondi et optimisé localement son sujet d’expertise, sans grand intérêt pour la vision globale des enjeux futurs du produit et de l’organisation, autant en termes d’évolution fonctionnelle que technologique.
Ne peut-on pas changer de paradigme et glisser d'une culture de contrôle d’un ensemble d’experts disciplinés, comme des ressources dans un tableau Excel, vers le développement de collaborateurs autonomes, innovants et créateurs ?
En quoi le Développeur au sein d’une équipe Scrum doit-il incarner des comportements différents ?
Le créateur de valeur
L’utilisateur a un problème à résoudre. Pas un « problème informatique », mais juste un « problème » auquel nous tentons de répondre par une solution informatique, à base de lignes de code, de serveurs Linux et de nombreuses Datas.
Dans l’équipe Scrum, le Développeur est un créateur de valeur et pas seulement un fabriquant de solutions (exit la notion de « Digital Factory »). Le Développeur fait du Product Management avec le Product Owner, et non pas pour le Product Owner. Il découvre et clarifie les problèmes à résoudre avec les utilisateurs, imagine des solutions avec ses pairs puis les crée et enfin les délivre pour améliorer le quotidien des utilisateurs. Dans le domaine IT, la création des solutions passe évidemment par le développement de lignes de code informatique, mais elle va bien au-delà puisqu’il faut aussi développer des maquettes, des « business cases », des architectures, des expérimentations, des algorithmes, des scénarios et automates de test, des scripts de déploiement…
On voit bien que la création de valeur passe par la mobilisation de multiples compétences, et qu’on a besoin que le Développeur contribue à résoudre des problèmes et pas uniquement à coder des lignes et des lignes dans son langage favori.
L’apprenti de tous les jours
Le monde est complexe, incertain, en évolution rapide. Ce qui est vrai et connu aujourd’hui ne le sera bientôt plus. De nouveaux problèmes émergent ; de nouvelles technologies se développent quotidiennement.
Le professionnalisme du Développeur l’invite à apprendre constamment. Il se doit d’être responsable de son propre chemin de progression, et pas seulement de se limiter aux rares journées de formation que son employeur veut bien lui payer. Selon ses goûts, il peut participer à des conférences avec ses pairs (ou regarder les multiples replays disponibles, ce qui permet de faire des pauses ou de passer en vitesse accélérée) ; lire des livres et des blogs ; participer à des projets OpenSource ; des hackathons…
Et bien sûr, il va pouvoir apprendre des experts les plus proches de lui, même s’il n’est pas « junior » : ses propres co-équipiers ! Quelles compétences ses co-équipiers ont-ils et qu’il veut développer dans les prochaines semaines ? Réciproquement, quels talents va-t-il pouvoir et devoir diffuser (mentorat ; tutorat…) à ses co-équipiers, même s’il n’est pas « sénior » ?
En effet, il est sain que dans une équipe, les co-équipiers tendent à gommer les disparités de compétences et connaissances pour éviter l’hypertrophie ou l’atrophie de pouvoir chez l’un ou chez l’autre, ce qui déséquilibre et met en danger l’équipe.
Le décideur
Le Développeur dans l’équipe Scrum n’est pas un simple exécutant, ni le fournisseur attitré au Product Owner qui serait son client. La prise de décision est décentralisée dans l’équipe.
L’équipe Scrum dans sa globalité est amenée à prendre moult décisions sur ses processus, sur le produit, sur l’architecture, sur la sécurité, sur la qualité.
Tous les membres de l’équipe doivent participer activement aux débats et prises de décision, s’engager à tenir les décisions de l’équipe.
En tant que membre d’une équipe auto-gérée, le Développeur doit décider et participer à l’établissement des règles et normes de l’équipe, à établir et respecter la charte de travail de l’équipe, tous ces éléments étant la base des prises de décision de l’équipe. Il doit se sentir pleinement responsable des choix fait par son équipe.
Au sens de l’Analyse Transactionnelle et ses trois états du Moi (Parent ; Adulte ; Enfant), le changement de paradigme consiste à sortir de transaction de Parent (incarné par le Manager, le Product Owner, le Scrum Master…) à Enfant (incarné par le Développeur) à des transactions d’Adulte à Adulte dans lesquelles chacun est en interdépendance avec les autres.
La force de l’intelligence collective et de la diversité cognitive dans l’équipe auto-gérée amène à prendre de meilleures décisions plus rapidement.
Le co-équipier
Enfin, le Développeur est avant tout un être humain social, vivant des sentiments et émotions plus ou moins fortes tout au long de sa journée, en particulier au fil de ses interactions avec les autres membres de son équipe et les personnes membres de son écosystème.
Il est un membre d’une équipe dans un écosystème complexe dans lequel la qualité et la quantité des interactions sont cruciales pour que l’équipe puisse remplir sa mission.
En plus de son expertise technique et de son humilité pour accepter d’être « seulement » un petit « moi » dans un « nous » plus grand (son équipe), le Développeur doit également cultiver ses talents de co-équipier pour communiquer efficacement avec ses différents interlocuteurs.
Patrick Lencioni parle ici des trois vertus du co-équipier idéal, citant la modestie, la soif de réussite et l’intelligence sociale.
Le Développeur ne peut pas se contenter d’être un simple expert, rouage d’une machine bien huilée, mais bien un agent actif d’un écosystème humain complexe.
Conclusion
Comment accompagner ces changements de paradigme, en particulier du point de vue de la gestion de carrière, de l’épanouissement personnel, de la quête de sens, de la reconnaissance des talents et compétences attendus qui ne sont plus les mêmes ?
De vastes sujets de préoccupation pour les Scrum Masters, DRH et Managers de toutes nos organisations. Dans vos contextes, comment accompagnent-ils ces changements ? Comment entretiennent-ils un environnement favorable à développer de meilleurs Développeurs.
Et si nous débattions de tout cela dans cette discussion ou autour d’une bière ou à l’occasion d’une de mes formations ?