Les enablers en agile – SAFe

Les enablers en agile sont des types d’items qui peuvent aider dans la création d’un backlog. Parfois détestés, parfois adorés, nous allons voir ensemble ce que sont ces enablers.

Les enablers en agile – SAFe

Les enablers ont été popularisé avec le framework SAFe. Cependant, ce concept portant parfois d’autres noms, est parfois une réponse pour des équipes en recherche de solutions pour rendre leurs « user-stories » indépendantes.

Les enablers sont des items du backlog qui prennent en charge les activités nécessaires pour amener les architectures à être opérationnelles pour créer les fonctionnalités futures. Ces items peuvent représenter :

• de l’exploration
• de l’évolution d’infrastructures
• de la conformité
• de l’évolution des architectures

Il faut cependant faire attention de ne pas utiliser ces enablers pour prévoir des mois de user-stories. Ces enablers doivent être utilisés pour rendre les user-stories du prochain sprint ou du sprint en cours indépendante. Si vous mettez des enablers pour prévoir les 6 prochains sprint voire plus, vous perdez les notions de KISS (Keep it simple stupid) recommandés en agilité.

Les types d’Enablers

Enablers d’exploration : ces items permettent de faire de la recherche, du prototypage voire d’autres activités nécessaires pour mieux comprendre les besoins du client. Il est possible de faire de l’exploration également dans me but de trouver des solutions potentielles ou définir des alternatives.

Enablers architecturaux : ces items sont créés pour construire des  architecture plus adaptées afin d’avoir des développements plus fluides et plus rapides.

Enablers d’infrastructure : ces items permettent de créer, d’améliorer et d’automatiser les environnements de développement, de test et de déploiement. Ils amèneront les équipes à avoir des environnements favorisant des développements plus rapides, des tests de meilleure qualité et d’avoir une livraison continue plus optimale.

Enablers de conformité : ces items facilitent la gestion d’activités de conformité spécifiques dont la vérification et la validation, la documentation et les approbations, ainsi que les soumissions et approbations réglementaires.

Au delà des simples items

Si dans les équipes scrum, les enablers sont en général de simples items, en SAFe, les enablers peuvent se situer à plusieurs niveaux. Au niveau des items, le SAFe propose comme nom : « enabler stories ».

Mais ce framework d’agilité à l’échelle propose deux autres niveaux au sein des backlogs :

Enabler Epics : ces epics sont écrits en utilisant le format ‘Epic Hypothesis Statement’, de la même manière que les epics business. Attention, en SAFe, les Epics représentent un regroupement de stories ce qui dévie de la définition originale des epics (voir article sur les epics). Ce type d’epics vont traverser les value stream et les program increment (PI). Pour faciliter leur mise en œuvre, ils doivent inclure un ‘Lean Business Case’ et sont identifiés et suivis avec le Kanban du Portfolio. Ces epics peuvent aussi être créé au niveau des couches Large Solution et Program de SAFe.

Enabler Capabilities and Features : ces enablers s’appliquent au niveau des couches Large Solution et Program de SAFe. Étant donné que ces catalyseurs constituent un type de fonctionnalité ou de capacité, ils partagent les mêmes attributs :

• une phrase
• une hypothèse d’avantage
• des critères d’acceptation.

Ils doivent d’ailleurs être structurés pour être réalisés au sein d’un même PI.

Conclusion enablers

Bien que SAFe peut amener à utiliser des enablers pour des prévisions très avancées, je ne peux que vous recommander de les utiliser pour du court terme.

Cependant, pour les équipes scrum classiques, je ne peux que vous recommander de n’utiliser ce concept que si il répond réellement à vos besoins. Ce concept bien qu’il soit complet peut amener votre scrum à se complexifier.