Avant d’aborder le sujet des transformation Agile, faisons un rapide rappel historique des transformations dans l’IT

Il faut attendre les années 1980 pour que l’industrie informatique connaisse les premiers déploiements de processus, avec des démarches basées sur l’ISO 9001 ou le CMM. Le postulat est alors que la mise en place de processus efficaces résultera nécessairement en la livraison de produits de qualité, tout en tenant délais et budgets.

Les années 2000 voient alors l’arrivée des méthodes et principes Agile, notamment avec la publication du manifeste Agile en 2001 : Si les processus sont nécessaires, ils seront vains sans prendre en compte la dimension humaine des équipes de développement. Il apparait alors nécessaire de motiver et responsabiliser les équipes afin que celles-ci délivrent des produits de qualité.

L’Agilité est orientée utilisateur. Vu de l’utilisateur, l’important est le produit livré, et non pas la manière dont le projet a été mené. Les organisations IT, orientées projets, se transforment donc en organisations orientées produits : les Chefs de Projets font place à des « Product Owners », les plans projet à des Product Backlog.

Quelques conditions pour une transformation Agile réussie

La première condition est d’avoir un objectif de transformation précis, partagé et orienté business, supporté par un sponsor fort : Pour quelles raisons l’organisation doit-elle évoluer ?

Donnons un exemple : vouloir développer un produit modulaire afin d’être en capacité de répondre plus rapidement aux besoins des clients. L’objectif est alors précis, concret, vérifiable et orienté clients. A contrario avoir comme objectifs de se transformer pour supprimer les silos dans l’entreprise ou améliorer la satisfaction des employés est certes louable, mais vagues et peu tourné vers les utilisateurs. Quel sponsor investirai durablement pour une démarche non liée au business de l’entreprise ?

La deuxième condition a été formalisée par Kotter : il faut un sentiment d’urgence : Sans urgence, il y aura toujours quelque-chose de plus prioritaire à faire ! Il ne s’agit pas la de l’urgence réelle, mais de l’urgence ressentie par les membres de l’organisation.

Il faut ensuite reconnaitre l’importance des différents axes de la transformation Agile :

  1. L’axe organisationnel : Agile nécessite une transformation des organisations au niveau équipe, par exemple avec Scrum, et au niveau organisation, avec la mise en place de frameworks comme SAFe ou LeSS. Sans changement d’organisation, pas de transformation Agile.
  2. L’axe humain : Agile nécessite un changement des valeurs et des comportements à tous les niveaux de l’organisation : mise en place d’un management plus bottom-up, responsabilisation et confiance dans les équipes, transparence, décentralisation des décisions. Sans changement de valeurs, pas de transformation réelle des comportements, et pas de transformation Agile.
  3. L’axe technique : pour livrer fréquemment, il est nécessaire de mettre en place de nouvelles méthodes de développement, comme l’intégration continue et les tests automatiques. Pour cela, il est nécessaire de « refactorer » les produits pour les rendre plus modulaire et testables, d’en revoir l’architecture. Sans transformation des méthodes de développement et de l’architecture des produits, pas de transformation Agile.

Comment s’assurer que la transformation Agile progresse ?

Un premier signe est d’observer que l’organisation IT orientée projet disparait au profit d’une organisation orientée produit : Les équipes projet se restructurent autours de composants pour former des « component teams », ou de fonctionnalités utilisateurs pour former des « feature teams ». Les budgets ne sont plus gérés par projet mais par produit.

Dans le même temps, les anciens rôles associés aux projets (Program Managers, Project Managers) font place à des rôles associés aux produits (Business Owners, Product Managers, …). Il ne s’agit pas uniquement d’un changement de nom, mais d’un changement de rôle, cette évolution s’accompagne d’une montée en compétence autours de la gestion de produit.

Les méthodes de développement, historiquement souvent définies par des équipes transverses sont prises en charge par des membres des équipes concernées, organisées en communautés. Le rôle des équipes transverses est alors de faciliter et s’assurer que les décisions prises sont alignées avec les objectifs de l’entreprise.

Enfin, une transformation Agile n’est jamais confortable : Managers et membres d’équipes doivent faire évoluer leurs valeurs, comportements. Une transformation facile est le signe d’une transformation de façade ou qui ne progresse pas.

Conclusion

Les transformations Agile s’accompagnent d’une revalorisation du rôle de développeur, pris au sens large, incluant les activités de conception et de test. Elle favorise également l’émergence de leaders, c’est-à-dire de personnes indiquant la direction à prendre et entrainant les équipes vers cette cible. Des leaders apparaissent à tous les niveaux de l’organisation : développement, architecture, management.

Enfin, une transformation Agile prend du temps, la mise en place de frameworks type Scrum ou SAFe n’est que la face immergée de l’iceberg. L’évolution des comportements des équipes et managers, de même que la mise en place de nouvelles techniques de développement ne se fait pas en quelques mois.

 

Comments are closed.