La transformation agile
de projets SI existants est un enjeu majeur pour beaucoup des organisations
avec lesquelles nous travaillons au quotidien, je me propose ici de vous faire
part d’un retour d’expérience sur les pré-requis mais aussi l’accompagnement
nécessaire à une transition d’une organisation « cycle en V » vers
une organisation SCRUM. Ce retour
d’expérience est issu de 3 ans passés sur un projet d’environ 150 personnes coté
ERDF en pleine réorganisation. Pour illustrer, je me suis appuyé sur
quelques principes fondamentaux du manifeste agile
« Les individus et les
interactions plutôt que les processus et les outils ».
Les interactions entre
les individus sont au centre de l’organisation agile SCRUM. On cherche
notamment à supprimer les guichets que l’on peut trouver dans l’organisation
cycle en V (Une équipe MOA qui livre des SFG à une équipe MOE fonctionnelle,
qui livre des SFD à une équipe de DEV, qui elle-même livre des développements à
une équipe de recette unitaire puis à une équipe de recette intégrée …). Dans
une organisation SCRUM, la communication et l’échange entre le PO, la team et le
ScrumMaster est mis en avant et la documentation est secondaire. Il faut donc
éviter certaines organisations entravant ces échanges, comme par exemple une
team délocalisée de son PO.
Le commanditaire
(à comprendre le responsable du projet/client ayant fait la commande de cette
transformation …) doit s’engager et porter la transition, il doit comprendre
les changements nécessaires (que nous aborderons un peu plus bas) mais aussi
s’assurer que l’ensemble des interlocuteurs sous sa direction en fasse autant.
Il doit être porteur de cette transition au sein de son organisation. Il doit accepter
les compromis et les changements nécessaires aussi bien qu’il en accepte les
avantages. Ce travail doit être mené en amont de la transition par les porteurs
de cette réorganisation (voir coach agile plus bas). Si le commanditaire
lui-même n’est pas convaincu, la transformation a toutes les chances de ne pas
réussir.
« La collaboration avec les
clients plus que la négociation contractuelle »
La situation
contractuelle entre les différentes parties doit être claire et doit
correspondre aux enjeux de la méthode. Il est difficile de faire adopter
une méthodologie Agile à un intégrateur en mode
forfait qui est objectivé financièrement sur des jalons à respecter avec une
quantité de périmètre fonctionnel bien défini. Accepter et faire accepter de
piloter par les délais et de considérer le périmètre comme la
principale variable d’ajustement est essentiel. Petit rappel : le BackLog
des fonctionnalités désirées est priorisé strictement. A travers la vélocité
(capacité à développer) de la Team, on sait prévoir ce qui pourra ou non être
déployé à une date précise. Si on veut d’avantage de fonctionnalités, il faut
alors d’avantage de sprint pour permettre à la Team de les développer, la date
de la release doit être revue en conséquence. Et si la date de release est
fixe, alors on accepte de ne déployer uniquement les fonctionnalités validées à
cette date.
Une équipe SCRUM est
stable, autonome, responsable, volontaire et expérimentée. L’équipe s’engage
sur le périmètre embarqué à chaque SPRINT selon sa capacité. Elle doit rendre
compte au PO (Product Owner) de chaque US (User Story) non terminée. Elle est en charge de l’intégration
continue des développements, de
la mise en place de l’ingénierie nécessaire, de la gestion des environnements,
des bonnes pratiques (Revue de code, ATDD …)
Un exemple de composition
d’équipe SCRUM équilibrée est :
- 1/3
de profil junior
- 1/3
de profil sénior
- 1/3
de profil expert
Attention donc aux
équipes trop junior.
N’oublions pas :
« Une attention continue à l'excellence
technique et à une bonne conception renforce l’Agilité. »
La première raison de
l’échec de la transformation Agile d’un projet est le manque d’expérience dans
l’application du Framework Agile.
La solution ? Se
faire accompagner!
Lancer une
réorganisation de projet sans se faire accompagner par quelqu'un d’aguerri
s’ayant déjà frotté aux difficultés de ce genre de transition et sachant
comment y répondre, c’est comme faire une partie de tennis sans raquette, c’est
forcément plus compliqué...
C’est là qu’intervient le
coach agile, sorte d’expert / médiateur / psychologue / gourou de
l’agilité, il est présent pour accompagner les différentes parties, faire
accepter et faire respecter les principes agiles. Le coach agile est un vétéran de
l’agilité, souvent externe à l’organisation et missionné pour aider les équipes
à assimiler la méthode et rappeler à chacune des parties leurs droits et
devoirs. Attention à ne pas se méprendre sur son
rôle, ce n’est pas un magicien. Sans base solide (team volontaire, PO motivé,
commanditaire engagé …), le meilleur des coachs agiles ne pourra rien faire.
« L’adaptation au
changement plus que le suivi d’un plan »
Transformer
l’organisation d’un projet aussi radicalement que le passage de cycle en V en
SCRUM (ou toutes autres méthodes Agiles) demande un accompagnement des
personnes concernées, certains vont voir leurs rôles changer, d’autres vont
comprendre que leur activité au quotidien va totalement disparaitre.
Prenons l’exemple du
middle-management (chef de projet, responsable d’équipe …).Une équipe SCRUM est
autonome, responsable et s’autogère. La gestion des priorités du produit est
donnée au Product Owner. L’organisation des cérémonies et le support quotidien
à la TEAM est la mission du ScrumMaster. Comment donc repositionner un
responsable d’équipe dans le cadre d’une organisation SCRUM?
Peut-être est il
intéressant de lui donner le rôle de PO, mais attention dès lors à ce qu’il
ne s’immisce pas dans la gestion de la Team. Le faire intégrer la TEAM ?
Est-ce vraiment bon pour son
autonomie ? Il n’y a
pas de réponse toute faite à ces problématiques, la solution dépend des personnes, du contexte, des
enjeux…
« Des logiciels opérationnels plus
qu’une documentation exhaustive »
Le cycle en V repose
sur la croyance que l’on peut spécifier intégralement un logiciel à l’avance.
La somme de documentations nécessaires peut vite se révéler astronomique.
L’agilité prône une réduction drastique de cette quantité de documents au
profit de livraisons fréquentes et peu espacées dans le temps (« SPRINT »), permettant ainsi de répondre rapidement à de nouveaux
besoins. Si il y a un forte baisse des livrables nécessaires à la réalisation
d’un logiciel, en plus de l’accompagnement nécessaire à le faire accepter, il
faudra peut-être réfléchir à diminuer le nombre de personne dont c’était
l’activité. Les aspects RH de ce genre de décision peut facilement nuire à
l’engagement des collaborateurs concernés. Il convient donc de préparer et
d’accompagner cette transition.
La méthode SCRUM a de
nombreux avantages, mais nécessite une préparation et un accompagnement
quotidien, c’est d’autant plus vrai sur les projets de transformation d’organisation
existante vers l’agile (il est toujours plus facile de créer une
organisation à la cible que d’en faire transiter une existante). Ces efforts ne doivent pas être pris à la légère sous peine
de retarder le retour sur investissement, voir d’échec complet. Rappelons-nous
certaines valeurs SCRUM : humilité, transparence, confiance et courage.
