Archives 2018

Du chantier à l’agilité : ce que la construction apprend à la gestion de projet

Du chantier à l’agilité : ce que la construction apprend à la gestion de projet

Terrain vs. théorie : l’opérationnel qui rend humble

Un chantier apprend la sobriété : objectifs clairs, séquences maîtrisées, décisions rapides, responsabilités explicites. Cette culture opérationnelle se transpose naturellement à la gestion de projet agile : rendre visible, limiter le travail en cours, livrer par incréments, construire un feedback utile.

Rituels de terrain ↔ rituels agiles

  • Brief quotidien (15 min, pied de grue) ↔ Daily : état d’avancement, risques, décisions.
  • Jalons de lotSprint Review : démontrer du “vraiment fini”.
  • Retex chantierRétrospective : causes racines, actions concrètes, propriétaire assigné.
  • Zones tamponKanban (WIP limité) : fluidifier les flux, éviter les blocages systémiques.

Définition de “fini” : réception partielle comme boussole

La Définition de Fini (DoD) n’est pas un idéal, c’est un contrat : critères visibles, mesurables, partagés. En chantier, c’est un PV de réception partielle ; en projet, c’est une story prête à l’usage, testée, documentée, déployée.

Gestion des risques : penser options, pas excuses

Sur chantier, le risque se traite en amont (réserves, variantes techniques, marges) et en aval (plans de reprise). En agile, on raccourcit les boucles, on valide tôt, on pivote à coût maîtrisé. La vitesse utile naît de cette lucidité.

Leadership : fermeté sur l’objectif, souplesse sur le chemin

Le chef qui réussit sait dire “non” quand il le faut, et “oui” quand c’est faisable. Il protège le rythme, tranche les arbitrages, et maintient la clarté. Qu’il s’agisse de béton ou de logiciel, le leadership reste la variable déterminante.

Conclusion : l’agilité, c’est du bon sens discipliné

La construction m’a appris la rigueur ; l’agile lui donne un cadre réplicable. Ensemble, ils produisent des projets lisibles, pilotables et utiles pour le client final.

Scrum, Kanban, Lean : adapter plutôt qu’imposer les méthodes

Scrum, Kanban, Lean : adapter plutôt qu’imposer les méthodes

Diagnostic avant cadre : le contexte d’abord

On n’installe pas Scrum “parce que c’est mieux”, ni Kanban “parce que c’est simple”. On part du contexte réel : flux, contraintes, maturité, disponibilité managériale. Le cadre doit servir l’équipe, pas l’inverse.

Scrum quand il faut apprendre par incréments

Sprints courts, incréments potentiellement livrables, reviews utiles, rétrospectives avec actions suivies. Product Owner formé à la priorisation par valeur, Scrum Master garant du rythme et de la clarté.

Kanban quand il faut stabiliser les flux

Visualiser, limiter le WIP, rendre explicites les politiques, gérer les classes de service (urgence, standard, date fixe). Prévisibilité par les données, pas par “l’intuition du planning”.

Lean : éliminer le gaspillage

  • Surproduction (fonction non utilisée), attentes (validations lentes), retouches (mauvaise qualité).
  • Standardiser ce qui doit l’être, laisser respirer ce qui doit évoluer.

Outils : au service du processus

Jira, Trello, Notion, SharePoint… peu importe. On choisit sobre, maintenable, compris par tous. Un outil mal compris ralentit.

Résultats : clarté, cadence, vécu apaisé

Moins de multitâche, meilleures prévisions, engagements tenables, moins de tensions. L’équipe s’aligne sur des règles visibles et partagées.