Bienvenue sur Développement Agile

Référence sur le développement logiciel Agile. Nous traitons de conception, de programmation, de pratiques de génie logiciel, d'essais et d'autres sujets connexes.

Les 8 étapes du changement de Kotter et l'Agilité

Publié par Philippe Tremblay le lundi 26 septembre 2011 à 00:00

Séparés à la naissance?

Introduire l'agilité dans un contexte de petite envergure (petite organisation ou petite équipe) est souvent plus réussi que celle tentée dans une organisation de grande envergure.

Une des raisons de cette difficulté pour les grandes organisations d'introduire l'agilité, est la gestion du changement. De nombreuses méthodes décrites dans d'aussi nombreux livres suggèrent des pistes pour mieux réussir les changements organisationnels. Un de ceux-ci est particulièrement intrigant à mes yeux et c'est celui du livre « Leading change » de John Kotter (http://www.amazon.com/Leading-Change-John-P-Kotter/dp/0875847471).

Pourquoi cette méthode est-t-elle intrigante pensez-vous? Regardez tout d'abord les 8 étapes du changement décrites dans ce livre :

  1. Créer le sentiment d'urgence
  2. Former une coalition puissante
  3. Créer la vision du changement
  4. Communiquer la vision
  5. Supprimer les obstacles
  6. Créer des victoires à court terme
  7. Bâtir sur le changement
  8. Ancrer les changements dans la culture corporative

Alors, voyez-vous l'analogie, les similitudes entre ces étapes et certains principes ou pratiques de l'Agilité? Pour ma part, j'y vois les correspondances suivantes avec Scrum :

8 étapes du changement organisationnel

Principes / Pratiques Agile

Créer le sentiment d'urgence

  • Développement itératif
  • Carnet de produit priorisé
  • Rétroaction rapide

Former une coalition puissante

  • Équipe multidisciplinaire, autonome
  • Propriétaire du produit (Product owner)
  • ScrumMaster

Créer la vision du changement

  • Carnet de produit

Communiquer la vision

  • Planification du sprint
  • Carnet de sprint
  • Carnet de produit
  • Mêlée quotidienne (Daily Scrum Meeting)

Supprimer les obstacles

  • Équipe autonome et responsable
  • ScrumMaster
  • Rétrospective

Créer des victoires à court terme

  • Développement itératif, incrémental
  • Retour sur l'investissement rapide

Bâtir sur le changement

  • Inspect and Adapt
  • Rétrospective

Ancrer les changements dans la culture corporative

  • Visibilité des progrès réel (succès)
  • Flot continu et soutenu du travail

Bien qu'il soit fort possible que vous divergiez d'opinion en ce qui concerne la correspondance spécifique des étapes avec les principes agiles, il ne fait probablement aucun doute pour vous, comme pour moi, que ces 8 étapes et les principes Agile proviennent de la même nécessité…la survie (http://en.wikipedia.org/wiki/Evolution).

À vrai dire, la constatation qu'une méthodologie de changements organisationnels ait des liens philosophiques avec l'Agilité ne devrait pas être si surprenante. Après tout, un des grands principes de l'Agilité est l'accueil à bras ouvert du changement. Considérer le changement comme un comportement attendu au lieu d'une exception!

Références :

  1. Kotter's 8-Step Change Model / Implementing change powerfully and successfully (http://www.mindtools.com/pages/article/newPPM_82.htm)

Par où commencer avec l'Agilité?

Publié par Louis-Philippe Carignan le dimanche 2 août 2009 à 02:39

C'est une bonne question et, à mon avis, la réponse dépend de vos besoins. Est-ce que vous cherchez à améliorer votre qualité logiciel? Est-ce que vous cherchez à améliorer votre temps de livraison? Cherchez-vous à motiver votre équipe? Est-ce que vous aimeriez adopter une mentalité d'amélioration continue? Bref, qu'est-ce qui vous pousse à regarder vers les méthodologies Agile?

Par exemple

Disons que votre principal problème est la qualité du logiciel livré au client. De nombreux bogues surviennent chez le client. On répare ces bogues et de nouveaux bogues apparaissent en même temps puisque de nouvelles fonctionnalités sont ajoutées au logiciel. Même si vous mettez en pratique une approche traditionnelle (revue de code, phase de tests exhaustive), votre nombre de bogues rapportés par le client reste le même. Comment s'en sortir? Comment l'Agilité peut-elle m'aider à régler mon problème?

Premièrement

Premièrement, je suggérerais de mesurer votre problème. Dans notre exemple, combien de bogues avez-vous dans votre logiciel? Ou plus précisément, combien de bogues sont rapportés par votre client? Est-ce vraiment la source de l'insatisfaction de votre client? Ou est-il mécontent des interfaces graphiques qui sont peu conviviales? Bref, mettre des valeurs numériques à votre problème est un bon point de départ. En plus de mesurer votre problème, vous donner un objectif pour l'équipe (réduire le nombre de bogues). Aussi, vous informez vos supérieurs que le nombre de bogues peut limiter les profits puisqu'il cause de l'insatisfaction chez le client.

Deuxièmement

Toujours dans l'exemple des bogues, comment les méthodologies Agile peuvent-elles m'aider avec mon problème? Un bon point de départ est les tests unitaires couplés avec l'intégration continue. Selon mon expérience, cette combinaison peut diminuer le nombre de bogues envoyés au client. Remarquer que vous continuerez à écrire des bogues dans le logiciel. Cependant, l'intégration continue attrapera les bogues avant qu'ils soient livrés au client. Vous pourrez alors les réparer avant la livraison. De nombreuses études démontrent qu'un bogue réparé avant la livraison coûte jusqu'à 4 fois moins cher qu'un bogue livré au client.

Facile mais..

Facile à dire mais difficile à faire. Je suis très d'accord avec vous. L'idée semble noble mais nous avons tous des horaires surchargés. Comment mettre du temps sur ces concepts lorsque votre est chargée. De plus, vous avez sûrement des ressources qui seront réticentes au changement. Alors comment s'y prendre? À mon avis, démarrer avec un projet pilote pour prouver votre point. Avez-vous un projet personnalisé qui démarre pour 6 mois? Si oui, regardez comment l'intégration continue et les tests unitaires peuvent y être intégrés. Je placerais aussi des gens ouverts au changement et prêt à essayer de nouvelles méthodes de faire dans ce projet. J'accompagnerais cette équipe en les encourageant que leurs efforts auront un impact sur le reste de l'entreprise. Donnez leur votre appui et support moral. Dès que le projet pilote se met en branle, gérer le changement. Assurez-vous que l'expérience est positive, même si les résultats seront négatifs.

Quality is free

La phrase peut sembler loufoque. Je crois que la qualité est gratuite puisque le temps passé à bâtir un système de qualité (intégration continue, tests unitaires) n'est pas repris avant la livraison lors d'une séance de tests. Je crois que la phrase suivante du livre Peopleware résume bien le thème sur la qualité.

The trade-off between price and quality does not exist

in Japan. Rather, the idea that high quality brings on

cost reduction is widely accepted.

On revient à notre problème

Par où comment-on avec l'Agilité? Je crois que cela dépend de votre problème. Dans cet article, je souligne l'importance de pratiques d'ingénierie telles que l'intégration continue et les tests unitaires. Ces pratiques proviennent des méthodologies Agile et peuvent vous aider à résoudre votre problème de qualité. Cependant, si vous problème est plutôt vers le manque de communication, Scrum est une méthodologie plus appropriée pour vous. Hélas, on en reparlera dans un autre article sur ce blogue.

Archive