Matinée PMI : L’Agilité pour gérer la complexité en TI

43
1 L’agilité pour gérer la complexité en TI La complexité et évolution de l’agilité L’agile à grande échelle, un exemple d’implémentation SAFe Etienne Laverdière, PMP, SPC, CSP Coach Agile, Digital Tango Ltée

Transcript of Matinée PMI : L’Agilité pour gérer la complexité en TI

1

L’agilité pour gérer la complexité en TI La complexité et évolution de l’agilité

L’agile à grande échelle, un exemple d’implémentation SAFe

Etienne Laverdière, PMP, SPC, CSP

Coach Agile, Digital Tango Ltée

Coach agile (2013 --) – ING Banque (Paris) – Banque Populaire (Nantes, Paris) – Intact Assurance (Mtl, Tor)

Chef de projet agile (2009 - 2012) – Banque Nationale (Montréal) – SFR (Paris)

Team lead, développement, architecture logicielle (1998 - 2008) – Société Générale (Paris) – Valeurs Mobilières Desjardins – Compuware – BCE Emergis – Bell Actimedia

2

ETIENNE LAVERDIÈRE PMP, PMI-ACP, SPC CSM, CSP, ICP-ACC, ICP-ATF @elaverdi Digital Tango ltée www.digitaltango.ca [email protected]

2

Votre partenaire agile

La complexité en TI

Mon intérêt pour le thème de la complexité en TI

Notre agenda:

• Un aperçu de la complexité en TI.

• Comment l’agilité « première génération » répond au monde complexe?

• Quels sont les modèles d’agilité à grande échelle? Un comparatif.

• Retour d’expérience sur la mise en place de SAFe (Scaled Agile Framework) dans une institution bancaire en France.

3

[We] identified a new primary challenge: complexity. Today’s complexity is only expected to rise, and more than half of CEOs doubt their ability to manage it.

2010, IBM Capitalizing on Complexity

« L’agilité c’est pour les petits projets, pas pour les gros. »

-- Un directeur

Les résultats

4

Katheen Hass, The Enterprise BA, Adapting BA Practices for Complex Strategic Projects, 2013 The Standish Group « Chaos Report 2015 », XP2002

Impact monétaire

• 1.22 billion $ par année au Etats-Unis

• 500 milliard $ par mois dans le monde

If we could solve the problem of IT failure, the US could increase GDP by USD 1 trillion/yr.

Roger Sessions,

Simple Architectures for Complex Enterprises, 2008

Les raisons principales d’échec des projets TI

5

Les requis changent trop ou deviennent inutiles

• Les techniques pour gérer les requis semblent inefficaces • Pénalités, demandes de changement, contrat, sign-off

• 64% du code dans un logiciel livré est rarement sinon jamais utilisé

Incapacité à maîtriser la complexité des projets

• Les variables projets changent plus rapidement que notre capacité d’adaptation.

“A lot of times, people don’t know what they want until you show it to them.” – Steves Jobs

Robert N. Charette, « Why Software Fails », 2005

Katheen Hass, “The Enterprise BA, Adapting BA Practices for Complex Strategic Projects”, 2013

La complexité

6

Importance stratégique, nombre de parties prenantes

Variabilité et rapidité des

changements

Risques, dépendances et contraintes externes

Niveau de complexité technique

Urgence et manque de flexibilité

Grosseur / Délais /

Coût

Clarté du problème

La complexité en entreprise

7

Katheen Hass, Project Complexity Model, 2013

Boston Consulting Group, Smart Rules: Six Ways to Get People to Solve Problems Without You, 2011

Importance stratégique, nombre de parties prenantes

Variabilité et rapidité des

changements

Risques, dépendances et contraintes externes

Niveau de complexité technique

Urgence et manque de flexibilité

Grosseur / Délais /

Coût

Clarté du problème

La complexité en entreprise

8

Katheen Hass, Project Complexity Model, 2013

Boston Consulting Group, Smart Rules: Six Ways to Get People to Solve Problems Without You, 2011

Augmentation de la « complication » des organisations de +6.7% par année depuis 50 ans

Impacts de la complexité sur les projets Un déficit de connaissance • Quel est l’objectif? On ne sait pas vraiment ce

que le client veut. • Comment l’équipe va réagir avec une nouvelle

condition?

Un déficit d’alignement • Comment aligner les actions d’un groupe de

personnes vers un but commun?

Un déficit de « contrôle sur le résultat » • Comment faire en sorte que les actions

réalisées soient toujours en ligne avec l’objectif?

• Équivalent de « Monitor&Control »

9

Connaissance

Alignement Contrôle

sur le résultat

2010, Steven Bungay, The Art of Action

Complexité & gestion traditionnelle

Pmbok: Planning Analyse (rationnel) Architecture Contrat à prix fixe Pénalités

Connaissance

Alignement Contrôle sur les

résultats

Pmbok: Planning, Execution Planification Détails dans les plans Complication

10

Pmbok: Monitoring&Control Rapports Indicateurs Sign-off, statuts

Complexité & gestion traditionnelle

Pmbok: Planning, Execution Planification Détails dans les plans Complication

Verrouillage Pmbok: Planning

Analyse (rationnel) Architecture Contrat à prix fixe Pénalités

Connaissance

Alignement Contrôle sur les

résultats

11

Pmbok: Monitoring&Control Rapports Indicateurs Sign-off, statuts

Complexité & gestion agile

12

Connaissance

Alignement Contrôle sur les

résultats

Focus sur ce que l’on sait (empirisme) Vision stratégique Sprint review (Démo client) Rétrospective équipe (inspection)

Discipline interne Autonomie, Engagement Collaboration Création et innovation

Adaptation

Impact et but recherchés, Valeur Cadence & Synchronisation, Simplification Principes directeurs Contextualisation de la vision stratégique

① Toutes les équipes doivent exposer leur données et leur

fonctionnalités à travers des interfaces de services. Les équipes doivent communiquer

ensemble à travers ces interfaces.

② Il n’y aura aucune autre forme de communication permise: c’est-à-dire aucune

communication directe, mémoire partagée, ou « back-doors ».

③ Toutes les interfaces de service, sans exception, doivent être conçues intégralement

pour être externalisable. c’est-à-dire que toutes les équipes doivent planifier et

construire leur services dans le but d’exposer leur service au monde externe. Il n’y aura

aucune exception.

④ Il n’y aura aucune consigne au niveau des technologies employées.

⑤ Toute personne ne suivant pas ces principes sera congédiée. Merci, bonne journée!

Principes directeurs d’architecture définis par le CEO de

Amazon Jeff Bezos (2002) :

Un exemple d’alignement: Les principes directeurs

13

Comparatif Projets TI : Cascade et Agile

The Standish Group « Chaos Report 2015 »

14

Impact de l’agilité sur les projets TI

• 3 X plus de projets réussis

• 3 X moins d’échec

Gestion traditionnelle vs agile

15

Katheen Haas, Project Complexity Model, 2013

Méthodologies Traditionnelles Scrum

PM : Focus sur le Project Management; Tâches, Exécution, Dépendances, Plan

Scrum Master : Focus sur la gestion de (la complexité de) l’équipe; Engagement, Prédictibilité, Mastery, Discipline et Autonomie.

BA : Focus sur les requis. Détail, Sign-Off, Validation.

Product Owner : Focus sur la gestion (de la complexité) du produit; Intention, Stratégie, Innovation et Valeur.

Méthodologies Traditionnelles Méthodologies Agiles

Se conformer au plan S’adapter au changement

Prise de décision experte au top Prise de décision au niveau de l’équipe et rapide

Mode prédictif, savoir explicite, rationnel Mode empirique, savoir tacite basé sur l’expérience

La solution est donnée top-down La solution est un phénomène émergent

L’organisation est fixe, comme une machine traitant de l’information

Organisation apprenante, sa structure aussi est émergente

Exécution orientée tâche Exécution orientée « but et valeur »

Livraison lente et unique Livraison rapide et incrémentale

L’agilité d’entreprise

16

Agilité d’entreprise

17

Focus sur les produits complexes

Focus sur les équipes et produits complexes

Agilité d’entreprise, architecture, gestion du portfolio, multi-équipes

Défis de l’agilité d’entreprise

18

Comment ne pas perdre l’agilité des petites équipes dans les grosses structures? Quelle approche d’agilité d’entreprise choisir? Comment transformer l’entreprise en accord avec sa culture ?

Scrum relies on self-commitment, self-organization, and emergence rather than authoritarian measures.

—Ken Schwaber

Quelques raisons pour considérer un modèle d’agilité d’entreprise: • Dépendances et nombre

d’équipes • Architecture couplée • Gestion du portfolio agile • Interface traditionnel –

agile difficile à maintenir • Gestion des parties

prenantes • Sortir du WaterScrumFall • Avoir une roadmap

d’agilité d’entreprise

19

Agile Scaling Knowledge base: http://www.agilescaling.org/ask-matrix.html

SoS 2001

LeSS 2013

Spotify 2012

Nexus 2015

Scrum At Scale 2014

Basse, prescriptif Haute, émergeant

Flexibilité

Co

uve

rtu

re

Équ

ipes

P

rog

ram

mes

Po

rtfo

lio /

En

terp

rise

DAD 2012

SAFe 2012

Faible

Adoption

Haute

Moyenne

Offres d’agilité d’entreprise

Put brutally SAFe seemed to be PRINCE II camouflaged in Agile language. SCRUM as an approach was emasculated in a small box to the bottom right of a hugely overcomplicated linear model. (…) SAFe is not only a betrayal of the promise offered by AGILE but is a massive retrograde step giving the managerial class an excuse to avoid any significant change. [A Body of knowledge] is an highly static non-adaptive approach.

Dave Snowden (Cynefin)

SAFe

20

I saw a Release Planning session with 20­some teams and almost 200 people, and realized how SAFe is Scrum, just expanded to the program level. I became aware that Scrum itself scales beautifully.

Lyssa Adkins (Coaching Agile Teams) SAFe gives us some good ideas for how to deal with [enterprise] complexities where few existed before. I am using some elements of SAFe with a client right now but not all since some of the techniques would not work well, which is consistent with a “pragmatic agile” approach.

Mark Lines (DAD)

The boys from RUP (Rational Unified Process) are back. Building on the profound failure of RUP, they are now pushing the Scaled Agile Framework (e) as a simple, one-size fits all approach to the agile organization.

Ken Schwaber (Scrum)

Quoting Martin Fowler

Respect de la culture, rôles et responsabilités traditionnels • « Start where you are; go where you want » • Moins radical que le « Fractal Agile » • Permet de débuter une transformation

d’entreprise

Introduit les meilleures pratiques • Lean / Agile / Scrum / XP • Devops / Test et qualité agile • Agile Budgeting • Cost of Delay • Principles of Product Development Flow

Supports à la transformation • Formations PO, SM, PPM • Certifications SP, SA, SPC, SPCT • Outils (Rally, Blue-Agility, JIRA, Microsoft) • Business Cases concrets de transformation

SAFe réussies

Raisons de la popularité de SAFe

21

Retour d’expérience sur une Implantation SAFe

22

23 23

Équipes - Exécution

24

Équipes Agile: – 8 feature teams

– 2 components teams

Scrum et « Kanban »

Coaching traditionnel

Scrum

Ce dont nous sommes satisfaits:

Sélection et accompagnement des PO Scrum

La mise en place des 10 équipes

Une cadence unique de 3 semaines x 3 + PI 2 semaines

Product Increment de 11 semaines

JIRA « SAFe » couvrant le portfolio, programme et

équipes

Ce que nous aurions aimé faire autrement:

Constitution des équipes en phase avec SAFe

Formation de l’ensemble des personnes. « Train

everyone! »

Plus de SM, plus de coachs (1 SPC)

Meilleur alignement des coachs

Programme – Synchronisation et alignement

25

2 PI Planning accomplis (6 mois)

Agile Release Train aux 11 sem. JIRA, Métriques de gouvernance

Nos challenges:

DevOps, architecture d’entreprise, équipe System Team (Test E2E) à refaire

Espaces de réunion

- Plusieurs réunions impliquent tous les membres de toutes les équipes!

« Change The Bank » - Stratégique, Groupe - Règlementaire - Grandes Initiatives

« Run The Bank » - Maintenance - Bugs - Maintenance évolutive - Petites initiatives

- À la discrétion du PO

Product Management - Feature management, PO - Risque, Opération, architecture

Portfolio – Stratégie et gouvernance

26

Ce dont nous sommes satisfaits:

Certification de 20 SAFe Agilistes « Leading SAFe ». Managers et SM internes

Mise en place des premières réunions de priorisation avec succès

- Stakeholders principaux

- PO

- Feature Management

Kanban Portfolio couvrant

- WIP

- Priorisation versus engagement

Bonne participation globale

Nos challenges:

Il faut avoir un plan de

communication

Il faut avoir un PMO actif

L’alignement et la maturité

de l’équipe coachs doivent

être aligné à l’approche

SAFe

Gestion de la complexité avec SAFe

27

Connaissance

Alignement Contrôle

sur les résultats

2 sem

aines

10

semain

es

Connaissance

28

Connaissance

Alignement Contrôle

sur les résultats

Fréquences et rapidité DevOps Portfolio et ART Metrics System Demo Program Increment « Released Increment » Indicateurs lean-ux Inspect & Adapt System Team

2 sem

aines

10

semain

es

Alignement

29

Connaissance

Alignement

Scrum of Scrums Scrum of Pos Release Planning Strategic Themes Vision PI Objectives Architecture Runway

Contrôle sur les

résultats

10

semain

es 2

semain

es

Contrôle sur les résultats

30

Connaissance

Alignement

Autonomie Discipline interne Collaboration Création Innovation Mastery Engagement

Contrôle sur les

résultats

Quelques métriques

31

Fréquence de livraison

Architecture

• Architecture

• Infrastructure

• Databases

Tools

• Branch model

• Testing

• Releases

Métriques « Deployment G-Force »

Agile Maturity Assessment, ©2015 DigitalTango Deployment G-Force: Lean Enterprise, 2015

32

Connaissance

Alignement Contrôle

sur les résultats

Métriques Agilité d’entreprise

33

Agile Maturity Assessment, ©2015 DigitalTango Enterprise Agility model, inspiré du travail de Hugo Villeneuve @hugovilleneuve

Enterprise Agility

Agile

Methodology

Agile

Architecture Agile Tools

Scrum, Lean, SAFe, XP, Mindset, Values

PaaS, CI, DevTools, Deployment pipeline, Mature SDLC

SOA, Microservice, WebApi, Distributed architecture

Incremental Architecture, Bimodal, Paced layer

Agile testing, A/B tests, TDD, BDD, ATDD, Devops, Embedded testing

Decoupling, Refactoring, Scalable, Testable, Adaptable

L’agilité d’entreprise ne peut se baser que sur les « individus et leurs interactions » pour créer un alignement, à large échelle nous avons aussi besoin d’une architecture agile et d’outils!

Métriques équipes

34

Identification des axes d’amélioration

• Mise en place

• Mindset

• Communication

• Livraison de valeur

Devops & Automation

PMO Agile

Architecture, Tools & Alignement

Agile Maturity Assessment, ©2015 DigitalTango

Le mode plus prescriptif et la couverture plus exhaustive de SAFe est un avantage en grande entreprise.

• Rassure les sponsors

• N’empêche pas la mise en place de l’agilité et la gestion de la complexité.

• L’alignement est essentiel pour établir une réelle autonomie des équipes

• Apporte une approche Lean/Agile

La formation certifiante SAFe des participants est essentielle pour créer l’alignement.

Développez dès que possible les outils, l’automatisation des tests et l’architecture agile.

35

Gestions des requis en ligne au format SAFe (ex. JIRA, Rally).

• Ne remplace pas les Taskboards physiques des équipes.

La culture organisationnelle doit aussi être transformée!

• SAFe donne l’impression que c’est le nouveau « RUP ». C’est une fausse impression: SAFe implique un changement culturel.

• Exemples de points d’action: Décliner un plan de communication qui touche l’ensemble de l’entreprise, ajouter des formations « Management 3.0 ».

Faites-vous accompagner par des coachs d’expérience alignés qui comprennent votre domaine.

En conclusion

Question?

36

Annexe 1 – Principes Agiles

Les 12 principes sous-jacents au manifeste agile

37

(6) Dialogue en face à face

(7) Un logiciel opérationnel est la principale mesure d’avancement

(8) Encourager un rythme de développement soutenable

(9) Attention continue à l'excellence technique et à la bonne conception (10) La simplicité : l’art de minimiser la

quantité de travail inutile

(11) Les meilleures architectures, spécifications et conceptions émergent d'équipes auto-organisées

(12) À intervalles réguliers, l'équipe réfléchit aux moyens de devenir plus efficace, et règle son comportement

(2) Accueillez positivement les changements de besoins

(4) Les utilisateurs ou leurs représentants et les développeurs doivent travailler ensemble quotidiennement

(5) Réalisez les projets avec des personnes motivées. Fournissez-leur l’environnement et le soutien dont ils ont besoin et faites-leur confiance

(1) Satisfaire le client en livrant rapidement

Alignement Connaissance

(3) Livrez fréquemment un logiciel opérationnel avec des cycles de quelques semaines à quelques mois

Contrôle sur les Résultats

38

Conway, 1968, « Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations. »

PRODUIT

EQUIPE

Annexe 2 – Manifeste Agile

Le manifeste agile

39

Alignement Connaissance Contrôle sur les Résultats

L’adaptation au changement plus que le suivi d’un plan

Les individus et leurs interactions plus que les processus et les outils

Des logiciels opérationnels plus qu’une documentation exhaustive

La collaboration avec les clients plus que la négociation contractuelle

40

Nous reconnaissons la valeur des seconds éléments, mais privilégions les premiers.

A

R

C

A

A

Annexe 3 – Accompagnement SAFe

41

FORMATIONS SAFe SAFe Foundations, 2 heures. Comité de direction. Leading SAFe, 2 jours. Pour les managers et leaders de la transformation agile. Certification SAFe Agiliste. SAFe ScrumXP, 2 jours. Pour tous les membres d’un « Agile Release Train ». Certification SAFe Practitioner. SAFe Product Manager / PO Workshop, 2 jours. Certification SAFe PM/PO. SAFe Program Portfolio Management Workshop, 2 jour. Gestion du portfolio Agile, Agile PMO. SAFe PO Orientation SAFe Scrum Master Orientation, 1/2 jour par module.

FORMATION IC Agile

Agile Fundamentals, 2 jours. Introduction à l’agilité. Certification ICP. COACHING et TRANSFORMATION Agile Évaluation Agile Coaching Agile Equipes Coaching SAFe Entreprise

Votre partenaire agile

43