Pie

rre E

. N

eis

1

récolte des besoins

Animation de groupes

Pie

rre E

. N

eis

2

Qui suis-je?

Pie

rre E

. N

eis

3

Tester Sentir Répondre

Ordre du jour

Pie

rre E

. N

eis

4

Agenda

Principes de l'agilité et la gestion de la

complexité (modèle Cynefin)

Idéation, Visioning et la création d’User

Stories

Principes et techniques de

priorisations: user story, épic et thème

Création d'un Product Backlog et d'un Release Plan centré utilisateur

Le Process Scrum est le rôle des utilisateurs

Techniques de facilitations: Wide Band Delphi, Open Space, World Cafe,

Serious Game

Études de cas et intégration dans une

équipe agile existante

Pie

rre E

. N

eis

5

LES PRINCIPES DE L’ AGILITE

❶

Pie

rre E

. N

eis

6

Manifeste pour le développement Agile de logiciels

Les individus et leurs interactions• Des logiciels opérationnels• La collaboration avec les

clients• L’adaptation au changement

les processus et les outils• une documentation

exhaustive• la négociation contractuelle• le suivi d’un plan

Pie

rre E

. N

eis

7

Principes sous-jacents au manifeste

Priorité1 satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à grande valeur ajoutée.

2 Les processus Agiles exploitent le changement pour donner un avantage compétitif au client.

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

4 Les utilisateurs ou leurs représentants et les développeurs doivent travailler ensemble quotidiennement tout au long du projet.

5 Réalisez les projets avec des personnes motivées.

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

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

8 Ensemble, les commanditaires, les développeurs et les utilisateurs devraient être capables de maintenir indéfiniment un rythme constant.

9 Une attention continue à l'excellence technique et à une bonne conception renforcent l’Agilité.

10 La simplicité – c’est-à-dire l’art de minimiser la quantité de travail inutile – est essentielle.

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, puis règle et modifie son comportement en conséquence.

Pie

rre E

. N

eis

8

Le triangle magique

Abondance

Engagement des employésReconnus, engagés, employés

heureux

Satisfaction du ClientServir le client

Création de ValeurMaximiser le ROI et

optimiser la trésorerie

Pie

rre E

. N

eis

9

Le Problème

• Le métier et le développement sont souvent enfermés dans une relation malsaine.

• Les deux partenaires doivent changer pour améliorer la satisfaction client et la création de valeur

Pie

rre E

. N

eis

10

Equipes auto-gérées Organisation traditionnelle

Orientées client Pilotée par le management

Force de travail multi-compétence Foce de travail constituée de spécialistes isolés

Peu de description de poste Beaucoup de description de poste

Information largement partagée Information limitée

Peu de niveau de management De nombreux niveaux de management

Orientée Ensemble du Métier Orientée fonction/département

Objectifs partagés Objectifs séparés

D’apparence chaotique D’apparence organisée

Emphatique sur l’hypothèse d’atteinte du résultat Emphatique sur la résolution de problème

Très fort engagement des “producteurs” Très fort engagement du Management

Améliorations continues Améliorations incrémentales

Autorégulées Contrôlées par le Management

Basées sur des valeurs et des principes Basées sur les politiques et les procédures

Source: "Leading self-directed work teams" by Kimball Fisher. Traduction libre Pierre NEIS.

Pie

rre E

. N

eis

11

Déclaration d’Interdépendence

Clients engagés

Amélioration de l’éfficcacité

R.O.I.

Optimisation de la performance

Pie

rre E

. N

eis

12

LA GESTION DE LA COMPLEXITÉ

❷

Pie

rre E

. N

eis

13

Pie

rre E

. N

eis

14

Cynefin

Pie

rre E

. N

eis

15

Pie

rre E

. N

eis

16

Pie

rre E

. N

eis

17

Pie

rre E

. N

eis

18

Pie

rre E

. N

eis

19

Pie

rre E

. N

eis

20

Pie

rre E

. N

eis

21

Désordre

Pie

rre E

. N

eis

22

Pourquoi gérer la complexité?

Pie

rre E

. N

eis

23

Temps

Conception Croissance Maturité Declin Retrait

Projet

ProjetProjet

Projet Projet

Projet

Projet

Projet

Cycle de Vie d’un Produit

Pie

rre E

. N

eis

24

Conception Croissance Maturité Declin Retrait

Projet

ProjetProjet

Projet Projet

Projet

Projet

Projet

Zone complexe Zone Compliquée

Developpement Production

Pie

rre E

. N

eis

25

Nouveaux challenges….

vitesse Stakeholders

RisquesChangement permanent

personnes

Business Alignment

Pie

rre E

. N

eis

26

IDÉATION, VISIONING ET LA CRÉATION D’USER STORIES

❸

Pie

rre E

. N

eis

27

De l’idée à la Vision…

Idée Vision Product Backlog

Développement Acceptation Livraison

Pie

rre E

. N

eis

28 Idéa

tion

Pie

rre E

. N

eis

29

La vision du produit est un aperçu de ce que

votre produit pourrait être.

Pie

rre E

. N

eis

30

Les questions à se poser…

1. Qui va acheter le produit? Qui est le client cible? Qui va utiliser le produit? Qui sont les utilisateurs?

2. Besoins des clients adressés par le produit? Quelle est la valeur ajoutée par le produit?

3. Quels attributs du produit sont essentiels pour répondre aux besoins des clients sélectionnés, et donc pour assurer le succès du produit? Dans quels domaines le produit va exceller?

4. Comment le produit se compare-t-il face aux produits existants, à la fois des concurrents et de la même entreprise? Quels sont les unique points de vente du produit (single selling point)? Quel est son prix cible?

5. Comment l'entreprise fera de l'argent de la vente du produit? Quelles sont les sources de revenus et quel est son modèle d'affaire?

6. Quel est l'échéancier et le budget cible pour développer et lancer le produit?

Donnez 3-5 indicateurs clés

Définir la valeur ajoutée

Les ressources financiéres?

Business Model?

Faisabilité?

Pie

rre E

. N

eis

31

Techniques pour créer une vision• The House of Quality The Kano Model

Personas, Scenarios et cartes de consommation Use Cases, User Stories et Modèles Cartes, Séquences et Storyboards Vision Box et “Trade Journal Review”

Pie

rre E

. N

eis

32

Vision Validation

Pour <client cible>

Qui < déclaration concernant la nécessité ou l'opportunité >

Le <nom du produit> estUn(e) <catégorie de produit>

Qui < avantage clé, raison impérieuse pour acheter>Contrairement à <alternatives concurrentielles>

Notre produit < déclaration de différenciation >

Pie

rre E

. N

eis

33

Une fois que la Vision est claire, nous pouvons rencontrer les utilisateurs

Pie

rre E

. N

eis

34

User Stories

Pie

rre E

. N

eis

35

User Stories du Product Backlog

User Stories décrivent les exigences du point de vue du client ou du client final• Chaque User Story fournit de la

valeur et est facile à comprendre• Les User stories supportent la

décomposition des exigences de granularité grossière à fine.

Les User Stories sont constituées• D'un nom significatif• D’une brève description• Et d’une condition de satisfaction

Les User Stories remplissent les critères 3C:• Carte• Conversation• Confirmation

Pie

rre E

. N

eis

36

User Roles

Les clients et les utilisateurs différents ont

des besoins et des exigences différents.

Établir une distinction claire entre les différents

rôles

Pie

rre E

. N

eis

37

User Story Card

• Une brève description textuelle des exigences

• + Risques

• + critères d’acceptance

En tant que Product Owner

Je peux / je veux estimer les coûts

3 lignes de description de l'exigence

Pie

rre E

. N

eis

38

Les bonnes Stories sont INVEST

•independentes

I•n

egociables

N

•valuables

V

•estimables

E

•Sized appropriately (de bonne taille)

S

•testables

T

Pie

rre E

. N

eis

39

Exercice

•Créez un exemple d’application pour la discussion

1•Etude

de cas réelle ou non

Lignes directrices

•Rédiger (lisiblement!) une description de votre étude de cas(100-200 mots)

2

Pie

rre E

. N

eis

40

Sécurisation des Informations Personnelles

Modèle

•Je voudrais une application bureau que je puisse utiliser pour stocker toute mon information confidentielle tels que les numéros de série, les informations de Carte de Crédit, les alias d’enregistrement sur les sites web, les mots de passe, etc. pour chaque item que je souhaite stocker, je dois définir le type de données (comme une date d’expiration). Bien entendu, le système devra être protégé par mot de passe et très sécurisé. Je souhaiterai effectuer des sauvegardes/restaurations online de sorte que je puisse récupérer mes informations à distance. Le produit devra posséder des options de recherche, etc.…

Source: Mike Cohn, CSPO

Pie

rre E

. N

eis

41

CRÉATION D'UN PRODUCT BACKLOG ET D'UN RELEASE PLAN CENTRÉ UTILISATEUR

❹

Pie

rre E

. N

eis

42

Product Backlog?

Sprint

Release

Releases futures

Le Backlog est une liste de tâches ouvertes comme :–les exigences

– une liste de tous les travaux souhaités pour le projet

–Idéalement exprimé de telle sorte que chaque objet a une valeur pour les utilisateurs ou les clients du produit–Priorisé par le Product Owner

–Repriorisé au début de chaque Sprint

Prio

rité

haut

e

Prio

rité

moy

enne

Pie

rre E

. N

eis

43

Le Product Backlog répond aux questions suivantes:

Quoi? Quand? Pour Qui?

Pie

rre E

. N

eis

44

Stories, themes and epics

THEME:

Un recueil de stories

USER STORY:

Une description de la fonctionnalité désirée du point de vue du l'utilisateur ou du client

EPIC:

Une grande story

Pie

rre E

. N

eis

45

Exercice

•Reprenez votre exemple d’application pour la discussion

1

•Créez des US

•Estimez•Priorise

z

2

Pie

rre E

. N

eis

46

Product Roadmap

Pie

rre E

. N

eis

47

Objectifs de la Product Roadmap• Faciliter la

communication entre la Scrum Team et les participants au projet

• Élaborer une stratégie commune pour la Product Vision

Planifier idéalement pas au-delà de 6 mois

Pie

rre E

. N

eis

48

Product Roadmap

Gestion du temps de l’équipe

Exigences client

Inspect & Adapt

La Roadmap est conçue considérant ces trois aspects :

-Qui sont les clients?

-Quels sont leurs besoins?

-Quelles sont les 3-5 fonctionnalités les plus prioritaires?

Pie

rre E

. N

eis

49

Release Planning

• Example Guichet Unique V3.0

Pie

rre E

. N

eis

50

Création d’un Program Backlog

• Le programme backlog reprend l’ensemble des projets nécessaires pour délivrer la version 3.0 du Guichet Unique

Projet

Projet

Projet

Projet

Projet

Projet

Projet

Projet

Projet

Projet

Projet Program

Backlog

Pie

rre E

. N

eis

51

Prioriser les projets

Projet3

Projet4

Projet5

Projet 6

Projet 7

Projet 8

Projet 9

Projet 10

Projet 11

Projet 2

Projet 1

Program Backlog

En fonction de:• la faisabilité•(s) interdépendances• les risques• la disponibilité de l’implication des parties aux projets• la disponibilité des technologies•De la complexité

Pie

rre E

. N

eis

52

Planification # 1 (rétroplanning)

06/1212/11

1 6 72 3 4 5

Projet3

Projet4

Projet5

Projet 6

Projet 7

Projet 8

Projet 9

Projet 10

Projet 11

Projet 2

Projet 1

Estimation idéale

Les points ❶❷❸❹❺❻Devront être clarifiés. Ceux-ci permettront de tester le réalisme du planning idéal.

Pie

rre E

. N

eis

53

Projet 10

Projet 11

Projet 8

Projet 9

Projet 10

Projet 11

Projet 6

Projet 7

Projet 8

Projet 9

Projet 10

Projet 11

Projet4

Projet5

Projet 6

Projet 7

Projet 8

Projet 9

Projet 10

Projet 11

Planification # 2 (suivi du Programme)

06/1212/11

1 6 72 3 4 5

Projet3

Projet4

Projet5

Projet 6

Projet 7

Projet 8

Projet 9

Projet 10

Projet 11

Projet 2

Projet 1

Estimation idéale

Projet 11

Mesure du Delivery

Pie

rre E

. N

eis

54

Projet 10

Projet 11

Projet 8

Projet 9

Projet 10

Projet 11

Projet 6

Projet 7

Projet 8

Projet 9

Projet 10

Projet 11

Projet4

Projet5

Projet 6

Projet 7

Projet 8

Projet 9

Projet 10

Projet 11

Planification # 3 (évaluation des écarts)

06/1212/11

1 6 72 3 4 5

Projet3

Projet4

Projet5

Projet 6

Projet 7

Projet 8

Projet 9

Projet 10

Projet 11

Projet 2

Projet 1

Estimation idéale

Aux points ❶❷❸❹❺❻Nous mesurons les écarts entre Estimation idéale et Mesure du Delivery pour savoir si le projet respecte son engagement en terme de Time-to-market

Projet 11

?

?

?

??

Mesure du Delivery

Pie

rre E

. N

eis

55

Avantages

• Identifier rapidement le risque de non respect de la deadline

• Apporter les mesures correctives• Identifier les fonctionnalités non-prioritaires

pouvant entrer dans la release 4• Réduire le risque de non-livraison• Identifier la charge de travail et la complexité

du développement

Pie

rre E

. N

eis

56

LE PROCESS SCRUM EST LE RÔLE DES UTILISATEURS

❺

Pie

rre E

. N

eis

57

Pie

rre E

. N

eis

58

Scrum Flow

• Scrum est un cadre souple pour la réalisation de projets complexes.

• A l’origine Scrum a été formalisé pour le développement de logiciels. Mais il fonctionne très bien également pour les projets complexes et novateurs.

• Le cadre de Scrum est trompeusement simple

Pie

rre E

. N

eis

59

Le Cadre de SCRUM• Le Product Owner crée une

liste de fonctionnalités appelée Product Backlog

• Pendant le Sprint Planning, l’équipe “tire” un petit morceau du haut de cette liste: le Sprint Backlog; et décide comment implémenter ces éléments.

• L’équipe dispose d’un temps donné pour y arriver: le Sprint

❶

Pie

rre E

. N

eis

60

Le Cadre de SCRUM• Chaque jour, l’équipe mesure sa

progression pendant 15’: le Daily Scrum

• Durant tout le projet, le Scrum Master fait en sorte que l’équipe reste concentrée sur sa mission.

• A la fin du Sprint, les travaux doivent être potentiellement livrables. Ces travaux sont considérés comme finis.

❷

Pie

rre E

. N

eis

61

Le Cadre de SCRUM• Le Sprint se termine avec la Revue

de Sprint et la Rétrospective.

• Lorsque le prochain Sprint démarre, l’équipe choisit un nouveau morceau dans le Product Backlog et recommence le processus.

• Le processus s’arrête lorsque l’on a délivré suffisamment de fonctionnalités, ou que le budget est atteint, ou que la date butoir est atteinte.

❸

Pie

rre E

. N

eis

62

Objectif recherché

Maximiser la valeur

Pie

rre E

. N

eis

63

Que recherchons-nous?

• L’Engagement de chacun

• La Responsabilisation de chacun

• La Participation de chacun

Pie

rre E

. N

eis

64

Améliorations attendues

Pie

rre E

. N

eis

65

Value Velocité

SPRINT

Daily Scrum

Sprint Zero Bl

ocag

e

READ

Y

DO

NE

Fonctionnalités claires

Constitution du socle de projet et du PBL initial

Tests automatisés, intégration continue, suppression des obstacles

Validation des livrables du Sprint

CHK Story

CHK Fonctionnalité

Pie

rre E

. N

eis

66

Scrum Flow

• Idea• Vision• Roadmap

Product Backlog

• Sprint Planning Meeting

• Sprint Backlog• Daily Meetings

Sprint • Sprint Review• Retrospective• Velocity• Releaseplan

Potentially Shippable Product Increment

1 2 3

Pie

rre E

. N

eis

67

Sprin

t Pla

nnin

g 2

Sprin

t Rev

iew

Sprin

t Ret

rosp

ectiv

e

Development

Daily Meetings

Sprin

t Pla

nnin

g 1

Sprin

t Pla

nnin

g 2

Sprin

t Pla

nnin

g 1

SPRINT

Pie

rre E

. N

eis

68

TECHNIQUES DE FACILITATIONS: PYRAMIDE DE DECISION, WIDE BAND DELPHI, OPEN SPACE, WORLD CAFE, SERIOUS GAME

❻

69

PYRAMIDE DE DECISION

Pie

rre E

. N

eis

Quelles sont mes attentes?

Quel est ma fonction?

Qui suis-je?

Pie

rre E

. N

eis

70

WIDE BAND DELPHI EXTENDED

Pie

rre E

. N

eis

71

Comment cela marche?

•Chaque participant exprime l’un après l’autre son point de vue sur des post-its et les affichent sur le tableau• Chaque participant « vend » sont idée•Le suivant peut revenir sur la décision du précédent en donnant son avis•Lorsque le tour est terminé, un consensus est trouvé… idéalement

Pie

rre E

. N

eis

72

OPEN SPACE

Pie

rre E

. N

eis

73

Analyse

Force• Communication• Inspiration• Participation• Échange

Faiblesse• Éparpillement• Peu de dynamique de

l’ensemble du groupe• Trop ouvert pour obtenir un

consensus (ce n’est pas l’objet de l’OS)

Opportunité• Idéal pour faire émerger de

nouvelles idées• Format ouvert• Adapté pour des évènements

d’amélioration de l’existant

Menace• Le modérateur doit être très

actif et créer l’énergie• Sans driver, cette animation

est risquée• Le format ouvert peut ne pas

convenir à une audience « traditionnelle »

http://www.openspaceworld.org/

Pie

rre E

. N

eis

74

Pie

rre E

. N

eis

75

Analyse

Force• Communication• Inspiration• Participation• Échange

Faiblesse• peu

Opportunité• Approche itérative et

incrémentale• Fait parler les « silencieux »• Maintient la discussion dans

un état « complexe » et le reporting « compliqué »

Menace• Peu grâce au time-boxing• Le modérateur doit ne pas être

trop présent• 6 personnes mini

Pie

rre E

. N

eis

76

SERIOUS GAMES

Pie

rre E

. N

eis

77http://innovationgames.com/

Pie

rre E

. N

eis

78

ETUDE DE CAS... NEXT STEPS!

❼

Pie

rre E

. N

eis

79

Pie

rre E

. N

eis

80

Merci

Pie

rre E

. N

eis

81

Pierre E. NEIS

Management Consultant

Head of Lean Centre of

Competence at coPROcess S.A.

Scrum & Lean Coach