Une façon classique de présenter le sujet est de commencer par le manifeste, puis d’évoquer le « parapluie agile » et les différentes approches qu’elle abrite : Scrum, XP, Kanban, etc.

Mais c’est surtout : délivrer tôt de la valeur métier et « moins de bureaucratie ». Pour illustrer cela, Kniberg nous trace le Value Stream Map d’une entreprise développant des jeux : un temps de cycle de 25 mois pour 3 mois de travail utile seulement ! La logique de telles entreprises est de minimiser les coûts en maximisant l’utilisation des ressources.

Optimiser l’utilisation des ressources

Il s’agit d’une illusion à plusieur titres. Tout d’abord occuper au mieux l’équipe ne garanti pas une meilleure productivité, au contraire. Preuve nous en est donnée lors des week-end de départ en vacances…

Par ailleurs, notre travail n’est pas de produire du logiciel … mais de résoudre des problèmes. Et si possible en produisant le moins de logiciel possible pour ce faire !

Et Scrum, dans tout ça ?

J’ai déjà longuement parlé de Scrum dans ce blog. Il se séfinit par quelques règles simples. Et aussi du Shu Ha Ri qu’évoque également Kniberg. Hélas, de nombreuses organisations sont « bloquées dans le Shu » !

Scrum, c’est une structure très simple, une Scrum Team composée d’un PO qui fait le lien avec le monde extérieur et une équipe de développement pluri-disciplinaire. Des artéfacts réduits au minimum, avec un Product Backlog et un Sprint Backlog.

Le Sprint, l’unité de temps de Scrum a une structure bien définie, elle commence avec le planning meeting et se conclut par le Sprint Review, puis la rétrospective. Mais ce n’est pas la seule façon de faire ! La cadence des rétrospective peut être décorrélée des sprints. De même, si les Sprint Reviews donnent la cadence, le planning meeting peut suivre une autre régularité. D’ailleurs en Kanban, ce dernier disparait pratiquement !

Pourquoi ça marche ?

Parce que l’approche agile diminue les risques ! Les gros projets ont une méchante habitude : ils échouent ! Pour l’auteur, un gros projet s’assimile à un tir au canon : de longs calcul, un seul essai… qui a toutes les chances de rater la cible.

Le projet agile serait plutôt un missile à tête chercheuse, capable de réajuster sa direction en permanence !

Le « big risk » du projet classique est transformé en « mini-risques » qui sont autant d’incréments. Des incréments qui ne sont pas des étapes de construction mais des tranches de fonctionnalités, des niveaux d’accomplissement du besoin. Les éléments principaux de la recette ?

• Des équipes pluridisciplinaires, où les membres travaillent ensemble et se complètent.
• Un focus sur l’optimisation de la valeur, et non des fonctionnalités livrées (et encore moins de l’occupation).
• Revenir au « pourquoi » et identifier les options qui s’offrent à nous, comme nous le faisons avec l’impact mapping

Parlons planning

Le planning classique, c’est le « big bang », le grand pari d’être dans les clous, sans aucun « plan B ». A contrario, le planning agile, c’est sécuriser un périmètre en continu. C’est aussi s’adapter en continu avec une boucle de feedback plus rapide. Celle-ci se prolongera vers l’utilisateur final avec la mise en place d’un déploiement continu.