You said agile ?

The latest success stories of the new economy are often the result of small companies that started in a “garage” environment, relying on highly agile processes. “Small is beautiful” was their guiding principle.

The question that interests us is whether these companies are simply exceptions driven by visionary founders, or whether broader lessons can be applied to the organisation of larger enterprises.

It is interesting to observe that companies such as Google, Facebook or even Amazon have remained flexible and innovative despite their significant scale (respectively 32,000, 3,000 and 22,000 employees at the time).

At a time when both “offshore” and “lean” approaches are highly popular, how should organisations and processes evolve to achieve maximum efficiency ?

When 1 is better than 10

The famous operating system behind the iPhone was developed by only 60 developers, while Motorola failed to create a competing system despite assigning 1,500 people to the project.

This demonstrates that developer quality cannot be compensated for by quantity ; on the contrary, oversized teams often become counterproductive. We have seen projects delayed by several months because of only 15 man days of development work.

Why ?

At the most fundamental level, the developer remains the key unit :

“One good developer is worth ten mediocre ones”
— Study by Sackman, Erickson and Grant

Strong developers produce higher quality code more rapidly. Code quality subsequently impacts testing, debugging, maintenance and upgrade phases.

At the team level, actions are not parallel but interdependent. Skills — or weaknesses — therefore multiply rather than simply add up, and one mistake can slow down the entire chain.

In reality, these dynamics reflect long standing principles found across many industries whenever work extends beyond pure execution : craftsmanship, creative work, analysis and design.

A developer is fundamentally a creator of code, not a simple operator endlessly repeating the same task.

From this perspective, management approaches must evolve accordingly by encouraging initiative and avoiding purely “military style” management based on top down executable orders. While such approaches may work for repetitive execution tasks, they are far less effective when initiative and problem solving are required.

This applies not only to management, but also to technical teams and more broadly to all employees involved in complex projects where creativity and autonomy matter.

Simplicity and lightness

Returning to software development helps explain the success of highly efficient teams.

For many years, software projects were structured around a strict separation between functional specifications and development.

However, describing (“specifying”) software can be almost as complex as building it. Furthermore, specifications are always open to interpretation and are therefore inherently imperfect.

Based on this observation, modern development methodologies aim to minimise the specification phase and merge it more closely with development itself.

This does not mean “building first and thinking later”, but rather limiting upfront planning to overall architecture and interfaces while dividing the project into coherent and manageable sub components.

Thanks to these approaches :

• Facebook releases new versions every week
• Mozilla Firefox shifted to six week release cycles instead of waiting several months or even years between releases

Which organisational tools support this model ?

Teams are intentionally lightweight and accountable, typically composed of :

• A Product Owner, acting as the sole business representative
• A Scrum Master, responsible for supporting the team, managing external interactions and resolving non technical issues
• A small, skilled and empowered development team with a global understanding of the project and the ability to actively contribute ideas

This stands in stark contrast to projects where there are more decision makers, project managers and validators than actual contributors.

We have even seen projects allocating €35,000 to project management for only €5,000 of actual development work.

‍

Exit donc les spécifications-contrat détaillées, rassurantes mais figées. En fait, comme elles ne sont jamais parfaites, elles constituent un fardeau à l'origine des conflits client/fournisseur classiques sur les délais de livraison. Les spécifications deviennent alors le support d’un dialogue, un des outils permettant de transmettre aux développeurs la vision du produit. Et le dialogue ne prend fin qu’à la livraison.

Détailler n’est pas gagner

Ceci est un enseignement largement généralisable : combien de plannings hyper détaillés qui ne seront pas respectés, dès le premier jour ? Combien de contrats de 50 pages à peine lus qui ne serviront à rien lorsqu'on se sera finalement aperçu d'un malentendu fondamental sur le fond ?

Le détail rassure mais fait courir le risque d'oublier l'essentiel. La 25e décimale de ce pi est-elle exacte ?
Pi = 31,415926535897932384626433832795028841971693993751058209749445923078164062862089
98628034825342117067 ??? Je vous laisse vérifier…[1]

La culture de la simplicité est très difficile à obtenir. La simplicité est hautement compliquée… 1/2 g t² Peut être vous souvenez vous de cette formule de la chute des corps. Il aura fallu attendre Galilée et Newton pour avoir une formule aussi simple, qui néglige les frottements de l'air, mais juste dans le cas général. Tout le monde n'est pas Newton. Mais c'est en cherchant des résultats simples et concis plutôt qu'à produire un pavé de 200 pages qu'on a de plus de chance d'aller dans la bonne direction.

La culture client / fournisseur

La culture client / fournisseur interne a sans doute de nombreux bénéfices. L'un est sans doute de permettre une lisibilité des processus internes, et un découpage en "livrables" intermédiaires. Néanmoins, dans beaucoup de cas, elle conduit à des surcouts par empilement des besoins et méconnaissance des contraintes des autres. C'est ce que nous appelons la complexité technique :

• « Le produit est trop cher parce que ces incapables du service achats n'ont pas su me trouver ma pièce au bon prix. Ils n'ont pas respecté leur SLA ! » (Service Level Agreement) Mais bien sûr, j'ai oublié de leur dire que 3m était une longueur approximative, et que j'aurais bien pu me satisfaire du standard de 3,02m.
• « J'ai spécifié une colonne pour le mois et une autre pour la date. Ce n’était pas vraiment ce que je voulais, ça a rallongé mon projet d'un mois et maintenant, je ne peux plus changer. »

Cela vous rappelle quelque chose ? La co-écriture du produit entre marketing et développement est fondamentale pour l'efficacité globale du projet. La discussion des interfaces (logicielles, physiques) entre deux équipes doit toujours être négociée et non spécifiée.

Itérations

De pair avec ces spécifications flexibles, des processus itératifs adaptés aux changements sont nécessaires: le logiciel est développé par incréments (sprint) successifs et périodiques.

Une validation est effectuée en fin de Sprint (plutôt qu’en fin de projet), "quelque chose" est livrable en fin de Sprint, il est possible d’ajouter des fonctionnalités non prévues à chaque Sprint, les codes précédents sont optimisés (Re-engineering), une analyse du Sprint est réalisée pour préparer d’éventuelles formations, améliorer des process et permettre les transferts de connaissances en interne.

Les Sprint sont typiquement de 15 jours. La durée peut être adaptée au projet :

• Deux heures pour la préparation d'une présentation
• Quelques semaines pour un projet industriel lourd.

La bonne durée équilibre la possibilité de voir quelque chose de concret en regard de la stabilité du besoin et de la latitude d'interprétation.

Ces méthodes peuvent réellement inspirer des projets aussi divers que la préparation d'un séminaire ou le lancement d'un nouveau produit. Nous avons vu ainsi des clients demandant des plannings détaillés à la demi-heure d'un séminaire de 3 jours, alors qu'il était clair que le planning devait s'adapter aux réactions des participants.

Les estimations sont toujours fausses

Au lancement du projet, les estimations sont absolument nécessaires, mais forcément fausses : le projet n’est pas encore délimité, les difficultés ne sont pas visibles, les estimations sont faites par le management ou le marketing plutôt que par les opérationnels, les résultats d’un projet/d’une équipe sont transposés à un/une autre, sans tenir compte de leurs spécificités…

Les aléas du projet choquent notre sens rationnel et notre optimisme humain. Mais les défis techniques, les changements, les contretemps, les erreurs sont inévitables. S’il n’y en a pas, on peut réellement se demander si le projet crée réellement de la valeur ! Il faut donc accepter l’imprévisibilité et la gérer en estimant des portions de projets et en révisant les estimations régulièrement.

Bon du premier coup

Vient ensuite la question de la qualité. Le "bon du premier coup" est toujours largement supérieur à la "qualité statistique". Si le flacon de shampoing ne sort pas de la ligne car une simple barre détecte que le bouchon n'est pas bien enfoncé, vous pouvez corriger immédiatement et vous êtes certains d'une qualité à 100%, bon marché. Un niveau impossible à atteindre par contrôle a posteriori.

Comment l’opérationnaliser ?

• Déjà par la culture : éviter les "on corrigera plus tard", de la faute d'orthographe qui sera détectée par l'éventuel correcteur, au "bug" grave qui est censé être détecté par la validation / qualité.
• Protéger ses équipes du « crunch mode » : phase de travail acharné pour satisfaire le deadline. L’augmentation de cadence se paye par une perte en qualité qui elle-même peut engendrer des contretemps.
• Mettre en place des contrôles immédiats : cohérence des résultats, validation par le client des itérations.
• Avoir des outils propres et lisibles : le code informatique doit être aussi propre que les postes de travails de Toyota!

La relecture par des pairs (des plans, du code, de la présentation, du business case, etc.) est une bonne méthode : on s'applique lorsqu'on sait qu'on sera relu. Par respect, on fournit une matière claire, propre et correctement présentée. Le retour sur investissement est généralement immédiat.

Veille et investissement

Enfin, l’incontournable des bons livres de management et d’organisation personnelles : commencer par l’important et non l’urgent. Si l’on s’inspire encore des développeurs, ceux qui sauront rester au-dessus de la mêlée sont ceux qui auront su rester sans arrêt aux aguets des derniers progrès de l’état de l’art, et qui ainsi pourront choisir le bon modèle, outil, langage, framework, en fonction du problème à résoudre.

Il est souvent tentant et rassurant de passer du temps à régler les affaires courantes, alors que la veille et l’investissement semblent plus aléatoires. Pourtant, il est généralement plus efficace de trouver un moyen de régler définitivement un problème, en trouvant une solution existante, en l’automatisant ou en le déléguant (« apprenez à un homme à pêcher et vous le nourrirez toute sa vie »), qu’en le résolvant soi-même. Même si la recherche de la solution pérenne prend deux ou trois fois le temps de la résolution simple, la rentabilité est généralement très rapide.

Finalement, l'apparente révolution de "l'agile" dans le monde informatique est riche d'enseignements dans la gestion de projets divers. On peut argumenter qu'elle est dans la continuité des méthodes "qualité" débutées dans les années 70. Néanmoins, cette "qualité" a été tellement mal interprétée, et a conduit à tant de classeurs et manuels rassurants, dormants paisiblement dans des armoires, que nous pensions utile de refaire un tour d'horizon des méthodes "disruptives" permettant de mettre sur le marché un nouveau produit toutes les semaines et non plus tous les ans, le tout sans surcoût.

Morand STUDER

[1] La 25e décimale est juste, mais vous aviez bien évidemment noté que la virgule était mal placée...