Lors de la conférence Agile Eastern Europe 2015, Gill Zilberfeld a donné une présentation intitulée La nouvelle agilité. InfoQ en a profité pour faire une interview de Gill sur la façon de gérer les attentes qu'ont les organisations sur les méthodes agiles, la manière d'éviter les malentendus, les bonnes idées et bonnes pratiques issues de l'agilité et sur ce que nous réserve le futur.
InfoQ : Quelles sont les attentes typiques des organisations en termes de profits liés à l'adoption des méthodes agiles ?
Gill : Les organisations qui ont décidé de mettre en place leur voyage vers les méthodes agiles ont généralement une idée de ce qu'elles veulent mettre en place, ce qui bien souvent est d'améliorer leur efficacité et leur productivité - livrer plus vite et diminuer les coûts. Ces attentes sont concordantes avec les objectifs traditionnels du management et les indicateurs clés de la performance d'une organisation. En se concentrant sur ces objectifs nets et précis, elles ne comprennent généralement pas l'investissement nécessaire pour arriver là et le temps que cela prend.
Le dernier point est crucial, parce qu'il existe beaucoup de sociétés qui vendent des certifications agiles après des formations très courtes ; on pourrait croire que la seule chose dont une organisation a besoin pour devenir Agile est une formation. La conception de l'agilité comme un état final, plutôt qu'un engagement continu pour une amélioration continue est une idée fausse, qui conduit généralement au constat : "Notre migration vers les méthodes agiles est un échec".
InfoQ : Avez-vous une idée de ce qui fait que les organisations aient cette vision des méthodes agiles ? Y a-t-il des choses que les consultants et formateurs agiles peuvent mettre en place pour éviter ce malentendu ?
Gill : Maintenant que Scrum a passé le cap, il s'inscrit dans les méthodes traditionnelles mises en oeuvre par les organisations pour former leurs employés. Les envoyer en formation, et hop ! Vous avez un professionnel certifié. D'un autre côté, le marché a réagi en fournissant ces formations et ces certifications. Le marketing qui a été mis en place autour de Scrum et de l'agilité a été articulé autour de l'amélioration de la productivité et de la diminution des coûts, il n'est donc pas étonnant que l'ensemble de l'écosystème ait fini par créer ces attentes.
Un autre problème avec la méthode Scrum est qu'elle "oublie" que l'excellence technique est la base de la création de logiciel durable. Au début de Scrum, les formateurs suggéraient les pratiques de l'eXtreme Programming pour adresser l'aspect technique. Scrum a gagné la guerre des méthodes agiles en parlant aux managers avec un langage de managers, orienté process, la partie technique était cachée. Ce qui n'a pas aidé, c'est que beaucoup de formateurs ne disposaient pas du background technique suffisant pour former les équipes au TDD, à l'intégration continue ou au code propre.
En tant que coach, je fais en sorte que les équipes travaillent sur les deux aspects - process et code. Je pense que les consultants agiles devraient inclure l'excellence technique comme une partie intégrante de leur plan quand ils travaillent pour un client. L'expérience de l'agilité de leurs clients en bénéficierait grandement.
InfoQ : Pensez-vous que les organisations récoltent les fruits de l'agilité ?
Gill : La véritable question est : Obtiennent-elles ce qu'elles espèrent ? Vous entendrez souvent des gens se plaindre à propos de la mise en place des méthodes agiles dans leur organisation. On dit souvent : "L'agilité ne résout pas les problèmes, elle les rend visibles". Les problèmes qui étaient dissimulés sous le tapis avant doivent maintenant être gérés. Et il y en a de nombreux.
Lorsque cela arrive, l'organisation doit faire en sorte de combiner la mise en place des nouveaux process et la gestion des problèmes "fraîchement découverts". C'est généralement à ce moment là que surviennent les déceptions face à l'agilité.
Si le dévouement est là, que le management ne lâche pas et s'engage pour résoudre les problèmes, ils tireront les bénéfices de l'agilité.
Dans ce cas, l'agilité devient un catalyseur pour mettre les problèmes en évidence. Si un problème était identifié dès le départ et qu'il y avait de l'engagement pour le résoudre, ils y seraient parvenus sans l'agilité.
InfoQ : Pouvez-vous développer sur les idées et les pratiques que l'agilité nous a apportées ? Quelles sont celles que vous considérez comme les plus bénéfiques ?
Gill : Il existe de nombreuses pratiques et principes qui sont bénéfiques. La pratique qui me tient particulièrement à coeur est la visualisation qui provient de kanban. Ce qui est drôle, c'est que le Manifeste Agile ne mentionne pas directement la communication, alors qu'il s'agit de l'élément de réussite essentiel. Et la visualisation du process est très puissante.
Plus les gens sont capables de visualiser à l'aide de dessins, de mind maps, de tableaux kanban ou de diagrammes d'états, plus ils disposent d'une base commune pour communiquer. La plupart de ces informations sont déjà dans nos têtes, mais nous ne disposons pas de cette référence commune, nous supposons que les autres savent ce que nous avons dans la tête, quel est l'objectif et comment y arriver. Le coût de création d'un dessin est très faible par rapport à ce qu'il peut apporter, c'est dommage que les gens n'utilisent pas plus ce genre d'outils.
Un autre élément qui apporte énormément est la mise en place de cycles courts. L'agilité a introduit des pratiques qui nous ont aidé à apprendre et à agir rapidement, en transformant notre manière de travailler d'une manière que nous n'aurions pas imaginé avant. Scrum dispose de mécanismes pour le feedback - la review et la rétrospective. Le TDD engendre un feedback rapide, et l'intégration continue nous permet de savoir si nous avons cassé une fonctionnalité directement après avoir soumis notre code. Et bien sûr, les outils de visualisation du process nous permettent d'avoir un feedback sur le process.
Si nous pouvons mettre tout cela en oeuvre dans une équipe, on peut le faire aussi en dehors. La mise en oeuvre de Lean Startup offre exactement ceci. Construire un MVP (Minimal Viable Product) rapidement et obtenir du feedback dessus. Ou changer une fonctionnalité d'un site, collecter des informations sur l'utilisation et pivoter. Une fois que nous possédons les bases techniques et que la méthode mise en place fonctionne, nous pouvons raccourcir les cycles de feedback, en faisant des expériences pas chères et de courte durée, en les sortant et en apprenant grâce à elles.
Le développement du produit est seulement le début. La méthode Beyond Budgeting marche exactement de la même manière avec l'aspect financier. L’organisation dispose d'un petit budget pour une période courte, et l'investit comme elle l'entend. Après cette période, l'organisation étudie le succès de l'investissement - s'il s'agit d'un succès, elle continuera à investir dans le budget suivant. Si c'est un échec, le projet est arrêté. Cette méthode est proche de celle que l'on utilise pour notre budget personnel, à l'aide de cycles courts. Les organisations apprennent maintenant à faire la même chose.
InfoQ : A quoi devons-nous nous attendre dans le futur, selon vous, au sujet des méthodes agiles ?
Gill : Si les 15 dernières années nous ont apprises quelque chose, c'est que l'agilité se développe dans d'autres secteurs que dans celui du développement logiciel originel. Le mouvement Beyond Budgeting se base sur la mise en place d'expériences courtes et défie l'idée du gros budget annuel. L'Extreme manufacturing crée des machines bon marché, adaptées au besoin, de manière incrémentale, à l'aide de cycles courts, parfois quelques jours. Les pratiques de développement telles que le TDD font maintenant partie des logiciels embarqués, de même que la preuve formelle.
Rajoutez de la complexité, qui saura vous dire où l'agilité nous mènera.
InfoQ couvre la conférence Agile Eastern Europe avec des news, des interviews et des articles. Précédemment, InfoQ a publié l'article L'adoption de l'agilité dans l'Europe de l'Est.