Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

Agile tour Montréal 2014 - Transition Agile en Entreprise

Retour d'expérience.
by

Guillaume Soyer

on 4 December 2014

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Agile tour Montréal 2014 - Transition Agile en Entreprise

Transition Agile en Entreprise
Vraiment ?
Faire plaisir aux développeurs !
Avoir un processus moins lourd !
On va livrer plus vite !
Ça va coûter moins cher !
Pas de documentation !
J'ai lu un livre sur Scrum !
Chacun dans l'organisation a ses raisons pour ou .....
contre
Nos raisons
Intérêts grandissant des équipes et du management.
Volonté d'améliorer l'image de la R&D
Trouver une solution aux délais et coûts de développement non maitrisés.
Besoins changeants
Organisation
Processus
Rôles
Gestionnaire de Projets
Gestionnaire de Produit
Développeur Serveur
Développeur Carte
Testeur Serveur
Testeur Carte
QAO / CMO
Rédacteur technique
Architecte
Maintenance
Les Origines
Pourquoi Agile ?
Équipes Mixtes
Le Plan
Rétros
Garder le cap
Scrum-But
n'est
pas
une option
Un tableau !
1ers Succès
R&D Montréal
Gestion
de produit
R&D
Management
PMO
Équipe Process
Support &
Maintenance
Impliquer les reste de
l 'entreprise
Support de la direction
Budget de formation
Transparence sur les risques
Gestion des changements
Gestion des besoins
Participation active
Processus nouveau
Suivi Qualité
Suivi projet
Audit
Maintenance Niveau 3
Documentations
Formation
Livraison
Définir les Rôles
Product Owner
Scrum Master
Product Manager
Project Manager
Équipe Dev
Architecte, Dev, QA
Scrum Master Certified :
Scrum par la pratique :
2 Gestionnaires de Projet
1 QAO & R&D Manager
Product Manager
Testeur, Dev
Architecte & Maintenance
Formation
Des défis
La maturité

Sur la route
Formation PO :
2 Gestionnaires de Projet
1 PM, 2 QA & R&D Manager
Choisir les outils
Adapter l'environnement
Gestion du BL :
Gestion du Sprint :
Burndown :
Réorganiser le plancher
Cohabitation
Tableau de sprints
Espace pour stand-up
Un escabeau...
Grande entreprise ?
Négociations:
Compromis:
Rôles
On ne change rien
Budget:
(RH, PMO, Marketing...)
Sponsor
Formation
Outil
Choisir
le projet
Projet Pilote
2 équipes
Grande entreprise ?
Rôles :
Hierarchie :
Team :
Dis-moi juste quoi faire !
Être responsable est nouveau.
On ne peut plus blâmer le GP !
Management :
aller-retour avec la maison mère
RH :
Culture individuelle
Top 15% et le Bottom 5%
En tant qu'équipe de R&D, Je veux implanter Scrum afin de .......
R&D -2008
SP :

Un cycle de vie complexe
Comme des gaulois !
Risques:
financier
sécurité
Embarqué
multi-platforme
100%
Qualité
et Contrôle
à
R&D de 45 personnes
20 développeurs
15 testeurs
Architecte,
Maintenance & Support
Management,
Gestion de projet, CMO/QAO
Gestion de produit
Marketing
Cycle de version de ~12 mois
Budget de 1.5 M$
Clients dans 15 pays
Projets internationaux
Greenhopper
à la main
Excel
Vue des équipes :
Motivations ?
Chaque chose à sa place
une place pour chaque chose
Limiter
les changements
Humain
Formations pertinentes
Confiance envers le management
Participer au développement du plan
Déjà plus de leadership
Ressources à la disposition de l'équipe
La validation
Qu'en est-il maintenant ?
1ers Sprints
Équipes
Dev vs QA
Équipe multi-disciplinaire
Des tâches séparées
Pas de collaboration en planning
Dev = Développement seulement
Équipe dans l'équipe
100 % tâches
0% comm.
1 Story
=
1 Dev
Nous décidons
seuls
Estimations
=
Mini
water
fail
Auto-Gestion ?
Estimé ne sont pas fiables
Pas d'engagement d'équipe
Rien ne change,
quand on y change rien...
Sans le gestionnaire, pas de décision !
Transparence
Trop beau pour être honnête...
Plus de
leadership
!
Dev :
On veut coder !
QA :
Écoutez nous !
Team :
Laissez moi travailler !
Management :
Trop d'information, Brownien
Sur-reaction
Big brother
Mon projet est chaotique !
Jusqu'ici tout va bien !
> capacité équipe
Dépassement 25%
Team :
Syndrôme de l'autruche
C'est à cause de...
C'est sous contrôle maintenant.
On va y arriver !
Management :
Être ou ne pas être Directif...
Équipe soudée
Travaillent ensemble depuis > 5-10 ans
Produit

PMO :
Pas de Flexibilité
Outils imposés: MKS, Project server : Agile
Peu de liberté pour les équipes
Pas de présence locale.
Story meeting
Changer la stragégie de validation
Améliorer les estimations
L'architecture
Les bugs
DoD trop Gros
Qualité ne suit pas
Pas les outils pour aller plus vite : CI, Automatic tests
On accumule de la dette
14 sprints : 3 mois de stabilisation !
Processus
Manque de rigueur
Le Backlog n'est pas à jour : Release Burndown
Sprint Backlog : Manque d'information
On manque de visibilité
Product Owner
Servant <> esclave
Leader sans pouvoir
SM = QAO = gardien des processus
Transparence
Dev Team
Daily scrum
Pointez les histoires
Afficher règles d'équipe
Visibilité commence par l'équipe
Management
Se concentrer sur la vision globale
Rétrospective sur invitation
Habituer l'équipe à sa présence
SM : rappel à l'ordre aux managers !
La Confiance n'empêche pas le contrôle
Pas de rôles
Pas de règles
Équipes instables
1ères Solutions
Grande entreprise ?
Rôles :
Hierarchie :
Pouvoir hierarchique
mal, mais ça marche !
RH :
Objectifs de performances Agile
PMO :
Dérogation outils
Contrebalancer pouvoir du PO
Reconnaître rôle SM dans la R&D
Groomings réguliers
Métriques sur les sprints et BL
Refuser
un story
non
groomée
Template de tâches par Story
Sprint de livraison détaillé

Processus
Ça ne résout pas notre problème de PO !
On décompose:
Story DoD
Sprint DoD
Release DoD

Rôles
Scrum Master
Une culture de qualité
Qualité:
du produit
du process
}>
Restructurations
}
Équipe soudée
{
Équipe stable
Fusions-acquisitions
Zone de confort
Management R&D Centralisé
Forte concurrence Asie
Il faut se démarquer mais jouer en équipe
Mais
Rétrospectives :
Vu comme psychothérapie
Remise en question ? :
Les autres.

Pas de suivi
Du mal à s'organiser
Décisions :
Responsabilité :
Entre anarchie et individualité.
0% Leadership
Architecte, Intégrateur,
Rédacteur Technique, Maintenance, QAO, CMO
Pas intégré
Product Manager <> Product Owner
On aime scrum,
MAIS...
Restructuration des équipes
Partage
Leader

(et mous)
Naturels
Stabilité
sur la version
Ressources partagées sur appel
Patrick Giasson
(L'équipe)
Guillaume Soyer
(Le management)
Vision Agile :
BackLog = 100% Business
Change tout le temps
IL faut coder : Planning, Retro, Meetings...
Présence client plutôt qu'équipe
Scrum Master
Dev Team
Du mal à trouver sa place
Auto Gestion :
Vision stratégique
Rapport Management
Organisation équipes
Gestionnaire de projet R&D :
Participation,
Proactivité,
Suivi des règles
évaluation 360° (SM, PO, Team)
Dérogation processus
Gestion Changement
Spécifications
SVN, Maven
Microsoft Project
Long & difficile
Weekly des SMs
Scrum Master Guide
Auto-formation
Dev Team
Rétrospectives
Participation
Plan d'action
Non négociable
}
Limiter le WIP :
Deux tâches max.
Gestion Projet 101
}
Estimation
Risques
Planification
Product Owner
Rappel à l'ordre
Il y a des règles
PO délégués dans les équipes
On resserre les règles
Objectifs individuels de travail en équipe !
Tableau :
}
Processus existant
Compliqué,
Artificiel
Engagement de la R&D
T
Q
$
Revue documentaire
Impossible à donner
Facile : tout est déjà fait
Phase de stabilisation et d'audit
Théoriquement : plus nécessaire
Mais nécessaire
Scrum pour maintenance.
Trop d'interruptions
Pas d'objectifs de Sprint
Priorités quotidiennes
Scrum pour maintenance.
Rôle du GP
Scope
FRs
Gestion du changement
Backlog.
Les Plans de tests.
Modification du User Guide.
CRM
Rien
Métrique sur volatilité du BL
Objectif d'équipe ?
Pas de RH locale
Comité de pilotage si budget/temps > 12% du plan.
(Release Planning initial)
Engagement

Design Review
Changement de mentalité

MAJEUR
T
Q
$
Backlog.
Les Plans de tests.
Modification du User Guide.
Le processus
Suivi
Budget
Rapport
Nb Ressources
x
Nb Sprints
Peu fiable sans Release Plan
Manque de rigueur du BL impacte le suivi
- Transparance
- Estimé par SP
- Grooming
- BL organisé
CRS
Spécifications
Définies
FRS
SRS
SDD
Backlog
+
Stories
Livraison
par
incréments
Architecture
évolutive
Refactoring
Mocks
Stubs
Outils
PM
Architectes
Programmation
Assurance
Qualité
Spécifications
PO
Devs
QA
Specifications
Tests
unitaires
Tests
d'intégration
Tests
exploratoires
Tests
unitaires
Tests
d'intégration
Qualité continue
Tests
Processus
Documentation
Intégration et Régression
Serveur = Tests en continu
Client = Tests exploratoires
Intégration client/serveur à chaque sprint
Niveau de confiance
Interaction entre
Devs et QA
dans une story
P.O. impliqué
immédiatement
dans les
discussions
Aucuns
'Bug High'
ne survit
à une story
timebox
utilisée
pour fixer
les 'bugs'
Daily Scrum
As a team member ...
I want to do ...
To improve ...
Retrospective
As a team member ...
I want to do ...
To improve ...
Revue
As a team member ...
I want to do ...
To improve ...
Planification trop longue
Besoin de reprendre notre souffle
Besoin de coordination inter-équipe
Monter la barre pour la baisser
'Story' reportée
Réflexe de waterfall
Abus du système
Trop de négociation avec le P.O.
Livrer moins avec plus de qualité ? Pas vraiment.
Sprints de livraison

Test de régression
Finalisation de la documentation
Conformité avec le corporatif
Scrum Process
Promouvoir le TDD
Uniformiser dévelopement et tests sur 3 plateformes:
Embarqué
Serveur
Mobile
Équipes multi-disciplinaires
Manque d'outils pour tests fonctionnels sur le client
Intégration continue difficile (Embarqué)
Défis
Bloquants
Différentes visions
Différentes personalités
Outils 'corporate'
Documentation
Structurer l'anarchie
Team Rules
DoD
Réamménager les cubicules:
3 Devs
1 QA
Poker Planning
Magic Estimation
Historique des stories
Grooming
INVEST
T: Testable
I : Independant
N: Négociable
V: Valeur
E: Estimable
S: Simple (small)
Le premier projet Done !
PO présent
Objectif clair et visible
Focus sur priorités
Actions immédiates
Support Management
0% Impediment
Agile fonctionne !
Démonstration
Grande visibilité,
PO en 1ère ligne
1 équipe de 8 personnes - 1 Sprint
délais=1 mois, charge initiale=2 mois.
}
Succès !
Danger
Crédibilité - Renforcement positif
Team,
Action !
Première Livraison
14 sprints
3 équipes
Version majeur
Documentation
Estimation
Qualité
Sprint Livraison
3 mois de stabilisation
même cyle de livraison
Toujours pas de vision
Reconnaissance de l 'organisation
Reset !
Sentiment de perte de pouvoir
Changer les choses graduellement
Technique
Utilisation d'outils open-sources
Forte expertise technique
Produit existant (plus facile)
Le Manager
Gestion des équipes
Gestion des projets
Son rôle
Stratégique
Tactique
Nos souliers ont beaucoup voyagé.
Green effect : vrai statut
Différent type d'approche
Équipe client - Trop d'analyse - Waterfall
Équipe serveur - Pas de docs - Refactoring
Équipe
Management
Vrai transparence ?
Je suis toujours responsable !
Qui est Responsable ?
Évaluer une équipe ?
Intervenir bloque l'agile !
Équipes avec vision tunnelisées
Peu de communication inter Domaine
Manque de coordination sur l'ensemble
Constat :
Perte d'engagement
Rythme trop soutenu ?
Pas d'objectifs de sprint réalistes
Story < 3 semaines : Pas facile
Approche ScrumBan
Team 1
Team 2
Team 3
Planning
Planning
Planning
Planning
Revue
Revue
Revue
Revue
Revue
Rétro
Itération
Intégration
6-8 semaines
1-2 semaines
Backlog : plus facile à groomer
Sprint Backlog : focus sur 3 stories
Revue : retour PO plus rapide
Rétro : plus de contenu
Daily : + scrum de scrum
3 Story max
2 tâches max par personne
5 tâches max ongoing
Tableau plus dynamique
Forcer le travail en équipe
Augmenter la vélocité
Équipe :
Management :
Philosophie scrum
Limiter le WIP
Avantages
Vrais objectifs d'itération
Plannings plus courts et efficaces
On peut souffler
Plus de focus sur le produit vs le sprint
Vélocité
Engagement
Encore des solutions
Business
Préjugés Scrum
Des défis d'équipe:
Exécutants -> Leaders
Plus responsables
Plus autonomes
}
Auto-gestion
Vision sur le sprint
Vision sur la release
Vision sur le projet
}
Plus que
des tâches
laisser le
contrôle
à l'équipe ...
... mais
sécuriser la
livraison
Savoir
prioriser
Être près de l'équipe
Prioriser les besoins
Connaître le marché
Connaître le produit
Product owner
Product manager
Et la grande entreprise dans tout ça ?
Et la formation ?
Et le support ?
Et le transfer à la maintenance ?
Et le 'packaging'
Done Prêts à livrer
Processus
en place
Processus
Centre expertise
Coach officiels : Singapore, Nice
Blog - Wiki entreprise Agile
Produits
Acceptance Client :
1er coup!
Amélioration continue
Management
scrum,
master,
poker planning,
story point,
des post-it !
Processus itératif... Encore un autre !
Aucun responsable,
Pas d'engagement
Pas de documentation
Résistance au changement
'Sustainable pace' = Overtime
Pas très sérieux
Clients,
Contrat,
Scope,
Budget,
Date fixes
Le bon côté des choses
Presque tous veulent toujours faire de l'agile maintenant.
Le process est appliqué avec beaucoup de discipline.
Des leaders sont ressortis du groupe
Meilleure compréhension du besoin de communication
Tests unitaires mais pas de TDD
Encore loin du Agile Testing Mindset
Pas complètement multi-disciplinaire
Et les moins bons côtés
Agile
reconnu
par PMO
Confiance : Design Review
engagement
Crédibilité : On livre, et Bien !
Une équipe
auto-gérée
et responsable
... avec le management toujours à l'affût
des distractions
Grooming
Planning
Revue
Retro
Merci à nos managers.
Agile n'est pas facile. Toujours
difficile de ...
Découper en petites Stories
Définir l'objectif du Sprint
Regarder la forêt. Pas juste l'arbre
Vendre des idées à nos pairs
On s'est rendu où ?
3 versions
majeures
livrées
Intégration
< 3 semaines
CoS
Use Cases
+
Tests
QAO
Inclut dans
la DoD
Livraison
Templates de
tâches
Bug Fix
Kanban
+
DoD
P.O.
Dans la
R&D
Maintenance
Fonctionne
en
Kanban
Question
du
jour
Ce qu'on a bien fait!
Integration continue
Scrum
Planification
Gestion des tâches
Stabilité des équipes
Répondre aux besoins
Rétro & Amélioration
Visibilité
: Release Plan
(Enfin !)
Bilan très POSITIF
Ce qu'on aurait fait
autrement.
Coaching technique
Appris à la dure.
Différentes recettes
pour différents produits
Critères de Succès
les équipes
les gestionnaires
l'organisation
(PMO)
Impliquer
Formation
Sponsor
Gestionnaire de
projet
agile
Commencer petit - capitaliser
}
Attitude
Avantages attendus
Peur de cette visibilité.
Jamais fait ça.
Micro-management.
On va droit dans le mur.
Je sais quoi faire !
Laissez moi agir.
DOD trop lourd
Manager & Team :
même Règles !
Plus grand pouvoir de
négociation
Livrer
régulièrement
Les risques
Toujours re-expliquer l'agile
Le naturel n'est jamais loin
Rôle de PO encore difficile
Pareto
Daily
Pointer les tâches
Règles équipe
Burndown
Story meeting
Des post-its !

Équipes
DoD Progressif
Plan d'Action
Stabilité et colocation
Guilde Scrum Master/PO
Agile
pas
un
dogme
Leçons apprises

Transition Agile : approche globale
Focus équipe :
Focus organisation :
Product Owner
Gestion de Projet
Risques
Équipes
Budget
Estimé
Dates
Contrat
Qualité
Besoins
Ne pas oublier son expérience
LE
rôle scrum
Accompagnement !
Rôles
Objectifs communs
Règles
Équipe 101 :

PMO :
Accepter ou
subir
le changement?
S
Présentation du Release Plan
Engagement sur le Processus
T
$
S
Q
Sprint
Gap : Bug Fix, dette
Transition Agile Réussie en Grande Entreprise
Agile Tour Montréal
15 novembre 2014
Q1
Q2
Q3
Q4
Supporting the team
Critique the product
Business Facing
Technology Facing
Automated and manual
Manual
Tools
Automated
Unit tests
Component tests
Functional tests
Examples
Story tests
Prototypes
Simulations
Exploratory tests
Scenarios
Usability tests
User acceptance tests
Alpha/Beta
Performance tests
Load tests
Security tests
"ility" testing
Planning
As a team member ...
I want to do ...
To improve ...
Burndown
As a team member ...
I want to do ...
To improve ...
Release P.
As a team member ...
I want to do ...
To improve ...
SM - PO
As a team member ...
I want to do ...
To improve ...
Équipe
As a team member ...
I want to do ...
To improve ...
pas
une
méthodologie
Compromis
Sans RP, pas de crédibilité.
Pas de support du PMO
On en demande beaucoup.
Agile ?
Surveillance et maîtrise des risques :
Planification de la gestion des risques :
Identification des risques :
Analyse quantitative et qualitative :
Planification des réponses aux risques :
Backlog
de risques
Sprint 0
En
équipe
Revue
régulière
Quantitative :
Priorités
Qualitative :
Estimation

Priorité
du Backlog
Strategie de
test
Revue
, Intégration
Acceptance
Software vs Hardware
Full transcript