Si vous pratiquez Scrum, vous avez expérimenté la dynamique des sprints:
- on démarre avec PLANNING 1 où l’on défini le QUOI
- ensuite on passe à PLANNING 2 où l’équipe sélectionne les items du Product Backlog qu’elle souhaite transformer en Sprint Backlog
- le développement commence
- tous les jours, les DAILY SCRUMS mesure l’alignement des développeurs et sa progression
- de temps à autre des sessions de Grooming de backlog (10% du Sprint): pour retravailler les items bloquants du Sprint Backlog
- à la fin du Développement, la Scrum Team, le Management, les Utilisateurs et le ou les clients inspectent et adaptent le résultat du développement (l’incrément potentiellement livrable) qui est validé par le Product Owner
- une fois terminé, la Scrum Team se réunit pour la Rétrospective
- et le cycle recommence indéfiniment
Cela fait quelques temps que je rencontre des scrum masters me demandant la possibilité d’avoir une journée de répit après la rétrospective. En effet, de nombreuses équipes ayant tout donné lors du Sprint se trouvent souvent nerveusement fatiguées pour démarrer une nouvelle itération. Lors de nos discussion avec les scrum masters, nous avons évalué deux options:
- une journée « libre » pour travailler sur des projets personnels comme un FedEx day
- une journée « différente » pour rechercher de nouvelles options du produit à développer en mode « Jam »
Le mode Jam ou Jam est souvent utilisé en Service Design. Il s’agit d’une journée de création tous azimuts dans le but est de créer une application, un service, un produit « fonctionnel ».
Cette approche ferait évoluer les Sprints de 2 manières:
La figure 1 reprend l’idée développée précédemment. Celle-ci permet à l’équipe de tester de nouvelles idées émergentes du développement effectué:
- Avantage: comme le projet a été cadré techniquement (on ne va quand même pas changer d’architecture ou utiliser des technologies bizarre?), les développeurs peuvent tester de nouvelles idées pour le projet ou non. Comme les FedEx Days, cette journée permet de concrétiser des idées, innover.
- Inconvénient: je ne vois pas sur le coup
- Risque: il y aura toujours quelqu’un pour « troller », tenez bon
La figure 2 est plus centrée sur le projet. En fait, entre PLANNING 1 et « , on laisse à la Scrum Team une journée pour « jammer » sur la proposition du Product Owner de sorte que ce dernier puisse avoir plusieurs options pour le sprint à venir.
Une option 3 reprenant les deux principes est une option tentante mais certes difficilement « vendable ».
A vous de juger!
Pierre
The Scrum Coach 
Article très intéressant. Mais est-ce vraiment assez 1j de « jam »? J’irais même jusque 2-3 pour profiter de cette session pour faire des tâches demandant moins de grosses réflexions, ou une mise à jour sur des technos utilisés.
1j n’est peut-être pas assez pour faire le vide intellectuelle et attaquer un nouveau projet.
Du moins, c’est ce que nous « essayons » de mettre en place dans notre équipe (L’application n’est pas toujours possible aussi 😉 )
Hello,
Je comprends ton approche. Dans ma vision, je recherche une approche systématique càd un « jam » à chaque itération.
Dans l’hypothèse de faire 3 jours de jam à chaque fois, le risque est d’être chronophage et de perdre l’équipe: elle risque de démarrer son sprint « épuisée ».
Mais l’idée est à creuser pour les projets R&D.
Pierre