Agilité et la gestion du changement mboisvert - 15 octobre 2013

L’agilité et la ges,on du changement

Copyright © 2012, Pyxis Technologies inc. Tous droits réservés

Mathieu Boisvert Pyxis Technologies Événement Université de Sherbrooke – Campus Longueuil 15 octobre 2013

Qui je suis et pourquoi ce sujet? •  Expert de méthodes agiles à Pyxis depuis 2004

Différents rôles: Conseiller, formateur, auteur, chargé de cours

•  Une ques,on qui revient de temps à autre

Est-‐ce que tu connais des exemples Agiles qui ne sont pas des projets de développement

logiciel?

Sondage à main levée •  Qui est familier avec la ges,on du changement?

•  Qui connaît peu ou pas Agile?

Les autres, qu’est-‐ce que vous faites ici?

Agenda •  50 minutes – Introduc,on au manifeste à l’Agilité

•  50 minutes – Mener un projet de ges,on du changement avec les méthodes Agiles

•  50 minutes – La ges,on du changement lors d’une transi,on vers l’Agilité

10 minutes de pause entre les sec,ons pour permeZre les déplacements de masse

INTRODUCTION AUX APPROCHES AGILES

Symptômes des projets de développement logiciel

Les sta,s,ques de Garthner: Des solu,ons peu ou pas u,lisées; Une mauvaise qualité de produit:

les anomalies; les régressions; le temps de stabilisa,on;

Le temps trop long entre une idée et sa mise en produc,on; Le dépassement de temps et de budget.

Les individus et leurs interac,ons plus que les processus et les ou,ls

Des soluCons opéra,onnelles plus qu’une documenta,on exhaus,ve

La collabora,on avec les clients plus que la négocia,on contractuelle

L’adapta,on au changement plus que le suivi d’un plan

Le manifeste Agile

Source: hZp://agilemanifesto.org/iso/fr/

Les 12 principes Agiles 1. Notre plus haute priorité est de sa,sfaire le client en livrant rapidement et régulièrement des fonc,onnalités à grande valeur ajoutée.

2. Accueillez posi,vement les changements de besoins, même tard dans le projet. Les processus agiles exploitent le changement pour donner un avantage compé,,f au client.

3. Livrez fréquemment un logiciel opéra,onnel avec des cycles de quelques semaines à quelques mois et une préférence pour les plus courts.

4. Les u,lisateurs ou leurs représentants et les développeurs doivent travailler ensemble quo,diennement tout au long du projet.

5. Réalisez les projets avec des personnes mo,vées. Fournissez-‐leur l’environnement et le sou,en dont ils ont besoin et faites-‐leur confiance pour aZeindre les objec,fs fixés.

6. La méthode la plus simple et la plus efficace pour transmeZre de l’informa,on à l'équipe de développement et à l’intérieur de celle-‐ci est le dialogue en face à face.


7. Un logiciel opéra,onnel est la principale mesure d’avancement.

8. Les processus agiles encouragent un rythme de développement soutenable. Ensemble, les commanditaires, les développeurs et les u,lisateurs devraient être capables de maintenir indéfiniment un rythme constant.

9. Une aZen,on con,nue à l'excellence technique et à une bonne concep,on renforce l’agilité.

10. La simplicité – c’est-‐à-‐dire l’art de minimiser la quan,té de travail inu,le – est essen,elle.

11. Les meilleures architectures, spécifica,ons et concep,ons émergent d'équipes autoorganisées.

12. À intervalles réguliers, l'équipe réfléchit aux moyens de devenir plus efficace, puis règle et modifie son comportement en conséquence.

Les 12 principes agiles (suite)


Pourquoi adopter l’agilité?

•  Sa,sfaire rapidement le client avec des solu,ons logicielles u,les;

•  Augmenter la qualité; •  Augmenter la produc,vité et réduire les coûts; •  Faire face à la complexité; •  Réduire le temps de mise en marché;

–  Réduire les inefficacités; –  Éviter les longues périodes de stabilisa,on en fin de projet;

•  Augmenter la mo,va,on, la collabora,on et l’engagement des individus.

Devenir agile pour suivre le courant, c’est une mauvaise idée!

Limites et défis des approches agiles •  C’est une approche, pas une méthode: demande de changer

le savoir-‐être •  Révèle les inefficacités d’une organisa,on, qui sont parfois

majeures: –  L’exercice du leadership –  La reconnaissance de l’exper,se –  La descrip,on de poste –  La culture d’entreprise –  La rela,on avec le client –  Les processus et procédures de travail

Même combat, peu importe le domaine d’affaires

Limites et défis des approches agiles

•  Intégra,on difficile avec les méthodes tradi,onnelles: –  Pas toujours bien adaptées avec les méthodes de ges,on de projet tradi,onnelles;

–  Source poten,elle de conflit de nature contractuelle; •  Implica,on exigeante pour le client et les équipes de projet;

•  Elles demandent de la rigueur, de la maturité, de la confiance et de la transparence pour réussir.

Lean en quelques mots

Principes

•  Éliminer le gaspillage •  Améliorer la rétroac,on •  Prendre les décisions au

dernier moment responsable

•  La livraison la plus rapide possible

•  La prise de recul et le regard global

Un système de flux Cré

Bonne méthode pour améliorer un processus de travail

Source: hZp://cdi-‐usa.biz/mission-‐directed-‐work-‐teams/5-‐lean-‐workflow/

Lean: le tableau Kanban

Pile de travail

Réalisation Acceptation Déploiement Terminé

D6

D7

D8

D9 D10

D11

D12

1

D3

3

D1 D2

D4

D5

3 1

1

3

Source: Choisir l’Agilité de Mathieu Boisvert et Sylvie Trudel

Scrum en quelques mots

Source: Wikipedia

Bonne méthode pour gérer le développement complexe d’un produit

Sprint review: inspec,on du produit Sprint Retrospec,ve: inspec,on des pra,ques

Sprint ou Itéra,on Product Backlog

ou carnet de produit

Daily Scrum ou

mêlée quo,dienne

Sprint Planning ou

Planifica,on

Product Owner (le client)

Dev Team (l’équipe de travail)

Product Owner (le client)

Dev Team (l’équipe de travail)

Scrum: les rôles Scrum Master

(coach d’équipe)

•  La vision du produit; •  Le carnet de produit •  Évalue le résultat des

itéra,ons •  Communique l’état

d’avancement •  Collaborer avec

l’équipe Scrum •  Collaborer avec les

par,es prenantes

•  Choisit le contenu du Sprint Backlog

•  Auto-‐gérée et auto-‐organisée;

•  Collabore avec le Product Owner;

•  Mul,disciplinaire: Compétences pour livrer un incrément complet.

•  Bonne applica,on du processus

•  S’assurer que l’équipe est fonc,onnelle, produc,ve et améliore sa qualité

•  Protéger l’équipe des interven,ons externes

•  Servant Leader

Agile dans sa forme la plus simple

Terminer ce que l’on commence Inspecter le résultat

Seulement avec une mêlée quo,dienne et une liste de tâches, Bruce Feiler a modifié la rou,ne du ma,n de sa pe,te famille.

Agile en famille

Quelques inspira,ons:

Des ques,ons?

MENER UN PROJET DE GESTION DU CHANGEMENT AVEC LES MÉTHODES AGILES

N’oubliez pas, votre approche peut être très simple

Terminer ce que l’on commence Inspecter le résultat

Comment choisir entre le Scrum et le Lean?

Le choix entre…

Lean: pour améliorer un processus Scrum: pour le développement de produit et/ou gérer la complexité

Wikispeed: hZp://www.youtube.com/watch?v=x8jdx-‐lf2Dw

Source: hZp://www.contrepoints.org/2011/09/04/44030-‐gains-‐de-‐produc,vite/chaine-‐de-‐montage-‐robo,se

•  Améliorer le temps de traitement d’une demande de réclama,on?

•  Construire un programme de ges,on du changement?

•  Construire une maison?

Réponse: Probablement Lean

Réponse: Probablement Scrum

Réponse: Hum, pas facile… regardons ensemble la livraison incrémentale et itéra,ve pour nous aider à répondre.

Lean? Scrum?

ou

Incrément versus Itéra,on

Incrément (porCon complète à chaque fois)

ItéraCon (vérifie fréquemment que l’on approche de la vision)

Scrum propose une approche itéra,ve et incrémentale

Tiré du matériel de forma,on de Pyxis Technologies Basé sur : hZp://www.agileproductdesign.com/blog/dont_know_what_i_want.html

Déroulement du projet

Lean n’impose pas d’approche par,culière

Comment planifier un incrément?

•  Quelle grosseur cons,tuera un incrément suffisant?

•  Combien de points d’inspec,on ceZe grosseur permeZra-‐t-‐elle?

•  En combien de temps est-‐il possible de construire cet incrément?

Mauvais incrément: Le cas de la construc,on d’une maison

Meilleurs exemples de la construc,on incrémentale

hZp://www.fastcodesign.com/1671701/micro-‐apartments-‐give-‐a-‐hint-‐of-‐city-‐livings-‐future

Empire State Building

Pourquoi c’est important de livrer par incrément, périodiquement?

Parce que l’évalua,on de l’incrément est au cœur de la ges,on de projet agile – Ges,on du risque – Ges,on des demandes de changement – Mesurer la progression du projet – Réduit le travail en parallèle (on termine ce que l’on commence)

Que faire si c’est impossible de livrer un incrément en un mois et moins ? •  Ne le faites pas! (avons-‐nous affaire à un processus?)

•  Sachez cependant que plusieurs entreprises en développement logiciel affirmait la même chose et qu’avec l’évolu,on de nos pra,ques, c’est maintenant possible!

•  Exemple de Wikispeed, qui a changé ses pra,ques pour réussir à livrer des pièces en 1 mois.

Comment choisir le contenu de l’incrément?

Les objec,fs La valeur d’affaires Les risques

Capitaliser sur ce qui est prêt

« Ben voyons! Je t’écoute depuis tout à l’heure, ça marche pas ton affaire. » Cas de Louis dont le projet est de répondre à un appel d’offre sur invita,on

Est-‐ce que le projet de Louis peut être fait avec Scrum?

•  Méthode: Scrum •  Valeur d’affaires: les sec,ons sensibles, risquant de causer le refus de la proposi,on

•  Incrément: Sec,on du document •  Itéra,on: 2 semaines •  Organisa,on du travail: une équipe d’architectes et rédacteurs techniques

« As-‐tu un autre exemple? » Cas de Mathieu qui conçoit un cours universitaire à propos des méthodes agiles

Est-‐ce que le projet de Mathieu peut être fait avec Scrum? •  Méthode: Scrum •  Valeur d’affaires: Objec,fs d’appren,ssage aZeints? (concevoir les devoirs en conséquence)

•  Incrément: Un cours de 3 heures (matériel, atelier, exemple, etc.)

•  Itéra,on: 1 semaine •  Organisa,on du travail: les deux chargés de cours

Un projet de ges,on du changement pour un nouveau logiciel de mission

Source: hZp://www.manutri,onniste.com/les-‐etapes-‐de-‐changement/

La valeur d’affaires d’un projet de ges,on du changement?

Les livrables (Incrément)

•  Forma,on •  Aide en ligne •  Aide à la tâche •  Capsules vidéo •  Documenta,on / références •  Bulle,n de nouvelles •  […]

Incidences (Valeur d’affaires)

•  Factura,on •  Inscrire un bâ,ment •  Planifier un projet •  Consulter un rapport •  Évaluer un projet de

rénova,on •  […]

Le meilleur programme de ges,on du changement dans les ressources disponibles 1.  Choisir une méthode de travail:

Scrum 2.  Iden,fier la valeur d’affaires:

les incidences 3.  Planifier un incrément:

aide à la tâche, module de forma,on 4.  Vérifier les résultats:

est-‐ce que les employés ont compris? 5.  Recommencer:

corriger et/ou poursuivre le programme?

Dernier point important: l’améliora,on con,nue des pra,ques •  Principe #9

Une aZen,on con,nue à l'excellence technique et à la qualité de la concep,on.

•  Principe #10

La simplicité et l'art de minimiser les tâches parasites, sont appliqués comme principes essen,els.

•  Principe #12 À intervalles réguliers, l'équipe réfléchit aux moyens de devenir plus efficace, puis règle et modifie son comportement en conséquence.

extremeProgramming: une inspira,on!

Quelques inspira,ons: •  La famille agile de Bruce Feiler:

hZp://www.youtube.com/watch?v=J6oMG7u9HGE

•  La voiture Scrum de Joe JusCce (Wikispeed): hZp://www.youtube.com/watch?v=x8jdx-‐lf2Dw

•  Mon expérience de chargé de cours: hZp://pyxis-‐tech.com/blog/2013/02/14/revela,on-‐dun-‐jeune-‐charge-‐de-‐cours/

Des ques,ons?

LA STRUCTURE ORGANISATIONNELLE

La ges,on du changement lors d’une transi,on vers l’Agilité

•  Requiert au préalable un consensus sur les raisons ayant introduit l’agilité;

•  Il est important que tous ceux ayant un rôle à jouer dans le sou,en de ceZe ini,a,ve en deviennent les promoteurs: le seul financement de la transi,on est insuffisant;

•  L’agilité est une philosophie de travail: il est possible que l’organisa,on doive : –  réunir certaines condi,ons gagnantes; –  accepter de se faire bousculer; –  être récep,ve aux raisons et aux objec,fs du manifeste, aux méthodes et

aux pra,ques agiles.

L’agilité comme élément de la stratégie d’entreprise

Les dirigeants peuvent craindre de perdre leurs acquis : contrôle, pouvoir et avantages liés à leur ,tre:

« Avec l’agilité, je vais perdre le contrôle puisque les équipes seront autogérées ! »

« Mais comment va-‐t-‐on y arriver ? Nous manquons déjà de temps pour tout faire… »

« Mais pourquoi l’agilité ? Le statu quo n’est pas si mal que ça… »

« Ah mais c’est que j’ai des intérêts personnels et

l’agilité ne me sert absolument pas ! »

« Là, on me demande de faire appliquer une nouvelle méthodologie à mes équipes et personne ne m’a

impliqué dans la décision. »

An,ciper les objec,ons

Compréhension commune

À quoi s’aZendre : •  Un processus empirique •  Un carnet de commande priorisé •  La livraison d’incréments de produits terminés •  Une équipe auto-‐organisée

Les appréhensions/interpréta,ons fréquentes : •  L’abandon de la ges,on de projet •  La fin de la documenta,on •  L’anarchie des équipes •  Une excuse pour le laxisme •  La solu,on à tous les problèmes

Bien qu’elles soient dites légères, les méthodes agiles requièrent de la rigueur et de la discipline.

L’imputabilité

Direc,on Affaires

• soutenir les ini,a,ves du responsable de produit ; • éliminer les obstacles rencontrés par les équipes ; • orchestrer les ac,vités autour de la livraison : déploiement, forma,on, marke,ng, etc. ;

• assurer le succès de chacun des projets d’affaires impliquant du développement logiciel.

Direc,on des TI

• qualité des logiciels livrés ; • améliora,on con,nue des processus, méthodes et ou,ls de développement sur les axes de coûts, de délais et de qualité ;

• améliora,on de la cohésion des équipes ; • montée en compétence des membres d’équipes ; • accompagnement des affaires dans la ges,on de produit logiciel.

Structure d'équipe Agile

du Scrum Master ,

Des Équipiers, Du Responsable de produit,

de l’ensemble des individus ayant les compétences pour produire un

incrément de produit.

L’équipe Scrum se compose…

Les collaborateurs et les contributeurs sou,ennent l’équipe

Ges,onnaires Clients

Experts

Et moi ?

Source: Rôle de l’architecte agile, présenté par Jean-‐René Rousseau et Mathieu Boisvert, Pyxis

Le client

Choisir le bon candidat: •  Est-‐il disponible? •  Est-‐il crédible? •  Connaît-‐il la vision du produit?

•  Est-‐ce un bon communicateur?

Probable que le candidat doive apprendre le mé,er de Product Owner

Les spécialistes: Être ou ne pas être dans l’équipe ?

•  Être dans l’équipe est sans doute la meilleure posture pour accomplir vos objec,fs

•  Mais… Aurez-‐vous la disponibilité nécessaire? – Plus souvent qu’autrement, les spécialistes se posi,onnent comme un collaborateur

•  Vous avez donc un défi supplémentaire – Ne pas être un goulot!

Rôle de l’architecte agile, présenté par Jean-René Rousseau et Mathieu Boisvert, Pyxis

Le défi du collaborateur •  Il faut à tout prix éviter les situa,ons suivantes: – L’équipe abend après une décision – L’équipe se fait systéma,quement reprendre ses ini,a,ves et perd ainsi confiance

– L’équipe n’a pas accès à l’informaCon qui lui permeZrait de décider

– Bref… l’équipe a constamment besoin de son architecte… qui n’est pas toujours disponible!

Les ges,onnaires Répercussions sur le rôle de la direc,on / vice-‐présidence

•  Définir les objec,fs de leurs équipes ou leurs départements au lieu de meZre l’accent sur leurs tâches;

•  Prioriser les objec,fs au lieu de prioriser les ac,vités;

•  Suivre la progression vers l’aZeinte de ces objec,fs;

•  Con,nuer de protéger les ressources des équipes afin d’augmenter leur cohésion et, par conséquent, leur performance;

•  Soutenir les employés dans leur développement de carrière;

•  Construire et entretenir des rela,ons avec les autres départements et équipes.

Impacts sur la structure organisa,on Exemple de matrice RACI dans un contexte non agile.

Exemple de matrice RACI dans un contexte agile.

1. Imposer (Tell) Imposer une décision à l’équipe

2. Vendre (Sell) Décider et convaincre l’équipe

3. Consulter (Consult) Consulter l’équipe avant de décider

4. Collaborer (Agree) Décider en collabora,on avec l’équipe

5. Aviser (Advise) Influencer la décision prise par l’équipe

6. Demander (Inquire) S’informer d’une décision prise par l’équipe

7. Déléguer (Delegate) Laisser l’équipe prendre ses propres décisions

Tiré du matériel de forma,on de Pyxis Technologies Source : Jurgen Appelo, Management 3.0 – leading agile developers, developing agile leaders

Leadership situa,onnel

LA CULTURE


Selon vous, quelles sont les causes principales

d’échecs des projets agiles?

Percep,on des causes principales d’échecs des projets agiles.

La culture est impliquée dans au moins 19% des cas, soit la « culture organisa,onnelle à l’encontre des valeurs et principes agiles » (11%) et le « manque de transi,on culturelle » (8%).

Source: VersionOne, State of Agile Survey 2010. Données recueillies auprès de 4 770 par,cipants dans 91 pays, entre le 11 août et le 31 octobre 2010.

Types de cultures

Tiré de l’ouvrage The Reengineering Alterna,ve de William E. Schneider

Caractéris,ques des cultures

Caractéris,que des cultures Caractéris,ques des cultures

La culture de préférence de l’agilité

Sondage mené auprès d’environ 120 personnes qui appliquent l’agilité et provenant de cultures différentes, par Michael Spayd, en mai 2010

Prédisposi,ons et indisposi,ons

Collabora'on •  prédisposé au travail d’équipe •  de bons généralistes s’aZribuant la prochaine tâche d’équipe à pied levé •  individus veulent tout décider par consensus •  s’embourbent dans des réunions où tous doivent être présents •  cherchent l’avis de tous et de chacun avant de prendre une décision Accomplissement •  la croissance concerne à la fois les individus et les équipes •  les inspec,ons et les rétrospec,ves sont menées avec un souci d’apprendre, de ,rer

des leçons et de s’améliorer •  manque de canalisa,on envers les résultats •  nouvelles idées provoquent de l’éparpillement •  manque de rigueur

Prédisposi,ons et indisposi,ons Compétence •  font preuve de rigueur et de discipline à propos de la collecte, l’analyse et la

présenta,on des données d’avancement ainsi que du calcul de l’effort restant et de la vélocité

•  cul,ve les secrets, et la poli,que finit par prendre le dessus sur l’efficacité •  transparence est permise seulement lorsque que les résultats plaisent •  le concept d’équipe auto-‐organisée passe mal

Contrôle •  propension à livrer des produits de qualité supérieure à ceux de la compé,,on

demande la contribu,on d’individus spécialisés, ayant de très grandes compétences techniques

•  réduit la possibilité de prendre des engagements collec,fs •  l’engagement d’équipe est absent ou chao,que

Prédisposi,ons et indisposi,ons

LE PLAN DE TRANSITION


•  Un sen,ment d’urgence La situa,on actuelle est intolérable et il est impéra,f de changer rapidement. La souffrance étant grande, l’organisa,on devient prête à essayer n’importe quelle alterna,ve pour changer sa situa,on.

•  Un facteur volontaire posi,f L’organisa,on a eu quelques résultats mi,gés et les équipes de développement désirent améliorer la situa,on, bien que la souffrance soit faible.

•  Un facteur néga,f ou involontaire La haute direc,on impose un changement n’étant pas perçu comme nécessaire. Cela crée un inconfort et une souffrance, comme si soudainement une solu,on se cherchait un problème.

Ges,on de la transi,on agile

La ges,on du changement

Évaluer les impacts d’une transi,on agile en tenant compte de la culture, de la structure de gouvernance, des projets en cours et à venir et des technologies u,lisées. Adopter une stratégie de transiCon agile tenant compte de la culture, des risques et des impacts sur l’organisa,on. Planifier et faire le suivi du projet de transi,on agile qui doit être traité comme un projet organisa,onnel. Choisir les méthodes agiles qui conviennent aux besoins et au contexte organisa,onnel. Adapter les processus ou définir un cadre méthodologique dans lequel les méthodes agiles choisies sont mises en œuvre avec des principes directeurs. Se doter d’ouCls adéquats pour opéra,onnaliser les processus et donner de la visibilité à tous. Former et accompagner les ges,onnaires, les membres d’équipes et les clients impliqués dans les projets de développement. Évaluer l’applicaCon des praCques agiles à intervalles réguliers pour s’assurer que l’organisa,on ob,endra le rendement escompté et appliquer les adapta,ons requises pour y arriver.

Ges,on des risques de l’adop,on

•  Par les ges'onnaires l’adop,on de l’agilité provient d’un ges,onnaire important qui sait communiquer et partager sa vision de l’agilité.

•  Par les équipes (par le bas) des équipes de développement logiciel qui sont à l’origine de la mise en œuvre des pra,ques agiles

•  En sandwich combinaison des approches « par les ges,onnaires » et « par les équipes »

•  Progressiste commencer avec un projet et contaminer de plus en plus de projets

•  Big Bang tabula rasa sur les méthodologies qui existent et tout démarrer ou redémarrer en mode agile

Stratégie de mise en œuvre

Des ques,ons?

Business

Agilité et la gestion du changement mboisvert - 15 octobre 2013