Execution is everything. Faux et archi-faux !

L’expression « execution is everything  » (tout est dans l’exécution) sonne comme une vérité absolue en entreprise depuis des décennies. Mais Basecamp, connue pour l’efficacité, le rythme et la qualité de ses développements, effectués avec peu de collaborateurs également très fidèles à l’entreprise, apporte la preuve du contraire. Leur méthode : Shape Up, met davantage l’accent sur la création d’une contexte de développement propice à la créativité, l’autonomie laissée aux équipes, l’envie des collaborateurs de transformer plutôt telles ou telles idées en applications utiles et la domestication du risque.

La méthode Shape Up repose sur plusieurs principes.

 

Des cycles de six semaines

Tout d’abord, Basecamp fonctionne par cycles de six semaines. Six semaines, c’est assez long pour construire quelque chose de significatif du début à la fin et assez court pour que tout le monde sente l’échéance se profiler dès le début, de sorte que le temps n’est pas gaspillé. La majorité des nouvelles fonctionnalités sont développées et diffusées au cours d’un cycle de six semaines.

Leurs décisions sont basées sur l’avancement du produit dans les six semaines à venir, et non sur une microgestion du temps. Ils ne comptent pas les heures et ne s’interrogent pas sur la façon dont les journées sont passées. Ils n’organisent pas de réunions quotidiennes. Ils ne repensent pas leur roadmap (feuille de route) toutes les deux semaines. Ils se positionnent à un niveau plus macro. Ils se disent : « Si ce projet aboutit au bout de six semaines, nous serons vraiment heureux et les équipes seront fières du travail accompli. Nous aurons l’impression que notre temps a été bien utilisé. » Ils lancent alors les développements pour les six semaines et laissent l’équipe travailler seule.

 

Cadrer le travail différement

Deuxièmement, Basecamp cadre le travail avant de le confier à une équipe. Un petit groupe de responsables hiérarchiques travaille en parallèle avec les équipes en charge du développement du cycle. Il définit les éléments clés d’une solution avant que le projet ne soit considéré comme prêt à être mis en œuvre. Les projets sont définis au bon niveau d’abstraction : suffisamment concrets pour que les équipes sachent ce qu’elles doivent faire, mais suffisamment abstraits pour qu’elles aient la possibilité de régler elles-mêmes des détails intéressants.

Lors de l’élaboration, les équipes se concentrent moins sur les estimations et davantage sur leur appétit. Au lieu de se demander combien de temps il faudra pour effectuer un travail, ils se posent les questions suivantes : Combien de temps veulent-ils consacrer à ce travail ? Quelle est la valeur de cette idée ? Telle est la raison d’être du cadrage : circonscrire le problème et concevoir les grandes lignes d’une solution qui s’inscrit à l’intérieur des contraintes de l’appétit de l’équipe.

 

Responsabiliser les équipes

Troisièmement, Basecamp confie l’entière responsabilité du développement à une petite équipe intégrée de concepteurs et de programmeurs. Ils définissent leurs propres tâches, ajustent le champ d’application et travaillent ensemble pour construire les phases de développement du produit, et s’y atteler, une à la fois. Cette approche est totalement différente des autres méthodologies, dans lesquelles les responsables découpent le travail et les programmeurs s’organisent selon les tâches reçues sous formes de tickets.

Ensemble, ces concepts forment un cercle vertueux. Lorsque les équipes sont plus autonomes, les responsables peuvent passer moins de temps à les gérer. En consacrant moins de temps à la gestion, les responsables peuvent élaborer de meilleurs projets. Lorsque les projets sont mieux conçus, les équipes ont des limites plus claires et peuvent donc travailler de manière plus autonome.

 

Cibler le risque

À chaque étape du processus, Basecamp cible un risque spécifique : le risque de ne pas livrer à temps. Ils réduisent le risque :

• dès le processus d’élaboration en résolvant les questions en suspens avant d’engager le projet avec un délai précis. Ils ne confions pas un projet à une équipe qui a encore des zones d’ombres ou des interdépendances enchevêtrées.
• au cours du processus de planification en limitant leurs paris à six semaines. Si un projet dépasse ce délai, il n’est pas prolongé par défaut. Ce « coupe-circuit » garantit à Basecamp de ne pas gaspiller l’appétit de l’équipe en lui faisant sur un projet mal cadré en amont.
• lors du processus de construction en intégrant la conception et la programmation dès le début. Au lieu de construire de nombreux éléments déconnectés et d’espérer qu’ils s’emboîteront ensuite, ils construisent un élément significatif du travail (un lot) de bout en bout dès le début, puis ils répètent l’opération. L’équipe réalise le travail en avançant du plus inconnu au moins connu. Ce qui garantit que les efforts à fournir en fin de cycle, dans la dernière ligne droite, ne soient pas pas les plus difficiles.

 

Il aura fallut des années à Basecamp pour être en mesure l’expliciter enfin sa méthode. C’est fait et nous les en remercions. La méthode Shape Up a largement été détaillée dans le livre Shape Up de Tyan Singer, l’un des designers de Basecamp et disponible en téléchargement ici.