Le mythe et la réalité

Dans le cadre de vos projets en SCRUM, vous avez forcément déjà entendu des affirmations du genre « nous fonctionnons sur un mode agile donc nous ne pouvons pas vous dire à quelle date nous livrerons cette fonctionnalité puisque nous nous adaptons au changements fréquents qu’on nous demande de prendre en compte ».

Comme si la contrepartie de cette adaptation au changement était une incapacité à prendre des engagements ou à donner de la visibilité sur l’avancement du projet.

Non seulement cette affirmation est fausse (comme nous le verrons un peu plus loin) mais elle est également délétère quant au développement et à la crédibilité de l’Agilité dans les entreprises, en particulier dans celles qui peinent à la mettre en œuvre.

Nous allons voir un peu loin dans cet article qu’il est possible de prédire des dates de livraisons et de passer en revue les moyens à mettre en œuvre pour y parvenir. Pour cela, imaginons le contexte suivant :

Un Product Owner exerce au sein d’une équipe SCRUM et on lui impose un engagement à date et à périmètre fixe. Il a beaucoup de pression et on lui fait bien comprendre qu’atteindre cet objectif est impératif.

Comment gérer cette situation ? Quelle stratégie mettre en place pour construire une réponse qui tienne compte de ce que l’équipe est réellement capable de produire tout en satisfaisant au plus près les critères de cette demande (périmètre et date fixe) ?

 

Comprendre les enjeux

L’enjeu essentiel pour le Product Owner et son équipe tient à sa crédibilité : construire sa crédibilité auprès des stakeholders c’est tenir ses engagements au fil du temps et le faire savoir (tenir ce que l’on a promis avec le meilleur niveau de qualité possible et le faire sur la durée, à un rythme soutenable).

La fiabilité avec laquelle on maintient ce niveau de maitrise génère un niveau de confiance croissant qui servira de fondement à la crédibilité recherchée.

 

Le commanditaire n’a souvent aucune idée de la capacité de production d’une équipe, sa principale motivation est d’avoir la totalité de ce qui est demandé à la date exigée. De son côté, le devoir d’une équipe SCRUM est de fournir rapidement la meilleure réponse possible qui permettra de satisfaire (ou d’être au plus près) de l’objectif à atteindre. Cela inclut la capacité de dire non à ce qui ne parait pas raisonnable et d’accepter d’être challengé sur les éléments de réponse fournis. L’expression meilleure réponse possible correspond à la précision avec laquelle on se projette dans le futur en se basant sur une capacité à produire fiable et prédictible.

 

Connaitre ses limites

L’équipe Scrum doit connaitre ses limites afin de construire une réponse objective et chiffrable sur la base de fait mesurables et objectifs. La première question posée à laquelle il faut pouvoir répondre étant : sommes-nous capables de fournir la quantité de travail nécessaire à la livraison de ce qui est demandé à la date fixée mais sans sacrifier le niveau de qualité du produit.

Si l’équipe SCRUM n’en est pas capable alors dans quelle mesure en est-elle éloignée et sur quoi peut-elle raisonnablement s’engager ? Dans tous les cas, la réponse doit être rapide : il n’est pas question de répondre dans des délais qui mette en péril la date de livraison exigée par exemple (auquel cas, fournir une réponse n’a plus vraiment d’intérêt).

 

Construire sa réponse à partir d’éléments mesurables

Parmi les artefacts que l’approche SCRUM fournit, la vélocité est un des éléments important qui va nous servir à construire une visibilité sur les futures dates de livraison. Pour cela prenons les hypothèses suivantes :

• La vélocité est stable
• Le backlog décrit le périmètre fonctionnel demandé et est complètement estimé
• La durée d’un sprint est de deux semaines
• Soit V cette vélocité de l’équipe de développement
• Soit B le nombre total de stories points que représente le backlog

Il faudra donc B / V = N sprints pour livrer l’ensemble des fonctionnalités décrites dans le backlog, c’est-à-dire 2N semaines pour effectuer la livraison correspondante. Si on démarre le premier sprint à la date « t » alors il est alors inutile de s’engager avant la date « t + 2N ».

Remarque: un premier constat permet de se rendre compte que si nous voulons être en mesure d’effectuer cette prédiction alors il faut absolument avoir une vélocité stable et un backlog complètement estimé rapidement.

 

Estimer rapidement un backlog

Il existe une technique qui s’appelle « eXtreme cotation » et qui consiste à paralléliser le travail d’estimation auquel toute l’équipe SCRUM participe. On travaille sur l’ensemble des Epics qui représentent le périmètre fonctionnel demandé (si le besoin n’est pas exprimé sous cette forme alors il faudra préalablement générer l’ensembles de Epics avec l’équipe).

D’une manière rapide, on procède de la manière suivante (le détail du processus est décrit dans deux articles que vous trouverez en référence à la fin de cet article) :

1. On dispose sur un mur l’ensemble des Epic sous la forme de post’it (titre + description) ainsi que l’échelle d’estimation utilisée par l’équipe (SP, taille de T-shirts, …).
2. Le PO présente rapidement les Epics à l’équipe
3. Sans parler, chaque personne vient poser les post’it sous la valeur d’estimation qui lui parait la plus juste (la valeur correspondante est notée sur les post’it)
4. Une fois que tous les post’it ont été traités, l’ensemble de l’équipe déplace les post’it (toujours sans parler) vers la valeur qui lui parait mieux correspondre. La nouvelle valeur est notée sur le post’it.
5. On met de côté les post’it qui n’ont pas changé de valeur
6. Seulement à cette étape, l’équipe échange sur les raisons qui ont conduit à changer la valeur des post’it de manière à s’entendre sur la valeur finale à donner à chacun des post’it restant.

On ne demande pas d’engagement à l’équipe, l’objectif est d’obtenir une estimation macro dans un laps de temps réduit. Une estimation plus précise sera effectué durant le travail de grooming lorsque les sprints de réalisation seront lancés.

 

Définir un sprint au plus tôt et au plus tard

La limite de l’exercice vient du fait qu’on manipule une valeur moyenne de vélocité alors qu’on sait que cette valeur peut varier de manière relativement importante d’un sprint à l’autre. Il peut donc être intéressant de se faire une idée de la précision avec laquelle on est capable d’estimer un sprint de livraison sur la base de la vélocité d’une équipe SCRUM en prenant en compte cette variabilité. Pour cela on va utiliser des courbes de Burn Up qui seront construites à partir des valeurs de vélocité constatés sur les 12 premiers sprints.

Pour fixer les idées nous utilisons une feuille Excel afin de construire les courbes de Burn Up, pour simuler les variations de vélocité et leur impact sur les projections de sprint de livraisons envisageables.

Le fichier Excel qui sert d’exemple se trouve ici.

ReleaseBurnUpSimulatorV1.0

Revenons à la situation où se trouve le Product Owner. La feuille Excel simule un contexte ou à l’instant « t », le développement en cours correspond au sprint 12 et le périmètre fonctionnel à atteindre se situe au niveau de 180 story points (SP) avant l’arrivée de la demande urgente. La demande urgente, une fois estimée, corresponds à un périmètre fonctionnel additionnel de 120 SP qui devra être livrée impérativement pour sprint 19.

La vélocité de l’équipe étant de 10 SP par sprint avec un écart max entre deux sprint de 5 SP (on est dans le cas d’une vélocité non stabilisée variant entre les limites de 5 SP et 15 SP). En reprenant les valeurs min et max de la vélocité on peut alors tracer deux droites (rouge et verte) permettant de se projeter sur les prochains sprints. Les dates auxquelles les droites rouge et verte coupent la ligne de 300 SP (objectif initial 180 SP + nouveau périmètre demandé 120 SP) correspondent aux sprint au plus et au plus tard que nous cherchons à définir.

On se rend compte au passage que le sprint 19 ne sera pas tenable même en étant très optimiste (droite verte obtenue en prenant l’hypothèse d’une vélocité max pour chacun des futurs sprints).

Arrêtons-nous un instant sur le fonctionnement de la feuille Excel.

• Dans l’onglet « Sprint » se trouve le calcul du nombre de SP réalisé par sprint à partir des valeurs min et max de vélocité.
• La valeur de la vélocité et sa variation (Ecart) peuvent être modifiée dans l’onglet « Projection ». Case B4 de l’onglet « Projection ».
• Scope 1 correspond à 180 SP et scope 2 correspond à 300 SP.
• L’écart (exprimé en nombre de sprints) correspond à la précision avec laquelle l’estimation du sprint de livraison est effectuée (si Ecart =0 alors « sprint au plus tôt » = « sprint au plus tard » = « sprint de livraison »). Voir « Erreur » en cases G2 et G3 de l’onglet « Projection ».

La feuille de calcul est conçue de manière à introduire un aléa sur la valeur de vélocité de chacun des 12 premiers sprints (l’ampleur de cet aléa est ajustable par la valeur donnée à Ecart en case B4 de l’onglet « Projection »). Donc à chaque fois que l’on fait <CRTL-S> sur la feuille Excel, on génère un autre ensemble de valeurs de vélocité qui vont influer sur les valeurs min et max de la vélocité.

Que se passe-t-il lorsqu’on compare le cas de figure où l’équipe SCRUM a une vélocité stable (Ecart = 1) à celui où la vélocité n’est pas stable (Ecart = 5) ? Pour cela, regarder :

1. Les valeurs de « Erreur » pour le scope 2 qui correspond au périmètre devant être livré (case G3 de l’onglet « Projection ») à chaque fois que vous faites <CRTL-S>.
2. L’allure des droites rouge et verte.

On constate que lorsque la vélocité est stable, l’écart entre le sprint au plus tôt et le sprint au plus est réduit dans des proportions importantes (graphiquement l’angle que représente la droite rouge et la droite verte est plus faible).

L’importance d’une vélocité stable est donc primordiale quant à la précision avec laquelle on va pouvoir estimer un sprint de livraison. En terme de prédiction, la stabilité de la vélocité est plus importante que sa valeur absolue. Dit autrement, si l’obtention d’une grande valeur de vélocité se fait au prix d’une grande variabilité alors l’erreur sur la prédiction sera d’autant plus grande.

Arrivé à ce stade, deux cas de figure se présentent. Soit la date à laquelle je peux m’engager est antérieure à celle imposée (je peux m’engager en répondant à la demande telle qu’elle est exprimée), soit elle correspond à une date postérieure (je ne suis pas en mesure de m’engager tel quel) mais il faut quand même proposer une alternative.

 

J’ai la capacité à tenir l’engagement

Cela signifie qu’à partir de la date que l’on m’impose, il est possible de définir un sprint sur lequel s’engager. Il restera malgré tout à challenger cette date en considérant les périodes de congés durant cette période, les formations, et éventuellement une analyse des risques liés à des aspects techniques du développement (nouvelle technologie, migration dans le Cloud, …) ou à l’environnement dans lequel le projet se déroule (engagements pris ailleurs, salon professionnel, …).

 

Je n’ai pas la capacité à tenir l’engagement

Le moment de la négociation finira bien par arriver alors autant se tenir prêt à fournir des arguments défendables et proposer des solutions alternatives viables. Le release Burn Up est un bon outil sur lequel basé sa communication et expliquer les raisons pour lesquels on ne peut pas satisfaire la demande telle quelle. Elle montre en passant que l’équipe se donne les moyens de piloter ses activités, respecte les principes de transparence et fournit des moyens factuels de se projeter dans l’avenir.

Parmi les alternatives les plus classiques on trouve (non exhaustif) :

• Réduire le périmètre et conserver la date de livraison: c’est la solution la plus raisonnable lorsque les contraintes business le permettent. De plus rien n’empêche de livrer le reste à des dates ultérieures, les fonctionnalités livrées en premier lieu ayant été choisie pour leur meilleur ROI (un maximum de valeur pour l’utilisateur pour un minimum d’effort de développement, mis à disposition le plus tôt possible).
• Augmenter la taille de l’équipe : c’est souvent tentant mais c’est une mauvaise idée (à court terme tout du moins) l’impact immédiat sur l’équipe étant fort (accueil et formation des nouveaux arrivants sur le produit et les méthodes de travail). On a un effet inverse de celui recherché la vélocité de l’équipe baisse car elle doit passer du temps à des taches non productives dont le bénéfice ne se verra que plus tard.
• Confier le développement à une autre équipe: c’est un peu une variante du cas précédent puisqu’il faut effectuer un transfert de connaissance vers l’équipe sous-traitante.

 

Les critères de succès d’une telle approche

Un niveau de maitrise élevé

• Une Definition Of Done efficace et une vélocité stable
• Savoir estimer rapidement un backlog : l’eXtreme cotation
• La stabilité de l’équipe dans la durée
• Sans oublier les autres bonnes pratiques liées à XP, à la maitrise de la dette technique, à DevOps …

 

Anticiper

Ce n’est pas le jour ou arrive une demande de développement urgente qu’il faut se mettre en ordre de bataille pour se positionner rapidement vis-à-vis de la demande. Etre en mesure d’établir une vélocité stable prends du temps (environ trois à quatre sprints) et n’est possible qu’avec un bon niveau de maturité agile. C’est un levier efficace pour renforcer la motivation intrinsèque de l’équipe SCRUM tout entière et un moyen efficace pour la faire progresser. Une vélocité digne de ce nom ne peut s’entendre qui si une Defintion Of Done efficace est mise en place.

L’estimation complet, d’un backlog sa priorisation passe par la maitrise de techniques et d’outils (Xtreme cotation, WSJF, …) qui nécessite un temps d’apprentissage et d’expérimentation avant d’être utilisés efficacement. De la même façon, maintenir un backlog bien ordonné permet de mieux estimer l’impact d’une nouvelle demande sur des objectifs en cours.

 

Conclusion

Il est tout à fait possible de s’engager sur des dates de livraisons en mode agile, d’évaluer le challenge que cela représente et enfin de tenir cet engagement. Cependant, pour être en capacité d’évaluer avec une bonne précision les dates de livraison en mode agile il faut impérativement :

• Une vélocité stable (Scrum Master et équipe de développement)
• Un backlog complètement estimé qui décrive le périmètre fonctionnel à livrer (Product Owner et équipe de développement).

Le fait de devoir maintenir un backlog à jour et une vélocité stable représentent un défi important à atteindre pour une équipe SCRUM. Ces contraintes fortes représentent aussi un levier très puissant au service du Scrum Master pour faire évoluer son équipe SCRUM vers plus de maitrise et de maturité agile.

La régularité avec laquelle l’équipe tiendra ses engagements renforcera sa crédibilité auprès des stakeholders même si ceux-ci ne sont pas pleinement satisfait de ne disposer dans un premier temps que d’une partie du périmètre fonctionnel attendu. Ils auront alors des éléments factuels pour prendre les décisions adaptées aux objectifs qu’il se fixent (passer à l’agilité à l’échelle ou se contenter d’un périmètre moins large mais avec un délai plus court par exemple).

 

Références

Burn Up vs Burn Down chart

http://www.clariostechnology.com/productivity/blog/burnupvsburndownchart

L’eXtreme Quotation : le planning agile «cartes sur table»

https://blog.octo.com/extreme-quotation-planning-agile-sous-steroides/

Estimer la complexité de son backlog : tout un défi

http://blog.thiga.fr/product-management/extreme-quotation-estimer-la-complexite-de-son-backlog/

Scrum Life #31 — Estimer un backlog entier en 1 heure avec l’atelier Extreme Quotation

https://jp-lambert.me/scrum-life-31-estimer-un-backlog-entier-en-1-heure-avec-latelier-extreme-quotation-dce141291b3c

Stabilizing Your Velocity

https://medium.com/@mdalmijn/stabilizing-your-velocity-4639e27f713b

Prioriser par coût du retard (cost of delay) | Excellence Agile

https://excellenceagile.com/2017/08/29/prioriser-par-cout-du-retard-cost-of-delay/

DoD Definition Of Done

https://www.sodifrance.fr/blog/dod-definition-of-done/

What is Extreme Programming?

http://ronjeffries.com/xprog/what-is-extreme-programming/

Agile Product Ownership in a Nutshell

https://www.youtube.com/watch?v=502ILHjX9EE

 

Sujets de réflexions

• Avez-vous des équipes de développement dont le turnover est important. Dans ce cas quid de la vélocité stable et de la capacité de l’équipe à être prédictible ?
• Quel est l’impact de l’absence de Vision sur la prédictibilité de l’équipe ? Sur la négociation avec le donneur d’ordre ?

 

read more

« Il n’y a pas de vent favorable pour celui qui ne sait pas où il va. » (Sénèque).

La vision produit est la réponse opérationnelle à la stratégie business de l’entreprise. Elle fait le pont entre cette stratégie et la roadmap du produit.

La vision produit se doit de répondre aux questions suivantes :

• Quel problème essayons-nous de résoudre ?
• Pour qui résolvons-nous ce problème ?
• Quelle solution apportons-nous à ce problème ?
• Comment allons-nous mesurer le succès de ce que nous faisons ?

Avoir une vision produit claire permet entre autres :

• D’accorder les parties prenantes (marketing, finance, équipes techniques). Elle contribuera à guider et fédérer les acteurs du projet.
• De garantir la motivation des équipes : sans objectif, sans vision partagée, l’équipe ne saura pas précisément où aller, dans quel but, ni comment y aller. Du retard peut être pris en début de projet, parce que l’équipe n’a pas connaissance de cette vision ; elle est alors hésitante, refusant de prendre le risque de se fourvoyer dans une mauvaise direction.
• D’anticiper les choix technologiques en fonction de cette vision.

La Stratégie produit et sa communication dans l’entreprise s’exprime souvent en termes de vision lorsque l’on parle d’innovation. La vision fixe le cap, elle donne du sens et décrit ce qu’on entrevoit pour le produit à court, moyen ou long terme.

« Fits in a shirt pocket, syncs seamlessly with PC, fast and easy to use, no more than $299″

A l’instar de la vision d’Hawkins pour le Palm Pilot en 1994, la vision produit est concise, souvent liée à un problème et pilotée en termes d’objectifs. Cependant, la vision produit n’aura de sens et ne sera fédératrice que si elle portée et partagée, permettant ainsi aux équipes de se projeter dans le futur.

La vision facilite les choix auxquels sont confrontées les équipes de développement dans leur recherche de solutions en leur fournissant un repère sur ce qu’ils peuvent envisager (ou pas) dans quelles directions ils peuvent s’autoriser à explorer des pistes sans craindre de voir leur choix remise en cause (et donc de perdre du temps).

read more

La rétrospective est l’un des moments phare d’une démarche agile. C’est à ce moment que l’équipe se réunit et fait le bilan de la période écoulée. L’objectif en est simple, fêter les victoires et les points positifs et chercher ensemble les solutions à apporter sur les éléments empêchant l’équipe de tenir ses promesses et de travailler dans un environnement sain et bienveillant

Les 5 règles d’or de la rétrospective : avant de démarrer une rétrospective, quel que soit son format, des règles claires doivent être partagées et acceptées par l’ensemble des participants.

• Assurez-vous que tout le monde peut s’exprimer librement, il ne faut pas que l’équipe ait l’impression que ses paroles sortiront de la salle de réunion et qu’elles auront des conséquences. Au début d’une rétrospective, rappelez systématiquement que cette règle de confidentialité s’applique à la réunion.
• Ne défendez pas votre ordre du jour La rétrospective n’est pas le moment de parler de choix techniques ou technologiques.
• N’accusez personne et ne laisser personne le faire. Personne n’est coupable. La rétrospective est avant tout un moyen d’améliorer la performance de toute l’équipe.
• N’acceptez pas les déclarations vagues. Il est important que chacun décrive exactement son point de vue ou son problème. Ne pas tomber dans le piège des non-dits ou des allusions.
• Faites-en sorte que chacune des actions à entreprendre soit attribuée à un membre de l’équipe et qu’elle rentre dans le processus de développement du projet. Personne ne voudra s’attaquer à la mise en place d’actions non répertoriées et non estimées.

D’après Mariah FRIH dans son article « Donner du peps à vos rétrospectives », les 5 règles d’or d’une rétrospective. http://blog.thiga.fr/a-la-une/product-owner-donnez-du-peps-a-vos-retrospectives/

Ensuite, une rétrospective va toujours suivre 5 étapes clés :

1. On lance la rétrospective et on met en place un environnement bienveillant et adapté,
2. On recueille des informations (positives, négatives) issue des membres de l’équipe,
3. On passe à l’analyse des informations récoltées,
4. On décide des actions à mettre en œuvre pour améliorer le fonctionnement de l’équipe,
5. On termine la rétrospective, avec un vote de satisfaction de l’équipe sur son déroulement (ROTI).

Important : ne jamais perdre de vue que l’objectif d’une rétrospective est de définir un plan d’action visant à améliorer le fonctionnement de l’équipe.

Le Speed boat

Méthode « Speed boat »

Source du support : XEBIA (article « la rétrospective : le format speed boat » par Olivier Marquet).

https://blog.xebia.fr/2015/03/20/la-retrospective-le-format-speed-boat/

 

Dans ce format de rétrospective, on trouve :

• Les objectifs à atteindre, représentés par l’île ;
• Les forces nous permettant d’atteindre les objectifs, représentées par le vent qui pousse le bateau ;
• Les freins et obstacles qui vont nous empêcher d’atteindre nôtre Ile, représentés par l’ancre ;
• Les risques pouvant potentiellement nous freiner dans l’atteinte de notre objectif, représentés par les récifs.

L’équipe est représentée par le bateau, avec l’image donnée à chaque membre que nous devons tous travailler ensemble pour que ce bateau puisse atteindre l’île, quel que soit notre rôle, nos responsabilités. Cela implique d’apprendre à se parler avec confiance et bienveillance.

Star Fish (Keep / Drop / Start)

Cette méthode permet de collecter les idées de l’équipe et permet à chaque membre de mieux comprendre l’intérêt des bonnes pratiques.

• Continuez à faire : quelque chose que l’équipe réussie bien et dont on reconnait la valeur
• Moins de : quelque chose de déjà fait ; on constate une certaine valeur mais on souhaite le réduire un peu
• Plus de : quelque chose de déjà fait et dont on pense qu’elle apportera encore plus de valeur si davantage utilisée.
• Arrêtez de faire : quelque chose qui n’apporte pas de valeur, ou encore pire, qui empêche de progresser.
• Commencer à faire : une nouvelle idée, ou quelque chose que vous avez vu marche et que l’on souhaiterait essayer.

Chaque membre va indiquer, sur un post-it, les pratiques, activités, comportements, qu’il souhaite garder ou arrêter ou les choses qu’il voudrait tester sur les prochaines itérations.

Chaque membre va prendre 5 minutes pour identifier au moins un sujet par thème. A l’issue de cette période, chacun va venir poser ses post-it, dans le thème correspondant (peu importe l’ordre), en expliquant ce qu’il a écrit. C’est un moment où chacun peut échanger librement sur les sujets abordés.

A l’issue de cette phase de présentation / discussion (15-30 min), l’équipe va identifier les sujets qu’elle accepte d’abandonner et ceux qui doivent être commencés (1-2 maxi). L’idée n’est pas d’accepter d’abandonner ou de commencer un sujet parce qu’il est inscrit sur un post-it. Cette décision doit faire l’objet d’un consensus de l’ensemble de l’équipe, avec une période de transition, qui va permettre de mesurer l’efficacité de l’ajout d’une nouvelle pratique ou de l’abandon d’une autre.

Il est recommandé de pratiquer cet exercice à un rythme régulier.

Conclusion

Il existe bien d’autres formats de rétrospective, chacun avec des objectifs différents. Changer fréquemment de format permet à l’équipe de rester constamment en éveil sur le fonctionnement de sa boucle d’amélioration continue et également de s’adapter aux événements et au contexte vécu par l’équipe.

read more

ROTI est l’acronyme pour Return On Time Investment. C’est un vote rapide à 4 doigts qui permet d’obtenir un feedback rapide sur le déroulement d’une réunion.

4 doigts = Excellent : très bonne réunion qui valait le temps qu’on y a passé,

3 doigts = Bon : j’ai gagné plus de temps que j’en ai passé mais sans plus,

2 doigts = Pas terrible : ça ne valait pas le temps que j’y ai consacré,

1 doigt = Pas satisfait : j’ai perdu mon temps,

Il n’y a pas de niveaux « neutre » afin d’obliger les participants à faire un choix véritable. Une fois le vote effectué, on interroge seulement les participants qui ont voté 1 ou 2 pour comprendre les raisons de leur vote.

read more

Un Burndown Chart est un graphique simple qui indique le degré d’avancement dans la réalisation des tâches. En d’autres termes, c’est une représentation graphique de l’évolution de la quantité de travail résiduelle en fonction du temps, sur une période donnée.

Le Burndown chart est utile car il offre une vision rapide de l’état d’avancement des travaux. Il définit ainsi la performance collective de l’équipe. Il est actualisé tous les jours lors du Daily meeting. Et, il est accessible à toutes les parties mobilisées sur le projet.

En début du Sprint, il est nécessaire d’initialiser le Burndown chart en positionnant l’échelle du temps en abscisse et, le nombre de tâches en ordonnées

Burndown chart (1/3)

Il faut positionner le premier point sur le nombre total des tâches. Ce point sera le point de départ pour la droite d’évolution idéale, ainsi que de la courbe réelle.

Ensuite, il faut tracer la droite qui part du premier point et qui rejoint le dernier point. Ce dernier a les coordonnées suivantes : abscisse : le dernier jour du temps imparti. Ordonnée : 0

Burndown chart (2/3)

Un bilan des activités se fera lors du Daily meeting. On constate alors par ce moyen, le nombre de tâches à achever à la charge de l’équipe. Puis, une fois que le total des tâches restantes à exécuter est calculé, il faut positionner un nouveau point sur le graphique, selon les coordonnées suivantes :

• Abscisse : date du jour
• Ordonnées : somme des tâches restantes

Enfin, il suffit de tracer la ligne entre le point précédent et le nouveau point. Et ainsi de suite.

Burndown chart (3/3)

On constate en général, dans la première partie du graphique, que la descente est assez faible. Cela est lié à la découverte de nouvelles tâches en démarrage de Sprint, ou à certaines tâches commencées qui se révèlent plus compliquées que prévu.

Le Burndown chart est un indicateur visuel de la quantité de travail qui reste théoriquement à faire pour terminer le Sprint.

Il pousse à évaluer quotidiennement le travail en instance d’achèvement.

read more

La gestion même du projet peut sembler se complexifier au regard des ajustements continuels entre les contraintes de délais et de budget. Les risques se multiplient, du fait même de cette gestion, et alimentent les difficultés du Chef de Projet.

C’est dans ce cas précis que la philosophie « agile » prend tout son sens. C’est une approche où le changement et les adaptations sont intrinsèques à l’organisation. Ils sont donc acceptés et mis en œuvre plus facilement par les acteurs du projet.

Dans le domaine informatique par exemple, le rapport CHAOS, publié en 2015 par le « Standish Group » (rapport réalisé à partir de 50 000 projets de développement logiciel à travers le monde.), celui-ci confirme que le taux de réussite des projets « agiles » atteint 39% (toutes tailles de projets confondues) contre 11% de réussite pour les projets en méthode « classique ».

https://www.infoq.com/fr/articles/rapport-chaos-2015

Le travail collaboratif et les itérations réalisées tout au long du projet permettent de rectifier les erreurs au plus tôt dans le projet et plus régulièrement que dans le cadre d’une gestion de projet « classique ».

On favorisera les équipes de petite taille (10 personnes environ) ayant si possible un profil polyvalent. L’expertise de chaque intervenant du projet est un des éléments essentiels et nécessaires pour la réussite d’un projet « complexe ». On conservera si possible la même équipe tout au long du projet.

Autres facteurs impactant les délais

Les erreurs ou omissions dans la définition des objectifs, la disponibilité des ressources, le pilotage des réalisations, etc., sont autant de facteurs de risque menaçant les projets. La première cause de dérive des projets est l’extension des limites du projet au fur et à mesure de sa réalisation : lorsque les limites du projet n’ont pas été correctement fixées, des tendances d’extensions continuelles se manifestent sans que l’on puisse les écarter, faute d’avoir défini des frontières contractuelles claires et précises. La gestion quantitative des ressources ne dispense pas d’intégrer les facteurs humains dans la conduite de projet.

L’approche Agile correspond à un ensemble de bonnes pratiques dont le fondement s’appuie sur des études scientifiques ou plus simplement sur des retours d’expérience acquis au fil des années par les communautés de gestionnaire de projets.

Time box

Cyril Northcote Parkinson, après une longue expérience dans l’administration anglaise, déduit en 1958, qu’un travail tend à se « dilater » pour occuper tout le temps disponible. D’où la nécessité de se fixer un objectif temps (réaliste) pour réaliser une tache et de s’imposer des dates limites de fin de réalisation : le time box.

Se fixer un time box c’est se donner une contrainte de réalisation « au mieux » d’un ou plusieurs objectifs dans un cadre de temps immuable et de préférence le plus court possible. C’est pourquoi une itération doit avoir une durée limitée et fixe dans le temps. Cette approche est fondée sur la prise en compte du caractère subjectif de la détermination qu’un travail est effectivement fini : comme on peut toujours tout améliorer, alors on risque de ne jamais rien finir.

Le principe : la date fixée ne bouge pas, le contenu de l’itération est la variable ajustable (on peut par exemple retirer des taches à réaliser dans l’itération n et les passer en n+1). Si le travail n’est pas terminé dans l’itération n comme prévu alors on fait une rétrospective afin et on corrige le tir pour ne pas recommencer la fois suivante. C’est contraignant au départ mais cela oblige à hiérarchiser les objectifs et donne une cadence à l’équipe mais aussi des repères, des deadlines claires.

Le time boxing peut également aider à :

1. Maîtriser le perfectionnisme : en définissant des objectifs SMART à accomplir avant que le temps alloué ne soit terminé, cela permet de prioriser les choses essentielles, d’éviter de se focaliser sur les détails.
2. Augmenter l’efficacité : on se donne une pression saine et suffisante afin d’effectuer le travail demandé dans un laps de temps réduit.

Planification au fil de l’eau

Au démarrage d’un projet, l’incertitude est grande : elle décroit au fur et à mesure que le travail avance. La Figure 11 donne une idée de son évolution au fil du temps : c’est le cône d’incertitude, popularisé par Steve Mc Connell.

En effet, les estimations sont fausses car elles reposent sur des hypothèses, pas des faits. Or, dans les faits, le contexte d’exécution du projet change souvent. Les proportions dans lesquelles cette erreur peut varier est très importante.

Mc Connell1 a travaillé chez Microsoft au redressement des projets en difficulté. Il a tiré de son expérience une observation : plus le projet approche de sa finalisation, plus les estimations qu’on réalise deviennent proches de la durée finale réelle. Le corollaire de cette évidence, c’est qu’au début d’un projet les estimations sont très éloignées de ce que sera la réalité.

Mc Connell a établi des coefficients montrant les variations de l’écart dans le temps du projet, entre les estimations les plus optimistes et les plus pessimistes. Au début du projet, les estimations sérieuses oscillent en 4 fois et 0,25 fois la durée que le projet prendra réellement.

L’écart entre l’hypothèse la plus optimiste et l’hypothèse la plus pessimiste traduit le niveau de risques que l’on prend en compte : un projet se déroule rarement de manière complètement catastrophique, et jamais idéalement non plus.

 

On notera que pour un projet estimé à 100 jours homme, la durée réelle pour un projet réussi au final peut se situer entre 25 et 400 jours homme, soit un rapport de 1 à 16. Ainsi, la fin du projet de d’une durée minimale de cinq semaines peut intervenir entre cinq semaines et un an et demie.

L’approche agile prend en compte cette réalité et s’y adapte en planifiant des itérations sur le modèle du PDCA de Deming. On avance pas à pas, on ne planifie que l’étape à venir et, en fonction des résultats de cette étape et des enseignements tirés, on planifie l’étape suivante.

 

La roue de Deming est un moyen mnémotechnique qui permet de repérer avec simplicité les étapes à suivre pour améliorer la qualité dans une organisation. La méthode comporte quatre étapes, chacune entraînant l’autre, et vise à établir un cercle vertueux.

Sa mise en place doit permettre d’améliorer sans cesse la qualité d’un produit, d’une œuvre, d’un service, etc.

1. Plan : préparer, planifier;
2. Do : développer, réaliser, mettre en oeuvre;
3. Check : contrôler, vérifier ;
4. Act (ou Adjust): agir, ajuster, réagir.

Le fait de procéder par étapes présente l’avantage de ne consacrer l’effort de planification qu’à l’étape qui démarre, sans perte inutile de temps pour élaborer un planning détaillé à long terme totalement hypothétique.

La différence entre une gestion de projet Agile et une approche basée sur une planification traditionnelle peut être représentée sous forme graphique.

Comparaison des approches : Agile et traditionnelle

Remarque importante : l’estimation d’une enveloppe globale est indispensable.

read more