Post on 26-Jun-2015
description
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