Le framing agile permet également de définir le cadre qui sera mis en place pour la phase de réalisation. La mise en place de ce cadre sera très différente selon le contexte du framing agile ; en effet, la réalisation d’un produit physique ne demandera pas du tout la même phase de réalisation que la réalisation d’une application ; cela serait également vrai si vous veniez à utiliser le framing agile pour cadrer le lancement d’une transformation agile. Nous rappelons que le framing agile n’est pas dédié au développement logiciel mais qu’il peut s’appliquer à tout lancement de projet, peu importe sa nature.
Développement logiciel
Dans l’univers IT, si dans une majorité des cas le scrum sera choisi, vous pourriez très bien décider d’utiliser d’autres méthodes agiles :
- Scrumban (kanban)
- Extreme Programming
- Crystal Clear
- Méthode maison…
Le choix doit se faire en équipe et après l’exposition des raisons qui amènent à ce choix. Le scrum n’est pas toujours adapté pour les équipes IT.
Nous ne recommandons pas d’envisager d’utiliser des méthodes waterfall telles que le cycle en V ; en effet, le framing agile a pour objectif d’amener à un état d’esprit agile.
Les méthodes agiles imposent de mettre en place un cadre stricte et complet pour être efficace. Si les équipes négligent la mise en place de ce cadre, elles verront très vite un ensemble de dysfonctionnements se mettre en place.
Si vous décidez par exemple de faire du Scrum, n’hésitez pas à aller voir le cadre minimal proposé par le “scrum guide” pour ensuite alimenter celui-ci de vos compléments nécessaires pour structurer le fonctionnement de la prochaine équipe qui se mettra en place. Mais si vous optez plutôt pour un Extreme Programming, il y aura moins de chose à cadrer car l’Extreme Programming impose lui même beaucoup plus de pratiques.
Exemple de cadrage avec Scrum
Vous pourrez retrouver le scrum guide dans différentes langues en recherchant le terme “scrum guide” sur Google. Celui-ci fait moins d’une vingtaine de pages et se lit plutôt rapidement.
Si votre équipe décide de partir sur une base scrum, ce qui sera vrai dans plus de 90% des cas, voici les différents éléments qu’il faudra définir :
- les cérémonies et les rôles (défini par le scrum guide)
- la gouvernance des ces rôles (prochain atelier proposé par le framing agile)
- le sprint et sa cadence (1 à 4 semaines)
- définition des items et organisation du backlog
Le sprint et sa cadence
La durée des sprint
Il est important de définir la cadence de ses sprints pour la phase de réalisation. En général, 80% des équipes décident de faire des sprints de 2 semaines car ce rythme est plutôt un bon compromis.
Pour ma part, je déconseille fortement de faire des sprint de 1 semaine car ce rythme donne souvent une impression d’avoir un trop grand nombre de cérémonies. De plus, il sera plus difficile de déplacer les différents acteurs extérieurs pour venir en “sprint review” comme les clients, les parties prenantes voire les sponsors.
Si je vois quelques équipes faire le choix de mettre en place des sprint de 3 semaines, il est très rare de voir des équipes qui décident d’avoir une cadence de 4 semaines. Pour ma part, je ne le recommande pas également car cela complexifie certaines choses :
- le product owner doit être capable de proposer un gros sprint backlog
- suffisamment avancé pour que l’équipe puisse s’engager
- la priorisation par la valeur est moins efficace
- l’amélioration continue avec les rétrospectives est plus lente
Rien ne vous interdit de faire des sprints de 1 ou 4 semaines mais n’oubliez pas les contraintes que ces cadences peuvent amener.
Cadence des Product Backlog Refinement
Si pour l’ensemble des cérémonies, la cadence est claire, elle l’est beaucoup moins pour la Product Backlog Refinement. Il faut premièrement comprendre que la Product Backlog Refinement n’est pas une cérémonie ; cependant beaucoup d’équipes transforme ce concept en cérémonie régulière. Il est possible de mettre ce principe sous ces formes :
- A la demande du product owner en accord de l’équipe de réalisation
- Cérémonie rythmée
Mais il est impératif en scrum, de définir comment sera réalisé ce concept qui permet de travailler sur l’affinage du backlog et plus particulièrement du prochain sprint backlog. Le format pourra évoluer plus tard si le format défini lors du framing agile ne semble pas adapté.
J’ai quelques conseils que je peux vous donner par rapport aux nombreuses équipes que j’ai accompagné :
- privilégier le format cérémonie pour limiter les perturbations
- faire cette cérémonie 1 fois par semaine afin de permettre au Product Owner de bien gérer la priorisation des futurs sprint backlog
- limiter la durée de la cérémonie à 1h pour chaque session car il sera compliqué pour l’équipe de réalisation de rester attentive plus longtemps. Cependant, la cérémonie pourra être écourtée si le Product Owner n’a plus d’affinage à réaliser.
- Si ce temps n’est pas suffisant pour faire tout l’affinage désiré, vous pourrez sans soucis rajouter des sessions d’une heure un autre jour de la semaine.
| Conseils : si votre product backlog refinement est une cérémonie, mettez un jour précis et une heure précise pour chaque session de Product Backlog Refinement pour que l’équipe ne soit pas perturbée par des changements continuels de dates. |
Définition des items et organisation du backlog
Il faut savoir que le “scrum guide” parle d’items et ne précise pas la nature des items à utiliser, ni même comment les définir. C’est à l’équipe elle même de structurer ce backlog et le cadre de celui-ci.
Bien que le framing agile amène l’utilisation de user-stories et de NFR, rien n’interdit l’équipe de faire autrement. Nous avons fait le choix, de proposer les notions les plus utilisées du marché sur lesquelles les équipes pourront trouver de nombreuses informations : blog, livres…
Nous verrons la définition des user-stories dès l’atelier du Definition of ready et Definition of Done (Dod).
Pour l’organisation du backlog, voilà le type d’organisation que je peux vous conseiller qui va dans la continuité des précédents ateliers :
Dans le monde industriel
Le monde industriel est très différent de l’univers du développement d’application. L’organisation pour le lancement de la réalisation peut s’avérer plus complexe. Le framing agile ne pourra pas vous donner énormément de pistes tant les cas peuvent être très différents. Le framing master sera dans ce cas, probablement votre plus grande aide.
Il y aura un grand nombre de questions à se poser :
- production externe ou interne
- gestion des livraisons
- trouver la matière première (voire les prix)
- …
Il y a cependant des outils qui peuvent grandement aider à la prise de décision entre différents choix comme par exemple le VSM (Value Stream Model) qui permet de définir le lead time complet à la réalisation d’une unité.
Vous pouvez trouver une explication complète de cet outil d’analyse de processus ici :
Dans l’univers industriel, la notion de budget pourra régulièrement être remise en question dans cette étape. En effet, en contactant d’éventuels prestataires pour l’une des étapes clés, les prix proposés peuvent réellement varier et faire augmenter le coût unitaire de votre produit ; cette variation peut avoir des conséquences importantes :
- prendre plus de temps pour réorienter les choix
- s’imposer un no-go
En effet, le prix d’une unité peut devenir très problématique surtout si vous êtes face à une concurrence potentielle ; et cela est vrai même si le coût n’augmentait que de 20%.
Lors d’une transformation agile
Bien que l’utilisation du framing agile pour lancer une transformation agile sera rare, ce type d’utilisation est tout a fait possible. Dès cette étape, vous pourrez alors définir l’organisation pour le lancement de cette transformation agile.
Si vous suivez les 8 étapes de changement de Kotter que nous expliquerons brièvement ci-dessous, vous en êtes à l’étape 3 « créer une vision ». Ce modèle est très reconnu pour donner un maximum de chance à la réussite d’une transformation.
Ces 8 étapes sont :
- créer un sentiment d’urgence
- former une coalition
- créer la vision
- partager la vision
- inciter à l’action
- démontrer des résultats à court terme
- bâtir sur ses premiers résultats
- ancrer les nouvelles approches dans la culture agile
L’équipe peut dès cette étape, créer sa stratégie pour partager la vision qui est en cours d’écriture. Comment se fera le partage ? Quel outil ou processus ?
Certaines entreprises optent pour des pôles de transformation agile. Est-ce que ce sera le cas dans votre vision de la transformation ?
Certaines transformation mettent en place des notions de « saison » ; celle-ci sont des itérations avec une planification de départ et une revue/rétrospective. Peu importe le terme à utiliser, il est fortement recommandé d’avoir des itérations pour le suivi de l’avancement de votre transformation.
Cette étape sera donc clé pour déterminer toute l’organisation nécessaire pour avancer sur la transformation agile et lui donner un maximum de chance d’être un succès. Tout ce qui sera décidé lors de cette étape pourra évoluer au fil de l’avancement.
Soyez le premier à commenter