Le changement dans la stabilité

L’agilité accueille favorablement le changement. Les clients peuvent changer d’avis et la technologie évoluer.

Mais l’équipe, elle ne doit pas changer pour être capable de prendre cela en compte. C'est grâce à sa stabilité qu'une équipe peut s'adapter à la situation et traiter les changements.

équipe en recherche de stabilité Une équipe en recherche de stabilité (dessin de Patrice Courtiade pour #scrum4)

Je constate que ce n’est pas le cas dans de nombreuses organisations. Indépendamment de la mise en place de Scrum et généralement bien avant, s’est développée une idée de l’agilité qui n’est que de la flexibilité imposée.

Les gens sont parfois considérés comme des ressources interchangeables, que des managers disposent à leur gré dans des pseudo-équipes, au rythme des réorganisations.

Souvent, ils travaillent sur plusieurs projets en même temps. Ce n’est pas un problème si c’est la même équipe qui est sur plusieurs projets. Mais si une personne multi-projets change d’équipiers pour chaque projet, la notion d’équipe au sens Scrum ne peut pas exister.

Dans son livre « La comédie humaine du travail »[1], Danièle Linhart évoque cette instabilité :

… comme faisant partie du paysage habituel des entreprises modernes, qui se veulent adaptées à un monde plus fluctuant et exigeant.

Le changement perpétuel dans les relations crée une précarisation subjective, pour reprendre la formule de l’auteure[2], qui entrave la marche vers l’auto-organisation visée par Scrum.

La stabilité d’une équipe permet de laisser du temps aux gens pour se connaître, pour apprendre à mieux travailler ensemble en partageant ses connaissances ; c’est cela qui l’arme pour mieux réagir aux changements dans l’environnement.

Sur le même thème : Le chapitre 3 « les gens de Scrum », nouveau dans l’édition 4, dédie le sous-chapitre 3.2 à l’équipe Scrum et ses caractéristiques de taille, d'auto-organisation, de pluridisciplinarité, de stabilité et d'identité.

Notes

[1] sujet du dernier Klub de lecture Agile Toulouse, dont Cyrille a dessiné le résumé.

[2] qui sera "keynote speakeuse" au prochain Agile tour Toulouse

Commentaires

1. Le jeudi 29 octobre 2015, 16:54 par François BlueTurtle

On rencontre ce problème effectivement dans la plupart des organisations. Après plusieurs discussions avec des dirigeants, j'ai compris qu'il vient de plusieurs sources. Premièrement, quand on est en cycle cascadé (si y en a encore !) et que les analystes on finit leur boulot pour le projet A, ils ont moins de boulot. Comme le manager a pour objectif de charger ses équipes sous peine de downsizing, il accepte (voire influence l'organisation) pour démarrer de nouveaux projets, augmentant ainsi le WIP. Ensuite et peut être plus important, la pression financière crée une illusion. L'illusion que plus on commence de projets, plus on va faire de bénéfices (c'est même une cryance). On lance 12 projets et en fin d'année, aucun n'est proprement fini... Recette simple mais réalisation compliquée : Prioriser la valeur au niveau direction et accepter la limite capacitaire des équipes comme une contrainte dure. On comprend vite que pour prioriser, il faut avoir une vision... c'est pas toujours gagné d'avance...