Dans la première partie de cette série sur Scrum et l’organisation, nous avons vu en quoi cela affecte la liberté accordée aux équipes et la notion de travail d’équipe. Voyons voir maintenant les 2 autres domaines:
Le contrôle
Ce qu’implique adopter un modèle empirique
Beaucoup de gens ne comprennent pas l’empirisme. Cela peut parfois poser un problème sérieux.
L’empirisme signifie travailler de manière factuelle, basée sur les observations et sur l’expérience. En effet, Scrum met en œuvre un processus empirique dans lequel les progrès sont basés sur des observations de la réalité et non sur des plans théoriques. Scrum accorde également une grande importance à l’esprit et au changement de culture pour atteindre l’agilité organisationnelle voire même commerciale.
Vous ne pouvez pas simplement supprimer votre ancienne méthodologie de gestion de projet pour la remplacer par Scrum et vous attendre ensuite à pouvoir continuer avec les plans de projet et les feuilles de route habituels.
Par conséquent si vous passez de waterfall à Scrum, vous ne pouvez pas simplement promettre à un client qu’une fonctionnalité sera mise en ligne dans x mois.
En outre, vous n’utilisez pas Scrum comme prévu lorsque vous décidez de vous écarter de la « définition de fini », par exemple en ignorant les tests de non-régression, afin de tenir une date limite.
Avec Scrum, vous introduisez un cadre basé sur l’empirisme. Cela signifie que des cérémonies, des artefacts et des rôles sont créés à cette fin. Voici quelques exemples:
- Une revue de sprint pour inspecter l’incrément et adapter le backlog du produit si nécessaire,
- un contrôle quotidien pour vérifier ce que l’équipe a découvert et son impact sur l’objectif de sprint,
- une définition de fini pour pouvoir inspecter l’incrément,
- un Scrum Master pour aider les parties prenantes à comprendre Scrum et le développement de produits empiriques.
Quand il y a des frictions avec les entités extérieures à l’équipe Scrum
Lorsque l’équipe Scrum travaille dans un environnement empirique mais que des personnes extérieures aux équipes Scrum ne s’y adaptent pas, vous rencontrez de graves carences d’alignement, telles que concernant:
- La manière dont les engagements sont pris
- Quand attendre quelle fonctionnalité
- Le but d’un incrément de travail
- La manière de coopérer avec une équipe Scrum
En résumé
Pour résumer ce paragraphe, on peut dire que sous l’approche incrémentale et itérative, le produit final nait après une vaste expérimentation et l’obtention d’un feedback des utilisateurs finaux et des parties prenantes. Par ailleurs, « itératif » signifie qu’on apporte des modifications au résultat des étapes précédentes. Donc, cela conduit automatiquement à changer les règles du jeu, à laisser de côté les traditionnels contrats à dimensions périmètre-prix-temps figés et à basculer vers une coopération directe entre l’entreprise et le développement. Cela implique-t-il des changements organisationnels potentiels? Probablement.
Les organigrammes
Scrum est un moteur de changement organisationnel qui aide les entreprises à devenir plus agiles et résiliantes. Par conséquent, une mise en œuvre correcte entraîne des changements inévitables dans la structure organisationnelle, sa simplification (« aplatissement ») ou sa déflation.
Si votre organigramme n’a pas changé après la mise en œuvre de Scrum, cela peut vouloir dire deux choses:
- Soit vous êtes absolument génial et agile, et votre structure organisationnelle actuelle est déjà optimisée pour Scrum. Toutes nos félicitations!
- Soit (très probablement), Scrum n’a été mis en œuvre qu’à moitié, et la gravitation organisationnelle a remporté la première bataille, de sorte que le statu quo et les structures de pouvoir sont restés intacts. Si c’est la cas, n’abandonnez pas!