Equipes agiles & principes d’engagement dans l’entreprise

« Commitment is dead? Hooray! »

Les fondateurs de SCRUM Ken Schwaber et Jeff Sutherland ont dans la dernière version du guide SCRUM, supprimé la notion d’engagement.

Que veut dire engagement ? sur wikipedia.. : « L’engagement est la base du mécanisme de soumission librement consentie. » bon ça va surement nous aider ..

1°) Engagement ?

Quand je commence une explication sur l’agilité, j’aime parler de l’histoire de la poule et du cochon, que je n’expliquerai pas içi (voir la poule et le cochon). L’histoire exprime la différence entre « engagement » et « participation ». L’un (le cochon) est engagé sur le projet, l’autre (la poule) ne fait que participer. Ok maintenant il s’agit de comprendre comment ces cochons et les poules apparaissent dans la structure traditionnelle de l’entreprise ?

2°) Engagement de résultat

Dans l’entreprise « traditionnelle » les équipes sont indépendantes et segmentées sur les différentes activités de compétence : DSI (Gestion du système d’information), Business (entités métiers, unités opérationnelles) et Utilisateur (client de l’entreprise ou utilisateur au sein de l’entreprise). Ces différentes équipes de la DSI  (Analystes, Développeurs, Infrastructure/Prod, Architecture du SI …) et celles du coté business et les utilisateurs  jouent le jeu de la « collaboration »… qui est en général basé sur une relation client/fournisseur (L’entreprise étant structure par « offre de service » entre les entités, définie contractuellement par des cahiers des charges et qui suivent le traditionnel triangle coût, qualité, délais). Cette relation constitue un engagement de résultat, c’est-à-dire « je veux ceci, fait le moi à ce coût, donne le moi pour cette date » :

3°) Problématique de l’engagement de résultat :

L’engagement de résultat sépare les compétences aux différentes entités de l’entreprise, à tel point que certaines personnes n’ont pas conscience de la vision et de la valeur business de la tâche qu’il réalise par rapport au produit sur lequel il travaille. Par exemple : si un projet échoue , une grande partie des intervenants de cette structure ne seront pas affecté, surement qu’ils ne seront pas prévenus d’un échec ! Les responsabilités sont limités à la sphère d’activité de chaque équipe. La segmentation des compétences et le principe d’engagement sur le résultat ne font que créer un système ou chacun est poule et donc inconscient de la bonne cohérence de ce qui se réalise sur le projet. Généralement un projet fait vite appel à au moins 50 intervenants différents, autant de goulots d’étrangement et surtout l’impossibilité de chaque intervenant de connaitre le contexte de tous les projets. tout est prévu pour que chacun soit investi sur son travail, mais impossibilité de s’investir sur le projet. On est tous d’accord pour dire que cela n’est pas agile.

4°) Engagement de moyen

L’un des principes de l’agilité (de scrum en particulier) est la proximité et la disponibilité. Et donc d’avoir une équipe unie, réduite, complètement investie au projet. Cette équipe va opérer une relation de confiance, et aussi un engagement de moyen. C’est à dire que l’équipe va s’engager à mettre tous les moyens intellectuels, matériel, de disponibilité pour réaliser le projet. Par contre elle ne va pas s’engager sur le résultat de produit.

4°) Engagement dans l’entreprise

Pour la mise en place d’un projet agile au sein de l’entreprise : scrum préconise de créer une équipe intégrée entre l’utilisateur, le business, l’équipe de développement. Ne plus parler de relation client/fournisseur dans cette équipe, mais bien entendu d’engagement de moyen.

Et comme toutes les entreprises ne sont pas des startups à monoéquipe, la difficulté est « comment » cette équipe doit interargir avec le reste de l’entreprise, et notamment par la multitude d’exigences structurelles et transverses de chaque projet au sein de l’entreprise (Architecture, Urbanisation, Méthodes, Dépendance avec d’autres projets, Dépendance avec le SI…). Malheureusement ces équipes ne peuvent pas être à 100% dans le projet puisqu’elles sont transverses.

Je donne un exemple :

Une équipe SCRUM mobile réalise une application iPhone et a un besoin ponctuel, il s’agit d’avoir accès au S.I. via un WebService. Ce WS sera être réalisé par une personne dédiée, un développeur du domaine fonctionnel concerné.

5°) Comment l’équipe va gérer cette dépendance ?

Voici les trois possibilités (cf. bulles bleus du schéma ci-contre) :

  1. Le développeur fait partie d’une équipe indépendante, qui traite plusieurs demandes venant de la DSI. Son travail n’est pas inclut dans le backlog, il s’engage sur le résultat: cout, qualité, délais. il reste poule dans le système. Cela va de pair avec les pressions et insatisfactions du demandeur.
  2. Le développeur est complètement intégré à l’équipe. il s’engage donc sur les moyens. Il travaille au même titre que l’équipe intégrée à 100% au projet et devient membre de l’équipe à part entière, et s’investit sur le projet dans sa durée complète. C’est la définition classique de l’équipe scrum. Malheureusement ce cas est difficile à obtenir pour des intervenants transverses ne peuvent pas être disponibles à 100%.
  3. Le développeur ne fait pas partir de l’équipe intégrée, mais participe  pleinement et régulièrement au cérémonial agile du projet (pas à 100%, mais une partie de son temps à intervalle régulier, par exemple deux fois par semaine…), il est au courant de l’évolution du projet, il connait la vision du projet. Il ne va pas réaliser le travail par rapport à une demande de l’équipe, mais par rapport à sa propre implication dans le projet. Son travail est identifié dans le sprint backlog et donc timeboxé au même titre que l’équipe intégrée. (il peut par exemple lui même créé/déplacer des taches le concernant sur le story board).  il s’engage aussi sur les moyens.

6°) Trois type d’équipes

J’identifie donc trois types d’équipe diffèrent : équipe intégrée & équipe engagéeéquipe participante. On aura compris que la plus agile est l’équipe intégrée, et la moins (pas) agile, l’équipe participante.

Ces équipes ont des engagements de types différents soit « de résultat« , soit « de moyen« .

Pour revenir à notre exemple, le développeur webservice pourra être intégré dans l’équipe engagée. il aura donc la visibilité et la possibilité de s’engager complètement sur le travail à faire, au lieu d’être poule dans le système. 

Quelles différences entre l’équipe intégrée et l’équipe engagée ? 

Les intervenants de l’équipe engagée réalise des tâches pour une feature donnée, et ne participeront certainement pas sur la durée du projet. (Le principe des équipes engagées se rapproche à ce qui est définit dans les « features team » dans le sens ou une équipe éphémère (le temps de réaliser la feature) se créé et disparait à la fin de la feature.

Les intervenants de l’équipe engagée n’interviennent qu’une fraction de leur temps (car ils ont une multitude d’autres implications), alors que l’équipe intégrée est à 100%.

7°) adapté aux DSI ?

Voici, pour moi, le modèle qui permet d’être en cohérence avec les contraintes des D.S.I., donnez-moi votre feedback et notamment si cela serait réalisable dans votre contexte.

Publicités

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s