Bonjour à tous! La semaine prochaine, nous lançons le cours
«Development Manager» , consacré aux activités managériales sous tous ses aspects dans le cadre de la gestion d'une équipe de développement. En prévision du lancement, nous partageons avec vous une traduction de l'article, qui pourrait devenir utile aux futurs chefs d'équipe.
Récemment, beaucoup de choses se sont produites en raison du fait que certaines organisations
passent à Agile , accordant plus d'attention aux équipes auto-organisées, des résultats supplémentaires et une attractivité maximale pour les entreprises. Cependant, chaque fois que quelqu'un lit sur cette transformation, les informations sont généralement présentées en termes d'organisation et comment Agile les affecte en général.
Mais même si de l'extérieur, il peut sembler que l'organisation est une sorte de structure monolithique sans visage, nous savons qu'elle consiste à vivre et à respirer des personnes qui fournissent elles-mêmes les biens et services fournis par l'organisation. Ainsi, il me semble important de considérer comment cela affectera ceux qui doivent gérer leur transformation Agile personnelle.
Je suis impliqué dans la gestion de projet traditionnelle depuis plus de vingt ans. J'enseigne également la gestion de projet et j'ai toujours aimé dire à mes étudiants que la gestion de projet, comme la comptabilité, est une profession mature. Les comptables parlent des débits et des prêts, et la seule chose qui change vraiment périodiquement est le code des impôts. Pendant de nombreuses années, la lingua franca de la gestion de projet a été des artefacts tels que les diagrammes de Gantt et les structures de décomposition des travaux.
Mais dans une large mesure, le sol a commencé à changer sous les pieds des chefs de projet traditionnels (orientés plan ou en cascade), surtout ces dernières années. Cela est dû au fait que l'approche Agile, initialement définie dans le manifeste de 2001, a finalement commencé à prendre pied dans les entreprises. Non, je dirais même à tel point qu'il remplace les méthodes traditionnelles.
Il est suffisamment important que les chefs de projet ne soient pas seulement conscients de cela, mais qu'ils commencent également à penser à l'enseigner et à acquérir de l'expérience. (Sa plus large reconnaissance dans ce bastion de la gestion de projet traditionnelle, la sixième édition de PMI, est un événement assez important.)
Sur le plan personnel, j'ai obtenu la certification
Scrum Master début 2013, mais je ne l'ai jamais utilisée, du moins au début. Ce n'était pas tant que j'étais contre Scrum, mais que je travaillais dans la gestion de projet traditionnelle et que je n'avais vraiment pas assisté à la révolution au premier rang.
Mais progressivement, j'ai commencé à réaliser qu'il y aurait un changement significatif dans la direction de l'utilisation d'Agile et que pour rester pertinent - et, je pourrais ajouter aux plus occupés, il faudrait commencer à se familiariser avec les projets Agile et à y travailler.
En y réfléchissant, je me suis rendu compte que la toute première chose que j'ai dû rencontrer dans Agile était peut-être le fait que le rôle du chef de projet n'est pas seulement si important, mais en fait il n'y a pas de rôle spécifique pour PM en tant que tel. Il n'y a que trois rôles spécifiques dans la variante Scrum - Scrum Master, propriétaire du produit et équipe de développement.
Quand j'ai obtenu la certification Scrum, j'ai déjà réalisé que c'était un type de rôle différent. En tant que chef de projet, je pouvais - et devrais - faire toute la planification avec mon équipe. Mais quand vient le temps de décider qui a fait quoi et quand, c'était toujours mon travail. Il s'agit d'une très grande structure de commandement et de contrôle. Et non seulement je m'attendais à diriger l'équipe, mais l'équipe devait être dirigée.
Mais Agile est différent. Dans ce rôle, je suis plus un assistant ou un coach qu'un guide d'équipe. L'équipe s'auto-organise et cela signifie que même si je peux aider à éliminer les obstacles pour eux, ma tâche n'est pas de leur dire quoi faire en tant que tel. Leur tâche est de savoir quoi faire dans une équipe et Scrum Master pour aider et former.
Vous trouverez ci-dessous quelques conseils utiles sur la façon de réussir la transformation Agile.
Il s'agit d'un changement majeur non seulement pour les chefs de projet, mais aussi pour les équipes. Le chef de projet doit cesser d'être directif et commencer à apporter son aide. Pour de nombreux managers, il s'agit d'une transition très difficile. Ils ne savent pas comment ne pas diriger. Et, très probablement, s'ils sont PM depuis longtemps, ils sont très habitués à utiliser un planificateur tel que MS Project. Mais l'équipe Scrum n'a pas nécessairement besoin d'un tel outil, préférant des outils de workflow comme Jira pour suivre les progrès.
Le problème est que le chef de projet traditionnel doit se retenir en disant à l'équipe quoi faire quand elle le demande. Il ou elle peut supprimer les obstacles lorsqu'ils surviennent. Mais son meilleur conseil lorsqu'on lui demande ce qu'un membre de l'équipe devrait faire est de «partager avec l'équipe». Dans un sens, il ou elle doit repenser ce qu'il sait et jeter certaines de ses compétences par la fenêtre.
Soyez un Scrum Master, pas un Scrum Manager https://t.co/ohOBBzH5Lb #agile #scrum #dev @HyperRTs @DNR_CREW pic.twitter.com/XrmsCAdzwK
- Seth G. (@Nicko_iCorplife) 14 octobre 2017
Et non seulement le Premier ministre peut avoir du mal à s'adapter à cette nouvelle réalité. Imaginez un membre de l'équipe habitué à recevoir des instructions sur ce qu'il faut faire dans un système hiérarchique. Maintenant, il ou elle est confronté à la nécessité d'être indépendant dans une certaine mesure. Certaines personnes préfèrent ne pas vivre cette expérience.
Bien qu'Agile puisse être utilisé pour une grande variété de projets, il est encore largement utilisé dans les environnements de développement logiciel. Et certains développeurs, par exemple, habitués à travailler seuls, doivent désormais rencontrer quotidiennement non seulement l'équipe, mais aussi les «métiers». Pour certains, c'est en dehors de leur zone de confort. J'ai parlé avec une femme lors d'une conférence Agile, qui m'a informé que plusieurs développeurs de son équipe avaient été invités à déménager ou à quitter l'entreprise à l'arrivée d'Agile.
Je pense que la principale conclusion ici est l'acceptation du changement et de l'adaptation. (Ironiquement, les caractéristiques distinctives d'Agile.) Certaines personnes préfèrent simplement faire les choses comme elles l'ont toujours fait. Et puis, lorsque le changement les dépasse - comme, bien sûr, cela se produit dans un monde agile - ils ne peuvent pas apporter de changements et se retrouver à l'extérieur, regardant vers l'intérieur.
Dès que j'ai réalisé que je devais entrer dans ce monde, j'ai fait la transition, non seulement en apprenant, mais aussi en utilisant une pensée flexible. (C'est exactement ce que les équipes de formateurs Agile aident.) J'ai commencé à lire tout ce que je pouvais, j'ai fait du réseautage autant que possible, puis, le moment venu, j'ai envoyé ces connaissances et mes années de gestion de projet à une entreprise qui, étant Agile-ready, encore vu la valeur des deux approches. Et quand j'ai abandonné le besoin de contrôler la situation et que j'ai réalisé que je devais être entraîneur et assistant, j'ai trouvé que tout était en place.
Traditionnellement, nous attendons vos commentaires et nous vous invitons à
une leçon ouverte qui aura lieu aujourd'hui par
Stanislav Mikhalsky , directeur du développement chez Biglion Technologies.