Les équipes agiles ne feront pas le travail
Auteur : Nick Oostvogels
Source : Agile teams won't do the trick
Date : 06/06/2012
Traducteur : Fabrice Aimetti
Date : 06/06/2012
Traduction :
Pourquoi y a t-il tant de tentatives d'adoption du lean ou de l'agilité qui ne mènent pas aux résultats attendus ?
- Est-ce par manque d'expérience ?
- Est-ce qu'il n'y a pas assez d'énergie consacrée à apprendre ?
- Est-ce qu'on oublie de gérer le changement ?
- Est-ce qu'on n'applique pas l'Agilité selon les règles établies ?
- Est-ce qu'on n'a pas recruté un coach expérimenté ?
- Peut-être qu'on a oublié les pratiques techniques ?
- Est-ce parce que l'approche est descendante, ascendante, centralisée ou menée de l'intérieur ?
- Est-ce parce qu'on n'a pas maîtrisé la complexité ou qu'on n'a pas suffisamment pensé systémique ?
- Ou parce que le portefeuille de projets n'est pas en adéquation ?
- Peut-être qu'on doit faire plus de jeux d'innovation ou de jeux sérieux ?
- Ou se concentrer sur l'amélioration continue ?
C'est possible ! Mais dans de nombreux cas, j'ai vu que cela était plutôt lié à la conception de l'organisation.
Pourquoi pensez-vous qu'en créant une équipe agile, vous réaliserez ce travail ?
Les équipes agiles s'engagent à livrer de la valeur à intervalles réguliers. Elles travaillent en l'espace de quelques semaines sur une liste d'opportunités métiers, souvent formulées sous formes de user stories ou de features. Les équipiers collaborent à fond pour analyser, développer, tester et livrer l'ensemble. Leur engagement est fort et simple.
Cependant, pour réussir à faire ça, les équipiers dépendent de personnes qui sont en dehors de l'équipe de développement agile. Des responsables d'entités métiers, des ingénieurs systèmes, des marketeux, du support à la clientèle, ... qui sont tous des individus appartenant à des entités différentes de l'organisation qui ont d'autres sujets d'engagement :
- L'engagement de maintenir opérationnel l'existant.
- Un autre engagement qui est d'élargir la clientèle.
- Et même d'autres engagements comme minimiser les changements, par exemple le support à la clientèle.
Même si le principal objectif d'une équipe de développement agile est de livrer des fragments de valeur à intervalles réguliers, il s'agit d'un objectif mineur pour les autres. Ne soyez donc pas surpris si cela a un impact sérieux sur le taux de réussite des livraisons menées par l'équipe de développement agile :
- Les user stories ne sont pas finies au cours de l'itération parce que le représentant métier n'a pas la disponibilité nécessaire pour les valider.
- La prochaine version ne peut pas partir en production parce que le support n'a pas eu le temps de se préparer.
- L'exploitation a décidé de retarder l'installation parce qu'elle a eu un problème de capacité de stockage.
Comment pouvons-nous recueillir les bénéfices d'un processus qui embrassent le changement si le reste de l'organisation fait le contraire ? Donc, au lieu de promettre des résultats grandioses dans le cadre de mon coaching agile, je commence désormais par observer l'organisation. Et dans la plupart des cas, je dois transmettre le message suivant :
Coacher vos équipes n'apportera pas une grande valeur ajoutée, en tout cas pas tant que nous ne commencerons pas à revoir la conception de l'organisation.
Le plus drôle c'est que cela ne surprend pas la plupart des managers.
Certains sont d'accord pour prendre le risque et essayer. J'en ai trouvé un ! une espèce rare, qui est plus préoccupé par la réussite de son entreprise que de couvrir ses arrières. Selon moi, c'est là que vous pouvez apporter de la valeur ajoutée en tant que coach. En l'aidant à concevoir une organisation qui tire avantage des changements et feedbacks permanents.
