Depuis la mi-2000, “scrum” pour la gestion de projet (GP) règne comme la méthode dominante dans le développement logiciel. Sa structure itérative, les rencontres fréquentes et une hiérarchie claire en ont fait un choix évident pour une industrie sujette aux changements réguliers de besoins et attentes clients. Le résultat en est un usage par la plupart des équipes pour la phase de développement avec une application de gestion de projet basée sur scrum.
Mais, un nouveau joueur entre sur le terrain avec beaucoup à offrir et une renommée grandissante - les outils de management visuel de projet. La gestion visuelle de projet est un usage réactualisé du lean et des premiers outils Kanban, bien que n'étant pas exactement synonymes. Par rapport aux méthodes manuelles, la gestion visuelle de projet de développement mixe les éléments de plusieurs méthodologies pour automatiser et rationaliser les flux existants. Packagé en système virtualisé, elle apporte également la mise à jour en temps réel, les contrôles d'accès sur-mesure, l'analyse de données, etc.
Les responsables d'équipes voulant adopter une gestion visuelle de projet en comprennent bien la valeur, et sont plus circonspects sur la gestion des défis d'une telle transformation. Cet article présente les meilleures pratiques pour réussir une transition douce au sein d'une quipe et retirer un maximum de valeur d'un nouveau système.
Quelle différence avec Scrum
Avec Scrum, les membres des équipes travaillent souvent sur des projets avec un fonctionnement en silos pendant les sprints. Ils collaborent et partagent l'avancement à la fin des sprints ou pendant les daily meetings, qui peuvent prendre du temps dans la journée. La gestion visuelle de projet apporte de la transparence, grâce au suivi en temps réel et la visualisation des tâches, pendant les sprints. Même si cela n'élimine pas complètement le besoin de rendez-vous, cela réduira leur redondance et l'inutilité de certaines - celles qui permettent "d'accélérer".
La gestion visuelle de projet modère le besoin d'incrément produit et souligne celui de travailler à une capacité raisonnable durant la période. Cela signifie que la qualité des stories individuelles est plus valorisée que l'avancement à tout prix. Souvent, la gestion visuelle de projet logiciel positionne même un maximum de travail en cours (le Work In Progress ou WIP - NdT) sur lequel un membre de l'équipe développement devrait travailler (ceci se retrouve dans de nombreux systèmes Kanban, utilisant des "cartes" pour l'avancement des tâches dans un flux reproductible). Il est important que chaque sprint produise des éléments, ce qui ne veut pas dire que la quantité doit surpasser la qualité. Les membres de l'équipe devrait être capable de travailler à capacité optimale et fournir à chaque élément du backlog le juste temps et attention nécessaires.
Pourquoi certains développeurs ne l'aiment pas
La gestion visuelle de projet a ses racines dans la “production lean” — un système de gestion développée par Toyota et largement utilisé dans l'industrie pour baisser les coûts et les gaspillages. Le parallèle implicite entre une ligne de production et le développement logiciel peut déranger certains développeurs étant donné la différence de complexité. Et c'est vrai : pousser un fonctionnement aussi versatile que le logiciel dans un moule aussi rigide ne pourrait pas montrer de résultats positifs.
Les plateformes Kanban simplistes sont souvent mono-dimensionelles et ne fournissent pas le niveau de complexité requis par les équipes de développement pour rester réactif à l'expérience utilisateur et à l'adoption, aux résultats des tests produits, et à un marché qui repositionne en continu la valeur métier.
Ces inquiétudes sont fondées, mais il est important de noter que tous les outils de gestion visuelle de projet se restreignent a des fonctions Kanban basiques. Beaucoup des outils visuels qui se sont révélés utiles dans le monde logiciel (par exemple, Atlassian JIRA, Microsoft Visual Studio, et Axosoft) combinent les meilleurs aspects de Kanban et du lean avec les bases de Scrum utilisées par les équipes, ce que certains appellent parfois "scrum-ban". Ces systèmes hybrides de gestion de projet fournissent aux équipes un contrôle complet sur le backlog, les tests des fonctionnalités, les dépôts de code, les user stories avec l'apport d'outils de visualisation puissants et la capacité de travailler depuis des interfaces centralisées et réactives.
Même en étant convaincu par la théorie, l'implémentation d'un tel système peut paraître intimidant. Il y aura des coûts de licences, des transferts de données, des intégrations à finaliser, sans parler de la formation des équipes sur un nouveau mode de fonctionnement. Ce ne sera pas un parcours de santé, mais avec une stratégie robuste, passer à la gestion visuelle de projet ne va pas gêner la productivité des équipes.
Voici les six astuces pour une transition douce et sans douleur :
1. Poser des attentes claires et réalistes : étant donné que les outils de visualisation en temps réel vont forcément accroître la transparence et la responsabilité, assurez-vous d'avoir des objectifs clairs pour chaque développeur pour chaque sprint. Vos attentes devraient être réalistes, étant donné la durée du sprint et le volume de travail que chaque membre de l'équipe peut gérer.
2. Soyez flexible : appuyez-vous sur la flexibilité que la gestion visuelle de projet apporte, comme la capacité de déplacer des cartes dans différentes "lignes" ou modifier l'assignation aux individus ou des sous-tâches. Ceci aidera vos équipes à faire tomber les cloisons mentales.
3. Utilisez la visualisation du flux pour isoler les zones de problèmes : par exemple - si vous notez qu'une story est continuellement "bloquée" en phase de test ou revient dans un sprint ultérieur du fait de critères non respectés, utilisez un root-cause pour déterminer la raison du bouchon et la redondance.
4. Repensez la manière de prévoir les stories : plutôt que de pousser les user stories aux équipes dans le sprint, laissez-les les tirer du backlog et peupler leurs lignes de travail. Ceci autonomisera les équipes et réduira largement le temps requis pour les rendez-vous de sprint ; vous avez seulement besoin de calculer le nombre total de stories pour garder l'équipe occupée pendant un temps donné et qu'elle se retrouve quand toutes ou la majorité des stories ont été tirées.
5. Assurez-vous que vos tableaux réflètent vraiment le flux : ne vous laissez pas distraire par la nouveauté de la gestion visuelle de projet. Restez sur le cycle de développement que vos équipes connaissent le mieux. Cela vous aidera à vous adapter plus vite et confirmer le retour sur investissement.
6. Poussez vos travailleurs à distance à se connecter : il est fréquent pour les membres d'une équipe (ou l'équipe entière) de travailler sur des créneaux horaires ou des pays différents. Une plateforme de gestion visuelle de projet peut être un outil puissant pour donner aux travailleurs à distance une vision à jour de l'avancement de l'équipe, et la capacité de suivre leur travail.
Etudes de cas
Beaucoup d'organisations ont déjà déployé des outils de gestion visuelle de projet pour améliorer les workflows des équipes et augmenter la quantité et la qualité des éléments en sortie. En voici quelques exemples :
Siemens Health Services
Siemens Health Services (SHS) est un fournisseur de solutions IT pour les entreprises de santé, réalisant du développement logiciel, de l'installation, de l'hébergement, de l'intégration, de la sous-traitance pour les hopitaux et d'autres activités plus larges. Cinquante équipes s'occupent du développement, majoritairement en Pennsylvanie, avec des parties en Inde et Europe.
En 2005, SHS commence à utiliser Scrum et eXtrem Programming pour atteindre leurs objectifs, avec des équipes Scrum, des sprints, revues, rétrospectives et une gestion de backlog. Après six ans d'utilisation de l'agile/Scrum comme premier levier de gestion de projet, SHS continuait à avoir des difficultés à atteindre les dates de livraison sans forte pression ou heures supplémentaires.
Bennet Vallet, responsable des développements agile chez Siemens, explique qu'ils ont décidé d'intégrer des techniques Kanban dans leur processus pour gérer ces challenges. Il écrivait en février :
Tandis que les Scrum/XP classiques proposent beaucoup de pratiques intéressantes, Siemens ne parvenait pas à dépasser les limites permettant d'obtenir des résultats prévisibles, et trouver l'impulsion vers l'amélioration continue dans l'efficacité opérationnelle, et la qualité s'essouflait. [...] De plus, les évaluations s'appuyant sur des tailles de story et les diagrammes de vélocité ne proposaient pas assez de visibilité pour gérer les cycles de livraison à cette échelle.
Ils misèrent le tout pour le tout dans cette transition, déployant Kanban à travers toutes les équipes et zones géographiques, et au niveau de la gestion des programmes.
Les équipes Siemens avaient accès à des outils vaguement visuels pendant les sprints, comme la vélocité ou les burndown charts, mais ces outils leur donnaient une vision biaisée du fait de la disparité entre les types de story. A l'opposé, Kanban, en se concentrant sur le flux continu de travail en cours, apporta la prévisibilité et "une vision sur les problèmes et modèles systémiques de la chaîne de valeur".
Vallet considère que Kanban les aida davantage à incorporer un état d'esprit d'amélioration continue, à atteindre les dates de livraison en réduisant le WIP, et à encourager un environnement collaboratif. Même les équipes hors site se sentirent plus intégrées et à jour durant les sprints. Leur temps de cycle tomba à 43 jours ou moins - une amélioration de 40% - en restant dans des tranches prévisibles.
Vallet raconta à InfoQ que les résultats de ses équipes furent si positifs la première année, qu'ils convainquirent la direction de passer toutes les lignes produit sur un mode de gestion visuelle de projet, impactant plus de 40 équipes sur trois continents.
Il est important de noter que Siemens mis en oeuvre un mélange de Kanban et de techniques agiles plus classiques, comme le développement incrémental de story, le test régulier, l'intégration continue, et les équipes scrum multi-compétences pour atteindre de tels résultats. Malgré les mauvais échos que l'état d'esprit "industriel" a parfois dans l'IT, SHS fit une découverte importante : le processus d'amélioration recquiert de la prévisibilité.
BBC Worldwide
L'étude marquante de 2009 d'une équipe de neuf personnes chez BBC Worldwide présentait les effets du lean et de Kanban sur un processus de développement logiciel sur une période de 12 mois. L'étude était sponsorisée par le IEEE Transactions on Engineering Management et dirigée par Peter Middleton, auteur de Lean Software Strategies, et David Joyce, principal consultant et penseur chez ThoughtWorks.
L'équipe BBC, avec une tradition agile/scrum du développement, commença par utiliser deux tableaux kanban principaux et quatre "radiateurs d'informations", qui sont de vastes représentations graphiques de l'évolution de l'équipe de développement. L'équipe était encouragée à enregistrer toutes les tâches et story en cours sur les tableaux et à ne pas travailler sur les autres.
De façon similaire aux équipes Siemens, l'équipe BBC Worldwide commença à noter un renversement progressif d'un flux poussé à temps fixe vers une nouvelle approche, où les membres ne tiraient le travail qu'en fonction de la capacité disponible, c'est à dire en limitant le WIP. Joyce et Middleton notèrent une constance des temps de cycle et une meilleure aptitude à s'améliorer progressivement, et donc considérèrent ce mode de gestion visuelle de projet comme un succès.
Ils mesurèrent les résultats suivant :
- Une amélioration du Lead time de 37%
- Un accroissement de la régularité dans les livraisons de 47%
- Une diminution des anomalies remontées par les clients de 24%
Par rapport à leur approche précédente scrum-full (où les rétrospectives ne remontaient que des résumés peu satisfaisants sur les stories non livrées), l'équipe BBC atteignit le niveau onirique de "Kaizen".
Bien que ce ne soit probablement par vrai pour toutes les équipes, les outils de gestion visuelle de projet peuvent apporter une plus grande flexibilité dans les cycles de développement et améliorer la qualité de l'ensemble du produit grâce à une répartition plus astucieuse des tâches. Une transformation réussie n'implique pas une refonte complète de vos processus et priorités métier - seulement une intention orientée et bienveillante, et une volonté d'en récolter les bienfaits.
A propos de l'Auteur
Aleksandr Peterson est un analyste des tendances techniques chez TechnologyAdvice. Il s'intéresse à la gamification, relation client, gestion de projet et aux technologies métier émergentes. Il est accessible via LinkedIn.