Post on 27-Dec-2014
description
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.
Source: hZp://agilemanifesto.org/iso/fr/
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)
Source: hZp://agilemanifesto.org/iso/fr/
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
La ges,on du changement lors d’une transi,on vers l’Agilité
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
La ges,on du changement lors d’une transi,on vers l’Agilité
• 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?