SAFe – Premières impressions

Fin mai, j’ai eu la chance de participer à une formation de deux jours sur SAFe chez les cousins de chez Xebia (@BenjaminMoitie). 2 jours intenses. Pourquoi SAFe ? La grosse raison, c’est que TFS 2015 (et donc VSO avant) intègre ce framework. Il existe d’autres méthodologies pour faire de l’Agile dans de grosses équipes (Spotify, Scrum at Scale). Pour ceux que ça intéresse, Benjamin a participé à un Battle entre Spotify et SAFe.

SAFe, litéralement Scaled Agile Framework, qu’est-ce que c’est ? C’est une proposition pour implémenter la méthodologie Agile mais à plus grande échelle. En effet, passé une certaine taille d’équipe, gérer un projet Agile n’est plus aussi simple.

Les bonnes nouvelles, c’est qu’on ne jette pas tout et que de la documentation existe. Les mauvaises, c’est qu’on rajoute une sacré couche à l’agilité “habituelle” et qu’il y a une très grosse partie changement d’état d’esprit dans le top management.

Je ne vais pas essayer de vous condenser les deux jours dans un billet de blog. Je vais plutôt essayer de donner mon avis en tentant d’expliquer de grands principes qui m’ont paru intéressants en tant que développeur.

Présentation rapide

On ne s’engage pas dans SAFe si l’équipe fait moins de 50 personnes. Aucun intérêt vu les coûts de mise en place sinon.

On impacte toute la pyramide hiérarchique pour mettre en place SAFe. Tout le monde doit participer, sinon, c’est l’échec assuré.

Les bonnes nouvelles

Documentation

Beaucoup de documentation est disponible sur SAFe, mais il y a un site web qui reprend tout : http://www.scaledagileframework.com/

L’ensemble de SAFe est résumé en un schéma disponible en page d’accueil du site. Comme ça, il peut être un peu imposant, mais après deux jours, tout s’éclaircit. D’ailleurs, à partir de ce schéma, tous les éléments étant cliquables, on peut obtenir toutes les informations nécessaires.

Ca reste de l’Agile

Deuxième bonne nouvelle, on ne jette rien. On encadre et on synchronise :

Les équipes Agiles, telles qu’elles existent aujourd’hui, ne bougent pas. On va juste changer un peu le calendrier et le rythme de travail.

On collabore tous ensemble : les Innovation & Planning (IP)

Sans rentrer dans les détails, on se donne le temps de bien travailler ensemble. Sur 5 itérations / sprints, la dernière itération est réservée aux tâches qu’on ne prend jamais le temps de faire : passer 2 semaines à ne pas produire quelque chose de visible, ça ne passe pas forcément très bien en haut. Donc, pendant 2 semaines, on prend le temps de faire des mises à plat du projet, des hackatons…
Mais surtout, on prend 2 jours pour communiquer entre équipes, se synchroniser, échanger. Donc, pendant 2 jours, on s’enferme et on planifie la suite
C’est un résumé, mais en tant que développeur, c’est une tuerie.

Les mauvaises nouvelles

Il y en a quand même.

Changer les mentalités

On fait bouger toute la hiérarchie. Comme dit plus haut, les équipes restent en mode agile. Il y a toute une chaine à bouger, à faire changer souvent.
Si on reprend l’exemple des IP, il faut faire passer au management que, pendant 2 semaines, les équipes risquent de ne pas livrer en production, même si on fait tout sauf ne rien faire.
Bref, c’est sans doute la partie la plus compliquée à vendre de SAFe.

La mise en place

En admettant qu’on arrive à convaincre le management, en admettant, l’étape suivante est la mise en place.
De ce que j’ai vécu, la mise en place de la méthodologie Agile est parfois un peu longue et compliquée. Il faut se roder et ce même quand on est qu’une dizaine dans une équipe. Faire bouger entre 50 et 100 personnes, ça peut prendre du temps, d’autant que les changements sont, mine de rien, assez nombreux. A voir.

D’ailleurs, si vous fouillez sur le site de la méthodo, vous trouverez des témoignages d’équipes qui ont réussi à mettre ça en place : Nokia, Intel, même un constructeur de tracteurs !

Et l’outillage dans tout ça ?

Je ne vais pas m’étendre sur le sujet dans ce billet, mais les équpes MS ont déjà commencé à implémenter quelques notions SAFe dans VSO et TFS 2015. Il existe aussi d’autres outils pour faire du SAFe, mais on s’attardera sur TFS et on fera cela dans un autre billet.