par Jean-René Rousseau Huit façons de rater votre implantation des méthodes Agiles

Qui suis-je? Jean-René Rousseau [email_address] Conseiller et c oach Agile à Pyxis Technologies www.pyxis-tech.com

Jean-René Rousseau [email_address]

Conseiller et c oach Agile à Pyxis Technologies www.pyxis-tech.com

1945 à 1965 – Les débuts 1965 à 1985 – La crise Années 80 et 90 – On veut passer de l’artisanat à l’ingénierie logicielle, on cherche le silver bullet Fin des années 90 – On voit apparaître des méthodes dites « légères » Septembre 2000 – Pyxis est née Février 2001 – Le manifeste Agile Septembre 2002 – Le groupe d’utilisateurs Agile de Montréal est créé Fin 2003 – Pas facile … 2006 – On s’intéresse de plus en plus à l’Agilité 2007 – Le nombre de participants à la conférence Agile double pour une troisième année consécutive 2008 – On en est où? Un peu d’histoire

1945 à 1965 – Les débuts

1965 à 1985 – La crise

Années 80 et 90 – On veut passer de l’artisanat à l’ingénierie logicielle, on cherche le silver bullet

Fin des années 90 – On voit apparaître des méthodes dites « légères »

Septembre 2000 – Pyxis est née

Février 2001 – Le manifeste Agile

Septembre 2002 – Le groupe d’utilisateurs Agile de Montréal est créé

Fin 2003 – Pas facile

…

2006 – On s’intéresse de plus en plus à l’Agilité

2007 – Le nombre de participants à la conférence Agile double pour une troisième année consécutive

2008 – On en est où?

État de la situation 69 % des organisations disent utiliser au moins une pratique « Agile » http://www.ambysoft.com/surveys Agile 2008 à Toronto 1500 participants Les sujets se distinguent par leur « maturité » Surestime-t-on notre niveau d’Agilité? Les projets Agiles livrent-ils les résultats attendus?

69 % des organisations disent utiliser au moins une pratique « Agile » http://www.ambysoft.com/surveys

Agile 2008 à Toronto

1500 participants

Les sujets se distinguent par leur « maturité »

Surestime-t-on notre niveau d’Agilité?

Les projets Agiles livrent-ils les résultats attendus?

1. Faire de l’Agile pour être « dans le vent » On oublie de s’aligner sur des objectifs d’affaires Augmenter la fréquence des livraisons Augmenter la qualité et la satisfaction des utilisateurs Augmenter la productivité des équipes Fournir un environnement de travail motivant et stimulant On a besoin d’un haut niveau d’engagement de la part de la haute direction Parrainer l’effort de transition Fournir les ressources nécessaires Ajuster les paramètres du succès

On oublie de s’aligner sur des objectifs d’affaires

Augmenter la fréquence des livraisons

Augmenter la qualité et la satisfaction des utilisateurs

Augmenter la productivité des équipes

Fournir un environnement de travail motivant et stimulant

On a besoin d’un haut niveau d’engagement de la part de la haute direction

Parrainer l’effort de transition

Fournir les ressources nécessaires

Ajuster les paramètres du succès

2. Sous-estimer les impacts de la transition Impacts sur les individus Nouveaux rôles, nouvelles tâches Pertes de pouvoir Compétences Mentalité, façons de penser, valeurs, attitudes Motivations et engagements Impacts organisationnels Structure organisationnelle Système de rémunération Pilotage des projets Relation avec les clients et les fournisseurs Configuration des locaux

Impacts sur les individus

Nouveaux rôles, nouvelles tâches

Pertes de pouvoir

Compétences

Mentalité, façons de penser, valeurs, attitudes

Motivations et engagements

Impacts organisationnels

Structure organisationnelle

Système de rémunération

Pilotage des projets

Relation avec les clients et les fournisseurs

Configuration des locaux

3. Manquer de leadership d’affaires Le rôle du responsable de produit ( product owner ) n’est pas pris au sérieux Manque de disponibilité Manque de ownership dans la gestion du carnet du produit Manque de pouvoir décisionnel Manque de connaissance de la valeur d’affaires Manque d’imputabilité Le carnet du produit n’est pas « propre » On n’effectue pas une maintenance régulière du carnet Les scénarios utilisateurs ne sont pas de la bonne granularité On n’ajuste pas la façon de documenter les exigences

Le rôle du responsable de produit ( product owner ) n’est pas pris au sérieux

Manque de disponibilité

Manque de ownership dans la gestion du carnet du produit

Manque de pouvoir décisionnel

Manque de connaissance de la valeur d’affaires

Manque d’imputabilité

Le carnet du produit n’est pas « propre »

On n’effectue pas une maintenance régulière du carnet

Les scénarios utilisateurs ne sont pas de la bonne granularité

On n’ajuste pas la façon de documenter les exigences

4. Ne pas produire des incréments terminés Le logiciel produit itérativement n’est pas potentiellement livrable Quel est votre définition de ‘terminé’? Accumulation d’une dette N’est pas mesurée Nuit à la prévisibilité Réduit la vélocité Pratiques d’ingénierie Agiles déficientes Tests automatisés Remaniement du code ( refactoring ) Intégration continue

Le logiciel produit itérativement n’est pas potentiellement livrable

Quel est votre définition de ‘terminé’?

Accumulation d’une dette

N’est pas mesurée

Nuit à la prévisibilité

Réduit la vélocité

Pratiques d’ingénierie Agiles déficientes

Tests automatisés

Remaniement du code ( refactoring )

Intégration continue

5. Oublier de s’améliorer Le développement Agile repose sur un modèle empirique compris de boucles d’inspection et d’adaptation À quand remontre votre dernière rétrospective? Une rétrospective doit être tenue à chaque itération Chaque rétrospective doit converger vers un plan d’amélioration concret Il faut diffuser les apprentissages Bon est l’ennemi d’excellent !

Le développement Agile repose sur un modèle empirique compris de boucles d’inspection et d’adaptation

À quand remontre votre dernière rétrospective?

Une rétrospective doit être tenue à chaque itération

Chaque rétrospective doit converger vers un plan d’amélioration concret

Il faut diffuser les apprentissages

Bon est l’ennemi d’excellent !

6. Avoir une équipe désengagée Se dire « Moi, j’ai terminé! » Créer des listes de tâches personnelles Créer des équipes non multidisciplinaires Disperser les membres de l’équipe N’avoir aucun engagement après la rencontre de planification Avoir un modèle de rémunération axé sur les performances individuelles

Se dire « Moi, j’ai terminé! »

Créer des listes de tâches personnelles

Créer des équipes non multidisciplinaires

Disperser les membres de l’équipe

N’avoir aucun engagement après la rencontre de planification

Avoir un modèle de rémunération axé sur les performances individuelles

7. Utiliser un style de gestion autoritaire Le passage de gestionnaire de projet classique à ScrumMaster est difficile Ce n’est pas une position de pouvoir On ne peut plus assigner les tâches aux gens Il faut faire confiance à l’équipe et éviter de faire de la « microgestion » Il faut quand même avoir du leadership L’équipe doit pouvoir prendre ses propres décisions Il faut savoir déléguer au plus bas niveau possible

Le passage de gestionnaire de projet classique à ScrumMaster est difficile

Ce n’est pas une position de pouvoir

On ne peut plus assigner les tâches aux gens

Il faut faire confiance à l’équipe et éviter de faire de la « microgestion »

Il faut quand même avoir du leadership

L’équipe doit pouvoir prendre ses propres décisions

Il faut savoir déléguer au plus bas niveau possible

8. Faire une mauvaise adaptation du processus Adapter une méthode Agile avant de l’utiliser selon les règles Mauvaise connaissance des principes lorsqu’on adapte une pratique Personne ne porte le chapeau de « coach Agile » Faire du déni relativement aux obstacles rendus visibles « Ça ne peut pas fonctionner chez nous » Blâmer l’approche Agile utilisée lorsqu’on rencontre des obstacles On masque les problèmes en adaptant le processus

Adapter une méthode Agile avant de l’utiliser selon les règles

Mauvaise connaissance des principes lorsqu’on adapte une pratique

Personne ne porte le chapeau de « coach Agile »

Faire du déni relativement aux obstacles rendus visibles

« Ça ne peut pas fonctionner chez nous »

Blâmer l’approche Agile utilisée lorsqu’on rencontre des obstacles

On masque les problèmes en adaptant le processus

En conclusion… Chaque mise en œuvre d’un processus Agile est unique et adaptée , avec des particularités qui répondent à la réalité et au fonctionnement de l’organisation cible Le développement Agile c’est simple mais difficile Il s’agit d’un processus d’amélioration continue Il faut savoir apprécier la résistance Il faut faire preuve de transparence

Chaque mise en œuvre d’un processus Agile est unique et adaptée , avec des particularités qui répondent à la réalité et au fonctionnement de l’organisation cible

Le développement Agile c’est simple mais difficile

Il s’agit d’un processus d’amélioration continue

Il faut savoir apprécier la résistance

Il faut faire preuve de transparence

Pas si simple, le changement Mode descendant La haute direction partagent une vision quand à l’utilisation de Scrum Mode ascendant Quelques équipes commencent à utiliser Scrum. Les gens voient les avantages de cette nouvelle approche et décident de l’adopter Pour assurer le succès, il faut que le changement soit introduit à la fois de bas en haut et de haut en bas , simultanément

Mode descendant

La haute direction partagent une vision quand à l’utilisation de Scrum

Mode ascendant

Quelques équipes commencent à utiliser Scrum. Les gens voient les avantages de cette nouvelle approche et décident de l’adopter

Pour assurer le succès, il faut que le changement soit introduit à la fois de bas en haut et de haut en bas , simultanément

Transition – Feuille de route

Questions?