t

Agile Program Management

Une expérience

Une marque déclinée sur :

- Un site Web

- Des applications mobiles

- Un espace communautaire

Organisation Agile

Dans chaque unité :

- Une équipe Agile

- Cross fonctionnelle

- Auto-organisée

Organisation

Les nouveaux projets émanent de la direction et des unités

Les projets sont choisis par les PO

Développés, déployés

Les utilisateurs sont contents

Et alors ?

Ça marche !

C’est génial !

Fin

Merci

En fait non… rapidement les problèmes surgissent

Pas de transparence entre les unités

Alignement aléatoire

Objectif commun oublié

Et puis

La direction a tendance à pousser des projets quand ça n’avance plus

Mais ça ne marche pas

Pour répondre à sa frustration la direction fait appel à des BA pour concevoir des projets

Et c’est encore pire

Personne n’a connaissance du WIP

Les dépendances entre unités sont fortes et sont révélées trop tard

Le déploiement est problématique

Les blocages ne sont pas résolues et les projets abandonnés

C’est la fin…

La direction n’a plus de vision et s’agite

L’architecture devient vulnérable car des projets risqués sont imposés

Les personnes sont démotivées

…

L’audience baisse

La rentabilité aussi

Plus d’investissement

La marque disparaît

Les problématiques

Adapter une entreprise à l’Agilisation de ses unités de production

Soutenir la croissance d’une organisation Agile

Les solutions du moment

Le cycle en V en intégrant des équipes Agile

SAFe (Scaled Agile Framework)

DAD (Disciplined Agile Delivery)

LeSS (Large Scale Scrum)

Cycle en V

Les métiers et les rôles sont respectés

La remise en cause ne concerne que les équipes de production

Allez… on fait des cycles en V plus court

Ça marche mieux ?

Cycle en V, ça coince

En poussant la réflexion sur l’intégration Cycle en V / Agile une entreprise refusant de mettre en cause son modèle culturel est arrivée à la conclusion :

Seuls les chantiers pouvant s’exécuter en autarcie projet , équipe projet(métier/réalisation) autonome peuvent être menés en agile.

SAFe

Scaled Agile Framework

- Alignement

- Code quality

- Transparency

- Program execution

Safe – big picture

SAFe - PSI

Potentially Shippable Increments (Program Sprint Interval)

Des objectifs partagés sur une période courte

2 jours de kick off + 4 à 6 sprints de 2 semaines

Objectif : Stop Starting and Start Finishing

SAFe – team objectives

La business value est négociée entre DEV et BUSINESS

SAFe – PSI metrics

S’améliorer avec les mesures

Est-ce que ça m’aide ?

Transparence : OK

Alignement : OK (PSI + metrics)

Agile : ~ (tentation au Push)

Délivrer : OK

SAFe – points d’attention

Le business doit être présent au PSI

L’engagement doit-être tenu

Les modalités d’implémentation des features doivent être définies dans les équipes (pas de BA dans le program management)

DAD

Disciplined Agile Delivery

- People first

- Learning-oriented

- Agile

- Hybrid

DAD - valeurs

- People-first- Goal-driven- Hybrid agile- Learning-oriented- Full delivery lifecycle- Solution focused- Risk-value lifecycle- Enterprise aware

DAD – big picture

DAD - Inception

Faire émerger la vision dans un processus Scrum

Discipline pour rester sobre et court

Une sorte de Sprint 0 répétitif

DAD - Construction

Délivrer une solution

- Scrum

- Lean flux continue

- XP

- …

DAD - Transition

Ce n’est pas toujours aussi simple de déployer

Idéalement cette phase disparaît au profit du déploiement continue

DAD - lifecycles

The Advanced/Lean DAD Lifecycle

DAD – risk/value driven

Prise en compte du risque/valeur très tôt dans le flux

- Eviter de ne pas délivrer du tout

- Eviter de délivrer la mauvaise fonctionnalité

- Eviter le manque de visibilité

DAD – concentré sur les solutions

Les stakeholders participent aux itérations pour anticiper les risques et garder la vision

Chaque itération doit déboucher sur un incrément utile et utilisable pour l’utilisateur

Les besoins changeants des stakeholders sont satisfaits

Est-ce que ça m’aide ?

Oui à condition de :

- Changement culturel fort : abandon complet du command & control

- Stakeholders au service de l’équipe

DAD – points d’attention

- Limites du modèle risk/value

- Discipline ? Problème culturel ?

LeSS

Large-Scale Scrum

- Valeurs Agile

LeSS - processus

LeSS - coordination

Inter-team coordination meeting

- Scrum of Scrum pour améliorer l’information le partage et l’alignement

LeSS – équipe impliquée dans le produit

Joint Light Product Backlog Refinement

- Deux membres de chaque équipe

- Analyser, découper, préparer les story à venir

LeSS – des retours au plus tôt

In-Sprint Item Inspection

- Obtenir des retours avant la review

LeSS - retrospective

Joint Retrospective

- Scrum Master + représentants

- Amélioration au niveau de l’organisation

LeSS - Est-ce que ça m’aide ?

- Rôle de PO challengeant

- Très Agile mais suis-je prêt ?

- Que deviennent les Product Manager ?

Retours d’expériences

Spotify

Telstra

Spotify - Squad

Squad cross fonctionnelles et autonomes

- PO est un entrepreneur en mode lean stratup

- Tout ce dont une équipe a besoin pour travailler

Spotify - matrice

Spotify - monitoring

Spotify - dépendances

Spotify – est-ce que ça m’aide ?

Les indicateurs sont un plus

La transversalité organisée

PO entrepreneur => suis-je prêt ?

Besoin d’une vision forte et comprise

Telstra

Organisation en « services »

- Pipeline services

- Development services

- Deployment services

Telstra

Telstra – Agile train

Telstra

Idéalement le service de développement PULL les features

Pipeline service avec des Portofolios Manager et des architectes => ils font l’interface, ils adoucissent le contact business

Ressources

Tesltra : http://fr.slideshare.net/ScaledAgile/agile-aus-2013final

Spotify : https://dl.dropboxusercontent.com/u/1018963/Articles/SpotifyScaling.pdf

SAFe : http://scaledagileframework.com/

DAD : http://disciplinedagiledelivery.wordpress.com/

LeSS : http://www.craiglarman.com/wiki/index.php?title=Large-Scale_Scrum

Comparaison : http://www.scrum-breakfast.com/2013/10/scaling-scrum-safe-dad-or-less.html