Tim Ottinger et Ruud Wijnands se sont exprimés lors de la QCon London 2015 sur la manière de retrouver la bonne vieille agilité du temps de XP et les raisons qui font qu'une partie a disparu en route.
Durant la présentation “Taking Back Agile”, ils ont commencé à explorer le sujet "si ça c'est de l'agile, reprenez-le" en soulignant les opposés, c'est-à-dire les éléments que l'agile a apporté en entreprise d'un intérêt faible ou nul. Leur message est : "Si ce n'est pas agile, débarrassez-vous en". Un certain nombre de causes sont identifiées, avec :
- Des rendez-vous interminables et une bureaucratie excessive.
- Des développeurs qui ne développent pas, en se concentrant sur le suivi de processus.
- Des équipes plus intéressées au management qu'à la pratique de l'ingénierie.
- Un fardeau pour l'estimation.
- L'accroissement de la vélocité corollaire d'une dette technique écrasante.
Dans la seconde partie de leur présentation, "Je voudrais retrouver mon Agilité, merci", ils proposent une méthode pour retrouver les bons aspects de l'agile et se débarrasser des mauvaises. La première idée suggérée est "d'arrêter d'espérer", parce que l'espoir limite l'action et les tentatives de résoudre ses problèmes. Dans la même veine, il y a la dualité entre "avoir l'air et devenir" - un individu devrait devenir un bon professionnel en partant du bas, en posant des questions bêtes, en faisant des erreurs stupides, en apprenant et devenant quelqu'un. Ils expliquent que lorsque quelqu'un s'inquiète surtout d'avoir l'air d'être quelque chose, cela l'empêche d'apprendre.
L'action est le point suivant de la présentation. Ils présentent le premier projet XP connu et les deux questions qui l'orientait :
- Qu'est-ce qui a bien marché pour nous précédemment ?
- Comment pouvons-nous mieux faire ces choses ?
Les personnes travaillant sur ce projet pensaient à la manière de procéder (agir) pour répondre aux deux questions. Ils systématisèrent les tâches casuistiques aussi souvent que possible. Voici quelques exemples :
- L'intégration de Code et les tests.
- La communication avec les autres.
- La compréhension des attentes clients.
L'idée clé ici est, pour reprendre les propos de Martin Fowler sur son blog : "Si ça fait mal, faîtes le plus souvent".
Pour mettre un plan comme celui-ci en action, ils suggèrent que les équipes aient des droits et des permissions. Les droits correspondent aux premiers jours de l'agile comme la proposition de ses propres estimations, le droit de décider, de terminer un travail, de savoir ce que veut le client.
Par rapport aux permissions, ils rappellent que personne n'a besoin de permissions pour faire du bon travail donc, "Ne demandez pas la permission ! Trouvez-les !"
Bien sûr, tout ce qui est présenté ci-dessus implique que vous "Preniez la responsabilité de votre travail !". Le faîtes vous ?