Programme Valtech Agile Day, 19 Juin, Paris

Suivez le programme

L’effet Big Bang

Cela fait maintenant quelques années que j’aide les entreprises à « passer » à l’agile.

Dans cette démarche, il m’est souvent conseillé de ne pas le faire en mode Big Bang, mais en douceur. Bon, d’abord, c’est moi le consultant qui conseille, non mais, puis quoi encore.

Et là je dis niet, pas de douceur. On n’est pas là pour s’amuser, pour mettre une nouvelle méthode et faire joujou avec les développeurs, leur mettre la pression pour qu’ils développent plus vite et je ne sais quoi encore.

C’est bien pour changer les choses, arrêter de perdre du temps et de l’argent, arrêter d’avoir des chefs de chefs de chefs…  C’est former une vraie équipe autour d'une idée, d'un produit, pour attaquer le marché, pour en gagner des nouveaux ou pour innover qu’il faut de l’agilité.

J’ai été fortement désappointé (je n’ai pas voulu être grossier sur ce point) lorsque j’ai entendu dernièrement qu’une entreprise qui au bout de 4 ans de transformation trouvait encore le scrum meeting comme une augmentation du coût de gestion de projet de 15%.

Dans d’autres entreprises, je me bats pour remplacer les systèmes qualité obsolètes, qui de plus ont été mis en place à fort renfort budgétaire. Qui a déjà mis en oeuvre ISO ou CMMI ? Combien cela vous a coûté, combien êtes-vous prêt à mettre pour passer à l’agilité ? Que vous ont apporté ces méthodes, à part une multitude de  « sachants contrôleurs » non productifs. Tant qu’à mettre des process, allez jusqu’au bout et utilisez la DO178-B, au moins c’est compatible avec l’eXtreme Programing sur le 100% de code testé.
Des additions de process au lieu d’optimisation. Des réunions de 4 heures hebdomadaires de suivi de projet à 15 personnes, alors que l’équipe projet se retrouve seul le jour de la démo. A n’y rien comprendre.

C’est ce que le Lean appelle l’optimisation locale, et qu’il est fortement déconseillé de faire. (Voir Lean Primer)

Je me souviens aussi lorsque Craig Larman est venu agiliser Valtech : « Quoi! Vous n’avez pas d’intégration continue, bon, bein, mettez-la en place, et je reviendrai quand ce sera fait ». (Traduction très adapté du message original, et avec une petite touche du sud-ouest !)

Il faut faire RAZ de tout, remettre notre cerveau à blanc, recommencer à réfléchir, arrêter de subir.

J’ai fort heureusement travaillé avec une entreprise qui a su faire le pas de manière radicale parce que nécessaire à son maintient dans la course, voire à sa survie. « C’est Agile ou rien, pas de plan B ». Oh, bien sûr tout n’est pas rose, ça laisse des traces, mais les principes sont acquis, le changement est en marche et l’entreprise même remonte sur le devant de la scène, renouvelle avec les bénéfices. Et pourquoi, parce qu’ils ont pris exemple sur une de leur entité, une entité de 200 personnes avec 3 managers seulement, qui avait la meilleure rentabilité du groupe et qui pratiquait les méthodes Agiles.

Bien sûr, on ne peut changer une entreprise dans son ensemble en une seule fois. C’est là qu’une approche graduelle doit être mise en œuvre. Du projet à l’entreprise, la route est longue. Mais au moins, à chaque étape de transformation, pensez à remettre les compteurs à zéro et prônez un changement radical. Quelques projets pilotes pour appréhender la capacité de pénétration de la méthode, beaucoup d’évangélisation, souvent par capillarité des pilotes, puis une application graduelle par niveau dans l’entreprise (service, entité, entreprise). Et là rien ne vaut l’expérience, merci Valtech !
Il faut au moins du BigBang sur le périmètre de mise en oeuvre pour s'affranchir des freins et obtenir les gains réels de la méthode.

Attention la prochaine sera BigBang sinon rien. Etes-vous prêt à changer ?

AgileTour Toulouse : Histoire d'une transformation Agile

Voici en ligne la présentation faite par Lionel Molas et moi même à l'Agile Tour Toulouse 2011, le 19 octobre.
Un grand MERCI à l'organisation SigmaT pour cette session très professionnelle.
Un grand MERCI aussi à Valtech, sponsor GOLD de l'édition, sans qui je ne serais rien ;-)
Et bien évidement en énorme MERCI à Lionel et Thierry de m'avoir accompagné dans cette aventure, qui n'est pas terminée.

Vélocité vs Qualité : Rien ne sert de courir, il faut partir à point

Ne pas vouloir augmenter la vélocité sans confirmer la qualité.
Lors d’une transformation  Agile, au début, les équipes n’ont pas encore mise en œuvre toutes les pratiques Agiles à leur disposition  pour garantir la bonne marche du projet et la qualité du produit.

Il est fortement déconseillé de vouloir augmenter la vélocité, et en sous-main la productivité, tant que l’équipe n’a pas en sa possession les éléments de base pour le faire proprement.

En Agile pour encadrer le niveau de qualité, nous utilisons la Definition of done (DoD, Définition de Fini).
Hors la DoD évolue avec le temps. Il est impensable de mettre en œuvre toutes les pratiques Agile en place dès le début du projet. Il faudra des formations, de l’apprentissage, de l’expérience, … en clair du temps.
Ce n’est qu’à partir de la stabilisation de la DoD, que l’on pourra améliorer la vélocité.

La vélocité est une estimation relative qui  tient plus compte du « quoi faire » plus que du comment le faire. Un ratio vélocité/jours.hommes n’a pas de sens dans ce contexte.
Si l’on cherche à augmenter la vélocité avant une stabilisation de la DoD, ce qui se passe le plus souvent est la réduction de la celle-ci entraînant la dégradation de la qualité. En contrepartie, il est plus utile de dégrader la productivité en apportant des pratiques garantissant la qualité sur le long terme. Je sais ça peut choquer !

Il sera temps après stabilisation de la DoD, de regarder quels sont les « gaspillages » à éliminer, seul manière d’augmenter la vélocité proprement tout en garantissant la qualité.

Burndown + Niko-Niko

Toujours dans la série des rétrospectives, un point intéressant est de suivre la tendance.

Le Niko-Niko:

Le Niko-Niko, pratique Lean utilisée en interne des équipes, permet de suivre l’état du ressenti journalier de chaque membre de l’équipe.

Cette pratique présentée par Emmanuel Chenu, a pour objectif « de vérifier la corrélation entre la santé de l'équipe, la santé du projet et la qualité du logiciel »

Une pastille de couleur est placée sur le calendrier en fin de journée par chacun et de manière anonyme.

«

• Une pastille verte indique que le développeur a passé une bonne journée sur le projet. 
• Une pastille jaune représente une journée neutre. 
• Une pastille rouge marque une mauvaise journée. 

»

Niko-Niko : Emmanuel Chenu

Le Burndown + Niko-Niko:

Dans un cadre Agile à l’échelle, il peut être utile de suivre le ressenti de chaque équipe en fin de sprint. L’objectif est d’avoir une tendance synthétique des rétrospective de chaque équipe sur une échelle de temps. L’échelle de temps étant celle des sprints, nous utilisons le burndown et comme dans le Niko-Niko, chaque équipe pose en pastille de couleur en fin de sprint.

Cette vision synthétique des rétrospectives d’équipe décrie une tendance. Cette tendance aide à montrer les risques de déraillements, tant émotionnels que sociaux et productifs : Rythme soutenable, motivation, ambiance d’équipe, collaboration, vélocité. Le burndown étant l’outil qu’affectionnent tout particulièrement les product owners et autres area product owners et scrum masters, c’est un bon moyen pour leur faire passer un message.

Burndown de release + Niko-Niko

Release 0, Sprint 0

Dans les projets Agile, en Scrum notamment, nous démarrons par un sprint 0. D’une durée d’environ 1 à 2 mois, il s’agit de mettre en place l’environnement de travail,  de construire le backlog et de préparer la montée en charge de l’équipe.

Dans le cadre d’un projet de grande ampleur, dit « large scale », (~100 personnes sur 3 ans) la durée du sprint 0 n’est pas suffisante, il faut plus de temps. Pour garder le coté inspection et adaptation, il ne faut pas augmenter la taille du sprint 0 mais plutôt faire une release 0 incluant plusieurs sprints.

Les premiers sprints sont consacrés aux activités plutôt techniques visant à couvrir les risques, c’est la « vision de départ ». Dans ce contexte, les équipes sont autonomes sur la création de leurs user stories.  L’élaboration du premier backlog s’étant faite lors d’un atelier de démarrage du projet (détaillé dans un prochain billet)

En parallèle, il faut préparer le backlog côté « vision métier ». Le produit étant organisé autour de grands thèmes, le découpage des équipes s’effectue par « area » couvrant ces thèmes. Il y a un Product Owner et des Area Product Owners.

On retrouve en quelque sorte la branche en Y chère à Pascal Roques.

Tout cela piloté par les valeurs fonctionnelles et techniques édictées par le PO. Les approches Bottom-up et Top-down combinées, mais toujours priorisées par la plus value.

Au final, les deux visions se rejoignent. J’estime cette jointure autour de 3- 4 sprints, ce qui équivaut à une release : c’est la release 0.