Autonomie

En réaction au principe de la hiérarchie, renforcée par la division du travail, l’agilité propose une distribution du pouvoir donnant son autonomie à l’équipe.

Les problèmes liés au pouvoir hiérarchique

La hiérarchie, avec un chef et des subordonnés, a été instaurée pour prendre des décisions rapidement. Plutôt que de rechercher le consensus, le chef décide. Effectivement cela va plus vite. Mais cela crée des frustrations, voire des problèmes, en voici quelques-uns.

Équipe mal formée

Problème : les personnes sont placées dans une équipe sans réflexion sur leur complémentarité et sans demander leur avis.

Une telle pratique est évidemment catastrophique pour l’avenir de l’équipe. La constitution d’une équipe bien formée demande du temps, de la réflexion et des discussions.

Pour insister sur son importance, j’en ai fait une des cinq parties de mon livre Scrum, qui s’appelle le prélude ; il sert notamment à définir le partage du pouvoir ; il inclut une réflexion collective sur les rôles de chacun.

Lire un article de présentation du prélude.

Autoritarisme

Problème : les responsabilités sont concentrées en une seule personne.

Dans un système hiérarchique, les employés peuvent souffrir du manque de dialogue, dans le cas où le chef a été imposé et ne bénéficie pas d’une autorité naturelle pour son équipe. L’ambiance se détériore.

Avec l’agilité, la facilitation est l’art d’augmenter le pouvoir d’agir d’un groupe.

L’agilité incite l’équipe à s’organiser elle-même pour effectuer le travail. Le Scrum Master est là pour faciliter cette auto-organisation et mettre les coéquipiers en confiance. Cette facilitation, qui permet à l’équipe de décider et de s’engager, possède donc un sens.

La plupart des décisions sont collectives. Pour ne pas ralentir certaines décisions, des leaders sont désignés, ponctuellement comme dans la sollicitation d’avis ou avec le rôle de Product Owner pour les décisions sur le produit.

Maîtrise d’ouvrage

Problème : Les décisions concernant le produit sont prises à l’extérieur de l’équipe.

Pour illustrer ce problème, je reprends les notions anciennes, de MOA et MOE :

• Maîtrise d’ouvrage et maîtrise d’œuvre sont des notions issues de la gestion de projet dans l’industrie.
• On en trouve encore des traces dans les situations où les coéquipiers n’ont pas de contact avec les utilisateurs, c’est une personne qui décide de tout.
• L’équipe exécute ce qu’on lui demande de faire.
• Le résultat obtenu est déconnecté des besoins.

Mes articles (de 2007 !) pour abandonner MOA et MOE.

La réponse de l’agilité a été de proposer le rôle de Product Owner et de la placer à l’intérieur, dans l’équipe.

Tour d’ivoire

Problème : les décisions techniques sont prises par des experts.

Ils décident sans mettre les mains dans le cambouis, en restant dans leur tour d’ivoire. Les coéquipiers en sont réduits à appliquer des solutions qui ne sont pas les leurs.

L’agilité apporte des réponses avec des pratiques issues du développement de logiciel comme :

• le mob programming,
• la propriété collective du code.

L’autonomie, une zone d’agilité à défendre

L’autonomie d’une équipe est sa capacité à se donner elle-même sa propre loi, à définir ses propres règles.

Il n’y a donc pas de chef. Pour une équipe, être autonome ne veut pas dire qu’elle fait ce qu’elle veut. C’est une exigence d’ouverture et de rigueur, pas de laisser-aller ou de chacun pour soi.

Au sein du collectif, la place et le bien-être de l’individu sont importants. Comme il n’y a pas de chef qui définit et assigne les tâches, ce sont les coéquipiers qui décident comment décomposer le travail et l’accomplir. Il n’y a pas non plus de rôle spécialisé (architecte, développeur web, testeur, etc.). Chacun se détermine et le Scrum Master (ou équivalent avec un autre nom) facilite la vie de l’équipe. L’ambiance dans l’équipe s’en trouve améliorée.

Antipatterns

L’autonomie est un principe qui avec, la démarche pragmatique et la confiance, concourent à un fondamental de l’agilité : l’auto-organisation.

Cependant pour les équipes en quête d’auto-organisation, attention à quelques points constatés sur le terrain qui limitent l’autonomie d’une équipe agile :

• PO proxy : le vrai PO reste à l’extérieur de l’équipe
• Discussions sans prise de décision : on délibère mais cela n’aboutit pas à une prise de décision, on reste dans le flou.
• Démesure de la grande échelle : comme il a été décidé au niveau de l’organisation d’utiliser un framework à grande échelle qui impose des règles, une équipe perd une grande partie de son autonomie.

La défense de l’autonomie

L’équipe agile défend son autonomie :

• en s’opposant à la culture de la hiérarchie des organisations, qui perdure et est la source des problèmes mentionnés,
• en évitant les antipatterns qui font déroger à l’intention de définir ses propres règles.