L'agile est-il insoutenable ?
19 April 2010
Article originellement publié sur le blog de Neoxia, et publié à nouveau ici, pour en garder une trace.
Sur son blog, David Brocard commente un phénomène observé dans des équipes agiles (Scrum par exemple) : une pression et un rythme insoutenable pèsent sur l’équipe. À mon sens, ceci est la conséquence d’un héritage des approches classiques, et d’un oubli de certains principes qui font l’Agilité. Voyons cela plus en détail.
Le Manifeste agile rappelle qu’il est préférable d’avoir un rythme supportable et régulier. Pourtant, dans les faits, cela n’est pas toujours le cas. En cela, l’observation faite par David est irréfutable. Il faut avouer que le terme sprint est parfois mal interprété, et ce, malgré le sens que Ken Schwaber a souhaité lui donner.
Plusieurs causes peuvent être à l’origine de cette situation :
- l’influence des leaders lors de la prise d’engagement,
- la surcharge de travail quotidienne,
- le manque de recul du product owner,
- et le mode de contractualisation de l’Agile, en cas d’externalisation.
L’influence des leaders
Dans Scrum, c’est lors du sprint planning que l’équipe s’engage sur les users stories qu’elle va développer lors de l’itération.
À ce stade, il faut faire très attention à l’influence que peuvent avoir certains membres de l’équipe sur l’engagement. Ce sont généralement des fortes personnalités qui se démarquent dans l’équipe. Sous leur influence, les autres membres peuvent se sentir ‘sous pression’, et accepter des engagements qu’ils ne pourront tenir.
C’est alors au Scrum Master de s’assurer que les plus timides donnent leur avis, et que les moins discrets leur laissent suffisamment de champ pour s’exprimer.
La surcharge de travail quotidienne
L’efficacité au travail, appelons-le focus factor, oscille entre 4 h et 6 h, pour une journée de 8 h. Le reste du temps est passé à répondre aux e-mails, et au téléphone, et aux pauses-café, etc. Le focus factor le plus élevé a été observé chez Toyota : il est de 80%.
Certaines équipes se sentent obligés de forcer l’allure pour tenir des engagements difficilement tenables. Elles en viennent donc à travailler entre 10 et 12 h par jour ; elles pensent ainsi augmenter le temps de travail effectif. Mais il est illusoire de penser que le focus factor reste le même, en pourcentage, sur une durée de travail de 12h. Le temps de travail effectif n’augmente que très faiblement.
L’un des outils sur lesquels l’Agile s’appuie énormément est la timebox. Son utilisation ne doit pas se limiter à l’itération ou au sprint planning, mais également s’appliquer à la journée. Une journée de travail, c’est 8h. Travailler 10 ou 12 h par jour, simplement pour tenir les délais, est finalement un mensonge que l’on fait au product owner, et surtout à soi-même. Le mensonge consiste à dire que l’engagement pris sur le sprint backlog est tenable, bien qu’il repose sur un rythme infernal. Et finalement, le product owner s’habitue à un rythme, et il ne comprendrait pas que ce rythme baisse.
Ce qu’il faut, ce n’est pas que l’équipe travaille plus longtemps, mais qu’elle soit plus efficace dans son utilisation du temps, notamment en éliminant le gaspillage. C’est encore au scrum master d’y veiller.
L’aménagement d’un temps off en fin d’itération peut également permettre à l’équipe de débrayer avant de repartir de plus belle. Cela permet à chacun de revenir sur certains aspects plus techniques, ou même d’assimiler réellement ce que l’on a appris rapidement lors de l’itération.
Le manque de recul du product owner
La pression sur l’équipe peut également être le fait du product owner. L’une des principales difficultés dans la mise en place de Scrum, notamment, c’est l’apprentissage du rôle de product owner. Les product owners sont bien souvent des ex-fonctionnels, et peu d’entre eux ont réellement une vision produit. Certains product owners tombent toujours dans l’écueil du « toutes les fonctionnalités sont indispensables ».
Or, comme le rappelle l’étude du Standish Group, 60% des fonctionnalités d’une application sont très rarement (1 à 2 fois par an), ou pas du tout utilisées. Pour vous en persuader, faites le sondage chez vous !
Là encore, c’est le scrum master qui doit accompagner le product owner, pour éviter qu’il ne parte dans tous les sens, et perde la confiance de l’équipe. Il doit amener le product owner à se recentrer sur ce qui est essentiel dans le produit.
Le forfait et l’Agile
La contractualisation de l’Agile est un sujet qui donne lieu à de nombreux débats. Pour moi, il est clair qu’il faut définitivement tirer un trait sur la contractualisation en mode forfait, telle qu’elle existe aujourd’hui. L’engagement strict sur le périmètre, y compris sur l’itération, a deux effets pervers qui vont à l’encontre des principes agiles :
- Si l’équipe est en retard, elle a l’obligation de tout finir pour la date prévue, malgré les imprévus. Et les conséquences de cela, on les connait. C’est encore la qualité qui va en prendre un coup. On retombe dans les mêmes travers que les approches classiques.
- Si l’équipe est en avance, car elle a sous-estimé son engagement, elle n’a aucun intérêt à intégrer de nouvelles fonctionnalités.
Il faut plutôt aller chercher du côté des solutions comme le target price, qui permettent un partage du risque en cas de retard, et un intéressement partagé en cas de réalisation supplémentaire.
Le lièvre ou la tortue ?
Tout le monde en est conscient, un rythme raisonnable et régulier (quitte à ralentir) est préférable à un rythme infernal et instable.
L’un des intérêts du développement itératif est de permettre d’évaluer plus précisément le travail à réaliser. Les estimations sont ainsi plus précises, parce que portant sur un intervalle de temps plus court, et basées sur l’expérience.
Mais, le fait que l’équipe soit constamment sous pression, avec des surcharges importantes et à répétition, nuit gravement à cette prédictibilité.