RTE : le calendrier

Continuons notre visite des activités du RTE. Aujourd’hui, une pratique simple, mais parfois malmenée : le calendrier.

Après un tour vers le flot de valeur, venons-en au calendrier, à deux vitesses :

  • Program Increment (PI)
  • Itération, y compris Innovation and Planning (IP) Iteration.

Avant de planifier…

Planifier… Mais quoi ?

Un PI est constitué de plusieurs itérations (SAFe utilise le terme classique d’itération et pas « sprint » comme dans Scrum). Plus une itération particulière (qui n’en est pas vraiment une… petite inconséquence de SAFe ici) : l’IP itération.

Plusieurs questions importantes, dont la réponse dépend de plusieurs paramètres comme l’efficacité de la tool chain de build ou bien tout simplement le mode de pilotage (plutôt teinté ou pas de waterfall).

  1. Quelle durée pour les itérations « de prod’ ?
  2. Combien d’itérations ?
  3. Quelle durée pour l’IP itération :
    • Uniquement une semaine d‘Inspect & Adapt + prochain PI Planning
    • Deux semaines pour l’innovation, la formation… Bref pour casser le rythme aussi.

Notez que l’innovation est un pilier de la maison Lean dans SAFe. D’ailleurs, la question n’est pas d’être conforme à SAFe. La question serait plutôt : notre organisation existera-t-elle encore demain sans innovation aujourd’hui ?

De même, le PI Planning est bien sûr un événement consacré… à la planification (du prochain PI). Mais pas que. Le cœur est aussi l’alignement, valeur phare de SAFe. D’où l’importance dans cet événement :

  • d’une vision produit digne de ce nom (ce sur quoi tous s’alignent…)
  • de la participation active de tous (sinon autant revenir à la « grosse session de planification » avec quelques élus)
  • des PI objectives élaborés par les équipes elles-mêmes à partir du contexte transmis au début, ce qui permet de conforter cet alignement entre contexte et objectifs des équipes.

Mais revenons à notre planification.
Les principes sont autant de « guides » qui permettent d’adapter SAFe tout en restant dans le cadre. Par exemple, le principe de feedback concret et rapide incite à diminuer les durées plutôt que les augmenter, toute chose égale par ailleurs.

Outre-mer et autres localisations

Cela va sans dire mais lorsque le train n’est pas co-localisé et est constitué d’équipes inter-nationales, il convient bien sûr de tenir compte

  • des us et coutumes locales, y compris les jours fériés
  • des fuseaux horaires pour les cérémonies
  • sans parler de la culture spécifique à chaque pays.

À quoi sert ce planning ?

J’ai tellement entendu de croyances insensées comme par exemple « en agile on ne planifie pas » qu’il est peut-être utile de rappeler que la planification est partie intégrante d’un fonctionnement agile. Voir pour cela le post-liminaire du Manifeste agile.

Ici, le planning permet de cadencer et synchroniser le fonctionnement du train. Ainsi, de mieux gérer les dépendances, le rythme des livraisons, etc. Pour le dire autrement, la fin d’une boite de temps, que ce soit le PI ou l’itération, ne dépend que d’un critère : la date. L’état dans lequel nous arrivons à la fin de la boite de temps… c’est autre chose.

Et bien sûr, ce planning de plusieurs PI permet tout simplement de s’organiser.

Enfin, notons – rappelons… – ces deux bases de la planification agile :

  1. le planning est basé sur des besoins (features, stories…) et pas sur des activités
  2. le postulat de complexité (voire de VUCA) de l’éco-système amène à utiliser des leviers d’adaptation du plan, au fur et à mesure des feedbacks
    • contenu
    • budget
    • planning (des livraisons)
    • dette technique.

Ce que l’on appelait le Planning Game dans l’Extreme Programming.
Pour le dire autrement, le calendrier lui-même devrait être gravé dans le marbre, sauf exception, car c’est sur cette base que vont être planifiés bien d’autres événements (congés, formations…). Si ce calendrier se veut immuable, il n’en est pas de même du « contenu » : voir le Planning Game dito.

Prochainement, nous reviendrons sur la préparation du PI Planning grâce à l’exploration continue (tiens… « exploration », encore un terme de l’Extreme Programming).