14 June 2019

Les 7 pièges les plus fréquents des transitions agiles


hubspot-blog_headers_agile_5

Il n'existe pas de mode d'emploi permettant une transition vers un fonctionnement agile, mais des experts proposent leur aide aux entreprises. Steven Happee est l'un de ces experts. Steven a assuré le coaching de plusieurs organisations dans leur transition agile et pointe les pièges à éviter.

La passion de Steven Happee pour la méthode agile est née dans les années 1990. À l'époque, il développait un petit logiciel multidisciplinaire d'équipe qui était déjà dans l'esprit agile : de nombreux contacts avec les clients, un apport de valeur, un travail transparent.

Aujourd'hui, vingt ans plus tard, il aide les entreprises à effectuer la transition vers une organisation agile et apprenante. Pour ce faire, il met à profit sa grande expertise acquise en tant que Product Owner, Scrum Master, développeur et manager afin d'ouvrir la voie à des expériences de grande valeur. Sur cette base, Steven nous indique les sept pièges les plus fréquents d'une transition agile.

1. Viser une approche uniquement descendante

Les transformations agiles peuvent être abordées de deux manières différentes : par une approche descendante ou ascendante. Dans le cas d'une approche ascendante, une équipe (souvent informatique) prend l'initiative d'adopter une méthode de travail plus agile.

Dans le cas d'une approche descendante, l'initiative vient d'un directeur, d'un CEO ou d'un CIO ; l'objectif est souvent de rendre plus agile l'intégralité ou une grande partie de l'organisation. L'approche descendante est relativement nouvelle. Ces dernières années, la méthode agile est devenue un sujet brûlant ; de plus en plus de CEO et de CIO pensent à opter pour une organisation plus agile. L'idée est bonne, mais ne peut pas se concrétiser sans une certaine base dans l'entreprise.

Une approche uniquement ascendante est plus à même de fonctionner. C'est souvent le cas dans les équipes informatiques, d'où est évidemment née l'idéologie agile. Un membre de l'équipe veut en faire l'expérience, son responsable est enthousiaste et une équipe Scrum est créée. Si tout se passe bien, ces membres pourraient emboîter le pas à plusieurs équipes et ainsi éveiller la curiosité du reste de l'organisation.

Ce qui fonctionne le mieux, c'est bien sûr la combinaison des approches descendante et ascendante : une équipe prend l'initiative de devenir plus agile et éveille l'intérêt du sommet de l'organisation, qui lui confère alors son soutien.

Vous voulez savoir pourquoi agile n'implique pas nécessairement la fin d'ITIL ? C'est par ici »

2. Appliquer une transition agile par la méthode en cascade

Il y a dix ans, beaucoup de gens estimaient encore qu'une transition agile devait se faire selon la méthode Prince2. Il s'agit d'abord de créer un projet, de l'élaborer par étapes, de définir des échéances, etc. Évidemment, c'est paradoxal.

Heureusement, la plupart des gens sont aujourd'hui convaincus qu'une transition s'aborde également selon une méthode agile. En effet, la transition vers l'agilité est un projet complexe. Il s'agit donc d'un genre de méta-agilité : les personnes collaborent entre elles différemment, la méthode de travail est remodelée et on adopte de nouveaux outils. Cette transition se veut donc itérative avec une équipe multidisciplinaire et un backlog de changement. Vous donnez alors directement le bon exemple.

3. Se montrer trop strict dans l'application des techniques

Les schémas agiles comme Scrum offrent des techniques d'intégration des principes agiles dans la pratique. Un backlog, des stand-ups, des rétros – des éléments tout à fait visibles. Ces techniques ne représentent toutefois que le sommet de l'iceberg ou la partie visible de la méthode agile. Elles se basent sur certaines idées à l'égard de la manière de structurer le travail et qui s'appuient à leur tour sur des principes comme ceux repris dans le manifeste Agile ou dans Modern Agile.

Certaines personnes ont tendance à suivre les techniques à la lettre, sans en comprendre les principes sous-jacents. Des problèmes peuvent alors survenir. Certaines techniques ne fonctionnent peut-être pas bien dans votre organisation, ce serait alors une erreur de les suivre à la lettre. Au final, l'objectif est de s'attacher aux valeurs d'agile et pas à ses techniques. C'est la raison pour laquelle il est nécessaire d'expliquer les principes sous-jacents de l'agilité à toutes les personnes qui souhaitent en appliquer la méthode afin qu'elles puissent s'appuyer dessus.

4. Trop varier les techniques existantes

C'est vrai qu'il faut s'approprier les techniques agiles, mais pas dès le départ. La méthode agile fait souvent référence à ShuHaRi, un modèle japonais qui amène l'utilisateur à acquérir une compétence déterminée en 3 phases :

  1. Au début, il convient de suivre strictement les techniques existantes (Shu).
  2. Une fois que vous avez assimilé ces règles, vous pouvez vous octroyer une certaine flexibilité (Ha).
  3. Jusqu'à ce que vous arriviez au Ri : vous avez alors intégré la compétence inconsciemment et vous n'avez plus besoin de règles ou de techniques.

Souvent, les équipes tentent dès le départ de varier les techniques existantes ou de rassembler différents éléments de plusieurs cadres. Cherry picking. Les excuses les plus récurrentes sont les suivantes : « Je connais la théorie, mais chez nous, ça ne fonctionnera pas » ou « nous aimons expérimenter, donc nous combinons plusieurs techniques ». C'est bien d'expérimenter, mais veillez à avoir une base solide avant de varier les techniques. Respectez une méthode établie pendant six mois ou un an et domestiquez-la. Comment les sprints fonctionnent-ils ? Qu'est-ce qu'un bon rétro ? Comment formulons-nous la valeur client ? Une fois que vous avez une bonne base, vous pouvez varier les techniques.

5. Faire partie d'une équipe agile et d'une équipe de projet

Le fonctionnement agile et le fonctionnement par projet s'appuient sur des principes de base fondamentalement différents. La méthode agile envisage des équipes fixes avec des membres qui fonctionnent et évoluent harmonieusement les uns avec les autres. Le travail se conçoit dans le cadre de l'équipe. Le fonctionnement par projet consiste en un travail qui occupera provisoirement des collaborateurs. L'équipe se conçoit dans le cadre du travail. Ces deux conceptions sont impossibles à concilier.

Un piège dans lequel tombent les organisations est de vouloir maintenir un fonctionnement par projet tout en mettant en place des équipes agiles. On se retrouve alors avec des gens qui travaillent dans une équipe Scrum deux jours par semaine et trois jours dans une équipe de projet, car il s'agit d'un projet tout aussi important. Le résultat implique souvent des équipes insuffisamment construites et des projets non aboutis.

6. Considérer une transformation agile comme un art informatique

Souvent, les personnes ont une conception trop limitée des effets de la méthode agile. Celle-ci ne se limite pas aux équipes informatiques Scrum. Une transformation agile est un changement de culture qui exercera une influence sur tous les processus et sur toutes les personnes de votre organisation, qu'il s'agisse des Finances, des RH ou de la direction. Si les équipes deviennent autonomes, qu'advient-il du rôle des chefs d'équipe ? Comment évaluer les membres des équipes Scrum ? Les budgets annuels et les équipes Scrum sont-ils vraiment conciliables ? Et souvent, au bout d'un moment, d'autres personnes de l'organisation demandent à travailler également selon les principes d'une méthode plus agile.

Plus vite on comprend l'effet d'une transformation agile sur l'entreprise, plus facile sera la transition. De nombreux directeurs voient également dans cette méthode une chance de changer la culture d'entreprise : se montrer, par exemple, plus orientés client ou mettre davantage l'accent sur les particularités des travailleurs. Parfois, les directeurs ont déjà consacré des dépenses à toutes sortes de programmes relatifs à ce changement de culture. Les techniques agiles permettent de réaliser des changements comme la mise en place d'un esprit plus orienté clients ou d'un plus grand sentiment d'appartenance émanant d'une nouvelle méthode de travail.

7. Évoluer trop rapidement

À l'heure actuelle, de nombreuses équipes ont déjà fait l'expérience de la méthode agile. Néanmoins, une fois que le système est en marche, comment étendre la technique à deux ou trois équipes ? Voire vingt équipes ? Et comment introduire la méthode agile dans les départements de vente et des RH ? Le monde agile planche encore sur cette énigme.

Plusieurs cadres envisagent l'évolution des équipes agiles, comme le modèle Spotify, SAFe (Scaling Agile Framework) et LeSS (Large Scale Scrum). La leçon à tirer est la suivante : si vous ne devez pas absolument évoluer, ne le faites pas. Déterminez s'il est possible de faire fonctionner les équipes indépendamment les unes des autres. N'envisagez un cadre d'évolution qu'en dernier recours. Certaines organisations veulent déjà évoluer dès que quelques personnes sont conquises par la nouvelle méthode. Attendez. Ne vous lancez dans cette entreprise que si vous en remarquez la nécessité.

Lire d'autres articles à ce sujet ?

Vous voulez en savoir plus ? Téléchargez notre e-book ! Il s'agit d'un manuel complet qui vous apprend comment travailler de manière plus flexible et fournir des services plus rapidement. Il contient des exemples pratiques, vous indique comment rendre votre gestion des notifications plus agile et bien plus encore.

Téléchargez l'e-book « Agile Service Management »

Comments

Stay Updated on Blog Content

Share this blog:

Want to know what is coming up?

Visit our roadmap!