Cet article fait partie de la formation gratuite Agile pour l'architecture, n'hésite pas à t'y inscrire pour t'aider à mettre en place l'agile sur tes projets.

Les itérations agile, de la phase au sprint

Les itérations, le découpage de projets en phases, tu vas me dire, tu le pratiques déjà ! Certainement, rien de nouveau dans ce concept, nous avons tous l'habitude de découper une tâche complexe, en plusieurs séquences simples. D'ailleurs la maitrise d'ouvrage le fait pour nous, en segmentant le projet en phases, qui se suivent : Esquisse, Avant-projet, DCE... On est d'ailleurs payé en tant qu'architecte, ingénieur par rapport au travail d'une phase. Mais dans l'agile et dans le Scrum, l'approche agile, la plus populaire. On va plus loin dans ce découpage et surtout chaque cycle est le moment de récolter les avis des parties prenantes et d'orienter la conception.

Les itérations agiles doivent être plus courtes, idéalement de l'ordre de 1 à 3 semaines au lieu de 2 à 3 mois pour une phase classique. Aussi on introduit le fait que le programme du début, n'est pas forcément celui que l'on ferra à la fin, du moins à la lettre !

Quoi comment ça ! Mais contractuellement, mon équipe de maitrise d'œuvre se doit de faire tout ce qui est au programme, je la paye pour ça ! On dit donc que le programme, la demande est négociable. Ce qui compte est la valeur délivrée, et non la contractualisation. On va voir comment c'est possible. Les itérations se suivent et orientent les suivantes

On introduit aussi le fait qu'il y a une boucle de rétroaction à chaque itération. C’est-à-dire que la livraison d'une itération, que l'on peut aussi appeler sprint (le terme utilisé dans le scrum) introduit des modifications de la demande initiale. Et c'est d'ailleurs pour cette raison principalement que découper en petits cycles est judicieux. C'est grâce à cela qu'on peut être agile, au sens de souple, adaptable.

Les itérations agile

En effet, il n'est pas possible de savoir tout ce que l'on veut dès le début, les besoins du client, la connaissance de ce qui doit être fait, se développe de manière progressive. Et notamment en montrant régulièrement le projet en train de se faire, lors de demo par exemple du modèle BIM, ou même de n'importe quel document, perspective, plan qui permette à tous les acteurs d'appréhender le projet.

Si on récapitule un peu,

👉 Les itérations agile sont des cycles de travail plus courts que les phases

👉 Elles sont appelées sprint dans le scrum, mais pourquoi pas jalon, échéance, cycle. L'essentiel est que le terme te parle.

👉 Les itérations se répètent et se nourrissent l'une l'autre par exemple, à la fin de la première, on peut réorienter les priorités de la deuxième

👉 A chaque fin d'itération, on montre le projet au maximum de parties prenantes, pour avoir des retours et orienter les travaux suivants Mais tout cela, c’est très bien, mais en quoi c'est mieux de travailler comme ça ? Le travail en itérations agile, pourquoi c'est mieux ? Les approches Agile, ont été crée par opposition à la méthode traditionnelle. Cette méthode que vous connaissez tous sans connaître son nom, s'appelle la méthode en cascade.

caption for image

Dans la méthode en cascade, les demandes viennent d'en haut jusqu'à l'exécution

Et oui en cascade, c'est une belle image. Mais en fait, elle reflète plus une organisation taylorienne d'un projet, comme une usine qui découperait un montage complexe en une série d'opérations simples :

1- Définir le programme

2- Choisir l'équipe d'architecte

3- Définir le projet en allant de plus en plus dans le détail

4- Choisir une entreprise

5- Construire En ne prenant que l'étape 1, comment un maitre d'ouvrage peut savoir à coup sûr ce qui est important de prévoir ? Les personnes qui sont le plus à même de le conseiller : l'architecte, l'entreprise, les ingénieurs, ne sont même pas connus !

À l'inverse, en Agile, on ne définit que le minimum de choses en amont, les décisions sont prises, itérations après itérations entre toutes les parties prenantes.

Donc travailler en cycle court, permet plusieurs choses :

👉 Limiter les hypothèses que l'on fait en avance pour s'adapter à la situation et la connaissance actuelle du sujet en lien avec le client ou les utilisateurs finaux.

👉 Avoir toujours un résultat partageable à la fin du cycle, pour pouvoir demander à tous les intervenants leurs avis. On appelle ça réduire la boucle de rétroactions (shorten the feedback loop)

👉 Prioriser à un moment donné ce qui est plus important pour les clients, utilisateurs et donner la valeur tout de suite, au lieu de leur faire attendre 3 mois. Éviter ainsi l'effet tunnel, où l'on travaille pendant 3 mois sans diffuser.

Mais comment appliquer cela pratiquement ? Oui, c’est bien, mais tu connais aussi bien que moi le métier, ça ne marchera jamais dans le bâtiment ! Les ingénieurs ne commencent leur travail que quand le projet est "figé". Le maître d'ouvrage est pointilleux et s'attache à la lettre à son cahier des charges... Oui je te l'accorde, et d'ailleurs nous avons identifié et commentés ces freins à l'agile de nombreuses fois avec la communauté agile BIM lors de nos meetups. Mais je pense qu'il y a néanmoins de nombreuses possibilités en interne ou à l'intérieur du groupement de changer la manière de travailler. Je te propose donc de tester ce travail d'itérations en se basant sur ce qui existe déjà, les réunions de conceptions.

📅 En pratique agilise le planning de réunion

Donc pratiquement voila ce que je te propose de faire :

✅ Décide à quel niveau de collaboration tu veux / peux travailler, en effet il peut être difficile d'impliquer toute l'équipe. Mais pas besoin de s'arrêter là, autant commencer à un niveau restreint, mais avec une équipe impliquée. Donc par exemple ça peut être "Avec la maitrise d'œuvre", "Juste en interne" en tant qu'architecte ou ingénieur. Ou même seul pourquoi pas !

✅ Identifie des cycles de conception sur lequel t'appuyer pour pratiquer les sprints. Par exemple les réunions de conception prévues avec le client, avec la maitrise d'œuvre. Si les réunions sont trop espacées, pourquoi pas en proposer d'autres ! Ton client sera certainement heureux d'entendre parler du projet plus fréquemment !

✅ Essaie de lister les points importants pour cette réunion et de juger du niveau de priorité avec les autres intervenants. Les points importants sont par exemple ceux qui permettent de "débloquer" un autre intervenant, par exemple fixer la trame de poteau pour donner des hypothèses de départ à l'ingénieur. On parlera de priorisation bientôt pour aider à déterminer ce qui a le plus de valeur, mais pour l'instant fait avec ton intuition.

✅ Force toi à préparer un livrable, même si le projet n'est pas fini. Plus vite les parties prenantes, quel que soit leur niveau technique, pourront rentrer dans le sujet et donner leur avis, mieux ce sera.

Enfin si ce contenu t'intéresse, sache qu'il fait partie d'une série pour apprendre l'agile pour l'architecture et la construction. Abonne toi à ma formation par email. C'est gratuit !