managing agile....

Agilité: régie ou forfait?

2012-01-26T17:25:00.002+01:00

Lors de mes pérégrinations au sein de mes différentsprojets et surtout, lors de discussions à bâton rompu avec les membres desassociations que j'ai pu rencontrer, le thème régie et forfait fait débat.

En effet, tout dépend de ce que vous vendez :

Une société de service voudra vendre desressources dans un projet agile :

o Dans cecas, elle vend des CV

o Et lepilotage du projet est fait par le client, même en ajoutant des closes hybridesavec un Scrum Master ou un coach.

o Cela neme satisfait pas vraiment, c’est de l’interim….

Une société de service voudra vendre unprojet agile :

o Dans cecas, elle fournit toutes les ressources pour aboutir à la réussite de ce projetet principalement un Product Owner et un Scrum Master.

o Elle peutcomposer avec des développeurs internes à la condition que ceux-ci soientdédiés à 100% au projet.

o A mesyeux, c’est déjà mieux.

Mais que dit l’ Agile Manifesto ?

J’ai relu les 12principes sous-jacents au manifeste et voici mes conclusions :

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

a. Régie : Pas concerné. La régie, c’est uneobligation de moyens et pas de résultat. Est-ce que la fourniture de moyensrépond à cette attente ?

b. Forfait : Obligation de résultat: livrer =satisfaire

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

a. Régie : Une ressource peut détecter une solutionde changement, mais celle-ci reste dans son silo fonctionnel.

b. Forfait : Le changement initie une modification dupérimètre du projet, une action, un ou plusieurs livrables.

3. Livrez fréquemment un logiciel opérationnel avecdes cycles de quelques semaines à quelques mois et une préférence pour les pluscourts.

a. Régie : Une ressource exécute une décision liée àla gestion des livrables. Elle aide, interagit, mais n'a pas de lead.

b. Forfait : Il s'agit d'un processus, d'une cadence ainsiqu'une validation de la qualité des livrables.

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

a. Régie : En tant que ressource, je contribue à l'effortde façon Co-productive.

b. Forfait : Le processus est le "comment" pourvalider le ou les livrables du projet.

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

a. Régie : Par principe, cette règle n'est pas liéeau contrat en "régie". Mais, elle est une règle de vie.

b. Forfait : Peut éventuellement apparentée auprocessus du projet. Le mode "forfait" donne la possibilité au client(sponsor) de revenir sur cette partie.

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

a. Régie : Règle de vie. Mais que ce passe-t-illorsque vous avez plusieurs prestataires dans la même équipe ?

b. Forfait : C’est la partie communication du ProcessProjet.

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

a. Régie : L'obligation de moyen n'oblige pas ledéveloppeur à fournir cela. C'est, dans ce cas, plutôt une mesuredéontologique.

b. Forfait : Il s'agit de la validation des livrables.

8. Ensemble, les commanditaires, les développeurs etles utilisateurs devraient être capables de maintenir indéfiniment un rythmeconstant.

a. Régie : Mais en fait, Oui/Non serait approprié.Oui pour l’équipe de développement. Non pour les autres acteurs du projet :MOA, Tests externes, BI, etc…

b. Forfait : Tous les développements disposent d'une date defin et une unité de mesure, même dans la recherche. Le forfait permet deconserver la main sur la gestion du temps.

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

a. Régie : Règle déontologique.

b. Forfait : Règle déontologique.

10. Lasimplicité – c’est-à-dire l’art de minimiser la quantité de travailinutile – est essentiel.

a. Régie : Ce n'est pas lié au mode régie enparticulier.

b. Forfait : Il s'agit avant tout de la réduction durisque d'échec et la sécurisation des livrables. Cependant trop de simpliciténuit à la créativité et réduit l’interactivité entre les membres des équipes autogéréesdans un système complexe auto-adaptatif (cf. Cynefin).

11. Lesmeilleures architectures, spécifications et conceptions émergent d'équipesauto organisées.

a. Régie : La régie lie un profil, un individu et pasune équipe.

b. Forfait ; Le mode au forfait favorise la vente d'unprojet. L'interaction du client sur l'organisation du projet est nulle. De cefait, l'autogestion peut être sécurisée.

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.

a. Régie : Travail d'équipe

b. Forfait : Amélioration continue = réduction desrisques.

Conclusion :

· L’Agilitéen mode régie est un non sens. Quelle différence y-a-t-il entre un développeuragile et un développeur catholique ? En régie, si vous envoyez un développeur agile chez un client « traditionnel »pensez-vous vraiment que celui-ci évangélisera tout le monde ? est-ce quec’est ce que l’on demande ?

· Cettedémonstration n’est pas parfaite car il y a toujours des cas particuliers.

· Il ya des versions alternatives qui vont bien à l’agilité, tels que les contrats desupport (tickets).

· Dans moncas, en tant que coach et Agile PMO, je ne fais que des contrats de support oudes contrats au forfait.

· Très souvent,les contrats au forfait s’enchaînent les uns aux autres chez un client. A chaquefois, nous définissons un objectif (Plan de Release, Project Backlog) etcelui-ci est géré en parallèle de façon collégiale avec le client.

Tu faisde l’agilité en régie? Nnoooonnn...

Le principede la régie est de fournir des profils pouvant intégrer un projet ou, plussouvent, une équipe existante. Dans un autre contexte, on appelle cela de l’interim.

Mais,bon... c’est le marché qui décide.

Product Owner Role explained...

2012-01-20T14:50:00.000+01:00

I've been cleaning my computer up and I had a look on past training programs. So I felt on a questionnaire that send to my customer a couple a years ago to customize the Product Owner Training.
After re-reading, I think that was no that stupid and I will use this approach again till now.

So, please readers, you can find below this questionnaire inspired by my Product Ownership gurus: Jeff Sutherland, Ken Schwaber, Alistair Cockburn, Scott Ambler, Jochen Krebs, Johanna Rothman, Roman Pichler, Anna Forss and my "Product Owner's Helpdesk" Community fellows on LinkedIn.

... and you can understand why I'm so often pissed of during Agile presentations....

theme	details	Estimation	Status
Introduction	Agile Values, Scrum Benefits and Origins
	Scrum and Change
	How would your life change with Scrum?
	Companies Using Scrum
Scrum Process and Roles	Scrum Flow
	Scrum Roles: Product Owner, Team, ScrumMaster
Product Owner	Product Owner Characteristics
	A Day in the Life of the Product Owner
	The Product Owner as the Voice of the Customer and Value Stream Manager
Requirements	Understanding the Customer
Vision	The Product Vision
	Benefits of the Product Vision
	The Vision in Action
	Desirable Qualities
	Techniques for Creating a Powerful Vision
	Creating Product Goals
Backlog	The Product Backlog
	Determining the Release Scope
	Stocking the Product Backlog
	Prioritizing the Product Backlog
	Refining the Product Backlog
	User Stories on the Product Backlog
	Case study and simulation
Stocking the product backlog	Failure of upfront thinking
	Emergent requirements
	User stories on the product backlog
	Augmenting the user stories
	User roles
	INVEST in your backlog
Visioning and The Product Vision	The Kano Model
	The Product Backlog
	Requirements in Scrum
	Product Backlog Characteristics
	Product Backlog Structure and Form
	Stocking the Backlog
	Grooming the Backlog
	Prioritising the Backlog
	Getting the Backlog Ready for Sprint Planning
	Progressive Requirements Decomposition
	Refining Requirements
	Collaborative Requirements Workshops
	User Stories on the Product Backlog
	Non-functional Requirements
Day one retrospective
Prioritizing the product backlog	The right size for prioritizing
	Prioritization Techniques: Kano analysis, Analytic Hierarchy Process
	Theme screening
	Theme scoring
	Relative weighting
	Priority poker
Responsibilities	Project responsibilities
	Developing the core
Release Management	Sustainable Pace
	The Project Levers
	Defining and Communicating Project Success
	Release Management Strategies
	The release planning meeting
	Estimating Product Backlog Items Using Story Points and Planning Poker
	Choosing the Sprint Length and Determining Velocity
	Fixed date planning
	Fixed scope planning
	Creating the Release Plan
	Tracking and Reporting the Project Progress
Sprint Management	Sprint Workflow and Characteristics
	Formulating Powerful Sprint Goals
	Sprint Planning, Daily Scrum, Sprint Review and Retrospective
	Understanding the Sprint Progress
	Getting to Done
Portfolio Management	The Planning Onion
	Why Portfolio Management Matters
	Levelling the Demand
	Portfolio Management Steps
	The Portfolio Bubble Chart
Large and Distributed Scrum Projects	Brook’s Law
	Organic Growth and Conway’s Law
	Master Product Backlog and the Product Owner Team
	Team Set-up
	Multi-team Planning and Coordination
	Shared Norms and Assets
	Distributed Scrum Project Tips

So, think now if this guy is just a proxy or customer's representative?

Extracts from the Semco’s Survival Manual for “Stoosiens”

2012-01-11T15:41:00.003+01:00

Last week-enda couple of Agile Thinkers have meet in Stoos (Switzerland) for a “GlobalManagement Warming” session.

Objective:

““Weare looking to energize organizations in ways that make them better for theorganizations themselves, better for the people doing the work, better forthose for whom the work is being done, and better for society as a whole. Andwe want to understand how we can speed it up!”

To supportthis activity, I will share some extracts from Ricardo Semler’s “Maverick”

“Semco’s Survival Manual”

Organization Chart	No formal chart	Only the led creates the leader
Hiring	The others of that unit have the opportunity to interview and evaluate ... before taking a decision	Even managers must have the “Go” from the team they want to lead.
Working hours	Flexible, each employee is responsible for track	Semco does its best to adapt to each person’s desires and needs.
Working environment	People must feel free to change and adapt it.	No rules.
Unions	Are important for workers protection. No persecution for union connected workers.	Always mutual respect and dialogue.
Strikes	Are normal as part of democracy.	Must always represent what people of the company think and feel.
Participation	Company’s philosophy built on participation and involvement.	“Don’t settle down. Give opinions, seek oportunities and advancement, always say what you think. Don’t be just one more person in the company”.
Evaluation by subordinates	Twice a year people of Semco become a questionnaire to evaluate what they think about their boss.
Factory committees	Those are guaranteed and need to defend people’s interests.	This is considered as healthy and necessary.
Authority	Hierarchy still exist.	No tolerance for: subordinates pressure, fear, insecurity, disrespect.
Job Security and Age	3 years seniority or age of 50 can”... only be missed after a long series of approvals...”	Semco has the will to increase people’s security.
Change	Are healthy and positive.	They are characteristics of the company.
Clothing and appearance	Are not a factor for hiring or promotion.	“Feel at ease – wear only your common sense.”
Private Life	Is sacred for the company. No interference.	HR department can help people on-demand.
Company loans	“The company loans money for unforseen situations.”
Pride	“Create pride by insuring the quality of everything you do.”
Communication	“People must strive to communicate with frankness and honesty.”
Informality	“don’t be shy or stick to formalities.”
Suggestions	No prizes for suggestions. Everyone must speak out and all opinions are welcome.
Women	Women discremination programs.	Women/Men equally treated.()*
Vacations	Are vital for people/s health and company’s welfare.

(*) my add-on

Inspiration Quote for the Guys at Stoos

2012-01-06T11:03:00.002+01:00

I got this picture this morning in my mailbox, and I thought that will be helpful for the Stoos hapening

Thinking about what can we do with managers in the emerging "agile" world is perhaps a perception defect: "... setting in the Jar and looking in the small one into the Jar... Matrioshka likely...".

Management is just a function and not a role

Have fun

-Pierre-

Nouvelle formation: « Animation de workshop pour la récolte des besoins »

2012-01-03T15:09:00.000+01:00

A la demande d'un de mes clients, j'ai développé une nouvelle formation: « Animation de workshop pour la récolte desbesoins ».

Celle-ci est dédiée principalement pour les Ergonomes (UX Designers, Psychologues) et les Analystes Métier (Business Analysts).

Il s'agit d'un package d'1 jour de formation + 1 jour de coaching

Descriptif de la Formation

La miseen place d’une approche centrée utilisateur nécessite l’utilisation et lacompréhension de techniques venant de pratiques agiles, tels que : lePlanning Dynamique, Requirement Workshops, la revue itérative et l’implication des utilisateurs ou de panels de personae.

Objectif:

Donner à chaque participant lacapacité de gérer des ateliers dynamiques de capture des besoins.

Contenu:

Principes de l'agilité et lagestion de la complexité (modèle Cynefin)
Idéation, Visioning et la créationd’User Stories
Principes et techniques depriorisations: user story, épic et thème
Création d'un Product Backlog etd'un Release Plan centré utilisateur
Le Process Scrum est le rôle desutilisateurs
Techniques de facilitations: Wide BandDelphi, Open Space, World Cafe, Serious Game
Études de cas et intégration dansune équipe agile existante

Process:

Formation en mode Learning-by-coaching en modeitératif (meth. Cône d'incertitude, Training from the back of the room)
Chaque thème est abordé d'un point de vue théorique suivi d'un exerciced'inspection, suivi d'une adaptation (transposition) au contexte spécifique de chacun des participants.

Bénéfices:

Clarification de l’approche
Support méthodologique et modèles
Support de cours
Outils et techniques applicables de suite

Vu la demande, je vais l'ajouter à mon catalogue de formation 2012.

Si cela vous intéresse, vous pouvez me contacter ici.

-Pierre-

My Inspiration gift for 2012

2012-01-01T15:47:00.000+01:00

I had read this anecdote in Ricardo Semler's book "Maverick" and picked it up from http://www.anecdote.com.au.

This is an anecdote, this a quote, this is the way how I'm looking forward.

Cathedral of Metz

On a foggy autumn day nearly 800 years ago a traveller happened upon a large group of workers adjacent to the River Avon. Despite being tardy for an important rendezvous curiosity convinced the traveller that he should inquire about their work. With a slight detour he moved toward the first of the three tradesmen and said “my dear fellow what is it that you are doing?” The man continued his work and grumbled, “I am cutting stones.” Realising that the mason did not wish to engage in a conversation the traveller moved toward the second of the three and repeated the question. To the traveller’s delight this time the man stopped his work, ever so briefly, and stated that he was a stonecutter. He then added “I came to Salisbury from the north to work but as soon as I earn ten quid I will return home.” The traveller thanked the second mason, wished him a safe journey home and began to head to the third of the trio.
When he reached the third worker he once again asked the original question. This time the worker paused, glanced at the traveller until they made eye contact and then looked skyward drawing the traveller’s eyes upward. The third mason replied, “I am a mason and I am building a cathedral.” He continued, “I have journeyed many miles to be part of the team that is constructing this magnificent cathedral. I have spent many months away from my family and I miss them dearly. However, I know how important Salisbury Cathedral will be one day and I know how many people will find sanctuary and solace here. I know this because the Bishop once told me his vision for this great place. He described how people would come from all parts to worship here. He also told that the Cathedral would not be completed in our days but that the future depends on our hard work.” He paused and then said, “So I am prepared to be away from my family because I know it is the right thing to do. I hope that one day my son will continue in my footsteps and perhaps even his son if need be.”

Girard J.P. and Lambert S (2007) “The Story of Knowledge: Writing Stories that Guide Organisations into the Future” The Electronic Journal of Knowledge Management Volume 5 Issue 2, pp 161-172.

I'll try to build a cathedral

-Pierre-

Le Contrat Agile open source.... une bonne mauvaise idée?

2011-12-01T23:21:00.001+01:00

Ce lundi, Xebia a communiqué sur la mise en ligne d'un contrat agile open source: cool, me suis-je dit.
Je lis le texte et je commence déjà à avoir des remontées gastriques.

Bon, d'accord... je suis un tantinet "emmerdeur", mais là.... c'est vraiment pas possible...

Mais qui raconte encore de telle énormités en France? mais qui sont les formateurs? .... le lac....le lac...

Je vous accorde, la majorité de la documentation est en anglais... mais qu'en même!

En clair, voilà ce qui coince:

en rouge, mes ajouts dans la version originale

1. Un point de détail:

Le contrat fait 52 pages: je vous met au défi d'avoir une signature sous 48 heures...

2. et des énormités....

mais où est passé l'utilisateur ou la mise à disposition d'un panel d'utilisateur? Faire du Scrum avec des User Stories sans les Users ont fait de l'analyse waterfall? Scrum est une démarche centrée utilisateur, si l'on ne comprend pas cela, il reste XP
en vrac:

Le Product Owner est le membre du personnel du client...l'interlocuteur privilégié... a disposition de l'équipe de développement: les bras m'en tombent.
la Sprint Review est une démo (tiens donc!!!) avec l'équipe de développement et le Product Owner (cf le client)
Le changement de périmètre est possible et passé aucrible de l’analyse de valeur et de l’analyse de risque. L’impact sur leplanning est mesuré avec le Prestataire (Le PRESTATAIRE), et un arbitrageéclairé peut être effectué par le Client et le Prestataire. A minima, cettemodification s’opère lors de la revue de Sprint (Sprint Review). Ce changementde périmètre ne devra pas impacter négativement la Vision du produit, véritablefil conducteur du projet.
leProduct Owner(Directeur de Produit), qui possède l'expertise fonctionnelle et est à même deréaliser les arbitrages nécessaires à la priorisation des développements. Sonrôle est absolument essentiel, et son respect des règles du jeu est la pierreangulaire du succès d'un projet agile. Le Product Owner est un membre de l’équipe travaillant en étroite etpermanente relation avec le ou les représentants du Client Sa présence au sein del’Equipe permet d’accroître l’efficacité du projet et de prévenir les risques d’échec.

Je vais m'arrêter là. Si cela vous interesse, la version révisée est dispo ici.

Vous voulez en débattre: je vous invite à me joindre lors de l'Agile Tour de Paris, Mardi 6 décembre, lors de ma session sur "Product Owner's is time to wake up!" - le débat sera public pendant ma présentation.

Pierre

Craig Larman a transmis un lien vers une nouvelle version de contractualisation agile (ici).

Quelles questions doit-on se poser pour mettre en place l'agilité dans votre organisation?

2011-10-31T15:26:00.000+01:00

Mettre en place l'agilité peut se résumer par le kanji ci-dessus qui signifie SHU HA RI.

SHU: protéger, obéir, apprendre les fondamentaux, les techniques

HA: détacher, digresser, rompre avec la tradition, le détachement des illusions de soi.

RI: prendre congé, séparer, transcender le physique, fluidifier.

SHUHARI est en quelque sorte le processus de haut niveau pour instancier une transition vers plus d'agilité.

1. Pourquoi l'agilité?

D'accord, l'agilité est tendance à l'heure actuelle. Mais dans tous les cas, posez-vous la question pourquoi voulez-vous, pourquoi votre organisation veut-elle ou doit-elle devenir agile? Toutes les raisons sont bonnes.
Par exemple:

Nous souhaitons devenir agile parce que Gartner Research a défini l'agilité comme étant une des trois mutations dans les dix prochaines années avec la gestion des applications et la SOA (architecture orientée services).
Nous souhaitons améliorer notre relation client.
Nous souhaitons livrer plus rapidement.
Notre organisation (PMO) a une méthodologie en décalage avec les accointances des ingénieurs nouvellement recrutés: par ex., Lean Six Sigma vs Scrum.
Nous n'avons pas de maturité dans la gestion de projet.
Nous pensons que l'agilité peut soutenir notre démarche RSE .
etc...

Il y a autant de raisons qu'il y a d'organisation. Dans tous les cas, pensez à bien clarifier les raisons pour lesquelles vous souhaiter démarrer ce changement. En langage Scrum, nous clarifions la Vision (True North en Lean).

2. Les questions pas vraiment "drôles" à se poser?

La mise en place de l’agilité n’est pas une alternative au découpage du projet en phase (WBS) mais bien la mise en place d’interactions entre les clients/les utilisateurs/le management et l’équipe de développement.

Une agilité au sein d’une MOA n’a de valeur que si ce changement est conduit avec le support de la PMO (Program Management Office) [si vous en disposez une bien sûr].

La proposition de l’agilité est d’apporter de la valeur à votre organisation. Pour parvenir à cela différents objectifs sont à prendre en compte :

La MOA estime que les fonctionnalités, la technique est le domaine du Développement
Un pool d’analyse des risques existe-t-il ?
Comment sont gérées les exigences ?
Disposez-vous d’ergonomes (UX Designers) ?
Qui contrôle le portefeuille de projets ?
Disposez-vous des mesures de temps et de gestion de la valeur acquise (SPI, CPI) ?
Comment mesurez-vous la qualité de vos réalisations ?
Visualisez-vous le workflow du process de production ?
Est-ce que la BPMO (Business Process Management Office) contraint ou propose ?
Avez-vous clarifié vos standards ?
Êtes-vous seul ou accompagné ?

3. Les ultimes points à vérifier

L’Agilité engendre un changement dans l’organisation de votre département. Avez-vous un plan de changement ?

Avoir Backlog de Changement permet de fixer les modifications organisationnelles et met en lumière les points d'amélioration: de mon côté, j'utilise un plan de changement reprennant les principes d'un Value Stream Map pour identifier Muri, Mura et Muda.

4. Conclusion

Si vous avez répondu à toutes ces questions vous saurez comment aborder votre projet.

Quelques éléments clefs qui vous aideront peut-être:

MOA, MOE, Dévelopement ne sont que des rôles dans une organisation "systémique".
Utilisez des ressources externes pour vous faire aider ponctuellement: celles-ci vous apporteront un regard neuf.
Diversifiez vos ressources.
Changez votre façon de penser

Scrum Guide 2011, la version française non-officielle

2011-10-19T15:20:00.000+02:00

Voici la version téléchargeable de ma traduction du Scrum Guide.

M'étant aperçu que la lecture de mon post d'il y a quelques jours était un tantinet "lourd", je me permets de vous le transmettre en version pdf avec quelques corrections de français.

Scrum Guide 2011 - non officielle

View more documents from Pierre NEIS.

SCRUM 2.0: UNE ÉVOLUTION DE SCRUM?

2011-10-17T15:47:00.000+02:00

En juillet 2011, Ken Schwaber et Jeff Sutherland ont édité une nouvelle version du Scrum Guide. Ce “Scrum Body of Kowledge” a l’air anodin, mais de mon point de vue, celu-ci annonce de profond changement dans le “framework”.

Lors de la sortie du Scrum Guide, la réaction a été vive et les débats sulfureux dans les listes de discussions. Scrum est en amélioration permanente, pourquoi cette version serait-elle différente des autres?

Le contexte est tendu dans le milieu des coaches et des trainers certifiés par la Scrum Alliance: abandon des certifications par Tobias Mayer et Boris Gloger; luttes entre Scrum Alliance et Scrum.org... en fin, de l’humain.. quoi!!! Stuckmann dirait que nous sommes étions en phase “storming”,

Ce Scrum Guide a été co-écrit par Schwaber et Sutherland, nos deux somités avaient déjà la capacité de calmer les esprits les plus échaufés (et il y a du lourd là dessous). Donc, cet écrit n’est pas anodin. Stuckmann dirait que nous abordons la phase “norming”.

M’étant engagé lors de l’Agile Tour de dispenser des Master Classes sur Scrum 2.0 et, après avoir revu mes formations Scrum et les ayant testé avec mes clients (les pauvres!), je me suis permis de faire une traduction non-officielle de ce Scrum Guide 2011 et je vous invite à la découvrir ci-dessous mon incrément de mon inspect-and-adapt:

Le Scrum Guide, Les régles du Jeu (adaptation P.Neis)

Parmi les milliers de personnes qui ont contribué à Scrum, nous devrions distinguer ceux qui ont contribué à ses dix premières années. D’abord, il y a eu Jeff Sutherland travaillant avec Jeff McKenna, et Ken Schwaber travaillant avec Mike Smith et Chris Martin.

Beaucoup d'autres ont contribué les années suivantes et, sans leur aide Scrum ne se serait pas affiné tel qu‘il est aujourd'hui.

David Starr a fourni des informations clés et des compétences rédactionnelles dans la formulation de cette version du Guide de Scrum.

Historique

Au début, Ken Schwaber et Jeff Sutherland ont co-présenté Scrum à la conférence OOPSLA en 1995.

Cette présentation était essentiellement documentée par l'apprentissage de la mise en application de Scrum que Ken et Jeff ont eu au cours des quelques années précédentes.

L’histoire de Scrum est déjà considérée comme longue.

Pour honorer les premiers endroits où il a été testé et amélioré, nous remercions Individuals Inc, Fidelity Investments, et IDX (maintenant GE Medical).

Les Révisions

L’édition du Scrum Guide de Juillet 2011 est différente de son prédécesseur l’édition de février 2010.

En particulier, nous avons tenté d'enlever des techniques ou des bonnes pratiques du cœur de Scrum.

Celles-ci varient en fonction des circonstances. Nous démarrerons un recueil de "Best Practices" pour offrir certaines de nos expériences ultérieurement.

Le Scrum Guide documente Scrum tel qu’il a été développé et entretenu pendant vingt ans et + par Jeff Sutherland et Ken Schwaber.

D'autres sources vous fourniront des modèles, des processus, et des idées dont les pratiques, les facilitations et les outils qui complètent le cadre Scrum.

Cela pour optimiser la productivité, la valeur, la créativité et la fierté.

Les notes de version couvrant les différences entre celle-ci et la version de Février 2010 sera publié ultérieurement, y compris des discussions sur

1. Release Planning

2. Release Burndown

3. Sprint Backlog

4. Product et Sprint Backlog Burndown

5. L’engagement est maintenant l’estimation

6. Team (to Development Team)

7. Pigs and Chickens … le savoir de Scrum

8. Ordonné au lieu de priorisé

Objectif du Scrum Guide

Scrum est un cadre pour l'élaboration et le maintien des produits complexes.

Ce guide contient la définition de Scrum.

Cette définition comprend les rôles Scrum, les événements, les artefacts et les règles qui les unissent.

Ken Schwaber et Jeff Sutherland ont développés Scrum; le Scrum Guide est écrit et fournis par eux.

Ensemble, ils se tiennent derrière le Scrum Guide.

Aperçu de Scrum

Scrum (nm): Un cadre dans lequel les gens peuvent aborder des problèmes complexes adaptatifs, tandis que productivité et créativité offrent des produits de la valeur la plus élevée possible.

Scrum est:

· Léger

· Simple à comprendre

· Extrêmement difficile à maîtriser

Scrum est un cadre de processus qui a été utilisé pour gérer le développement de produits complexes depuis le début des années 1990.

Scrum n'est pas un processus ou une technique pour construire des produits; c'est plutôt un cadre dans lequel vous pouvez utiliser divers procédés et techniques.

Scrum met en évidence l'efficacité relative de la gestion de vos produits et des pratiques de développement de sorte que vous pouvez améliorer.

Le cadre de Scrum

Le cadre de Scrum se compose des Scrum Teams et de leurs rôles associés, des événements, des artefacts et des règles.

Chaque composant dans ce cadre sert un but spécifique et est essentiel à la réussite et de l’usage de Scrum.

Des stratégies spécifiques pour l'utilisation du cadre Scrum varient et sont décrits par ailleurs.

Les règles de Scrum lient les événements, les rôles et les artefacts, qui régissent les relations et les interactions entre eux.

Les règles de Scrum sont décrites dans le corps du présent document.

Scrum, la théorie

Scrum est fondé sur la théorie de contrôle des processus empiriques, ou l'empirisme.

L'empirisme affirme que la connaissance vient de l'expérience et de la prise de décision basée sur ce qui est connu.

Scrum utilise une approche itérative et incrémentale pour optimiser la prévisibilité et la maîtrise des risques.

Trois piliers supportent chaque implémentation du contrôle des processus empiriques : la transparence, l’inspection et l’adaptation.

La transparence,

Les aspects importants du processus doivent être visibles pour les responsables du résultat.

La transparence exige que ces aspects soient définis par une norme commune de sorte que les observateurs partagent une compréhension commune de ce qui est vu.

Par exemple :

Une langue commune se référant au processus doit être partagée entre tous les participants, et,
Une définition commune du "Done" doit être partagée par ceux qui effectuent le travail et ceux qui acceptent le produit du travail.

L’inspection,

Les utilisateurs de Scrum doivent inspecter fréquemment.

Les Artefacts de Scrum mesurent le progrès vers un objectif de détecter les écarts indésirables, leur inspection ne doit pas être si fréquente de sorte que l'inspection soit la façon d’agir.

Les inspections sont plus bénéfiques quand elles sont diligentées par des inspecteurs qualifiés sur le point de travail.

Et l’adaptation

Si l'inspecteur détermine que un ou plusieurs aspects d'un processus s'écarte des limites acceptables, et que le produit résultant sera inacceptable, le processus ou le matériel en cours de traitement doit être ajusté.

Un ajustement doit être effectué dès que possible afin de minimiser l'écart d'autres.

Scrum prescrit quatre occasions formelles pour l'inspection et l'adaptation, tel que décrit dans la section Événements Scrum de ce document

Sprint Planning Meeting
Daily Scrum
Sprint Review Meeting
Sprint Rétrospective

Scrum

Scrum est un cadre structuré pour soutenir le développement de produits complexes.

Scrum se compose d'équipes Scrum et leurs rôles associés, des événements, des artefacts et des règles.

Chaque composant dans le cadre sert un but spécifique et est essentiel à la réussite et l’usage de Scrum.

Les règles de Scrum lient les événements, les rôles et les artefacts, qui régissent les relations et les interactions entre eux.

Les règles de Scrum sont décrites tout au long du présent document.

La Scrum Team

La Scrum Team est constituée d’un Product Owner, d’une Development Team, et d’un Scrum Master.

Les Scrum Teams sont autogérées et inter-fonctionnelles (transverses).

Les équipes autogérées choisissent la meilleure façon d'accomplir leur travail, plutôt que d'être dirigées par d'autres en dehors de l'équipe.

Les Équipes inter-fonctionnelles ont toutes les compétences nécessaires pour accomplir le travail sans dépendre des autres ne faisant pas partie de l'équipe.

Le modèle d'équipe dans Scrum est conçu pour optimiser la flexibilité, la créativité et la productivité.

Les Scrum Teams livrent des produits de façon itérative et incrémentale, en maximisant les possibilités de feedback.

Les livraisons incrémentales de produit "Done" assurent qu’une version potentiellement utile du produit qui fonctionne est toujours disponible.

Le Product Owner

Le Product Owner est responsable pour maximiser la valeur du produit et le travail de la Development Team.

Comment cela se fait peut varier considérablement selon les organisations, les Scrum Teams, et les individus.

Le Product Owner est la seule personne responsable de la gestion du Product Backlog.

La gestion du Product Backlog comprend:

Exprimer clairement les éléments du Product Backlog;
Ordonner les éléments du Product Backlog pour mieux atteindre les objectifs et les missions ;
Assurer la valeur du travail réalisée par la Development Team;
Assurer que le Product Backlog, est transparent et clair pour tous, et montrer ce sur quoi la Scrum Team va travailler la prochaine fois et,
Assurer que la Development Team comprend les éléments dans le Product Backlog au niveau nécessaire.

Le Product Owner peut faire le travail ci-dessus, ou avoir la Development Team qui le fait. Toutefois, le Product Owner demeure responsable.

Le Product Owner est une personne, pas un comité.

Le Product Owner peut représenter les désirs d'un comité dans le Product Backlog, mais ceux qui veulent changer la priorité d'un élément de Backlog doivent convaincre le Product Owner.

Pour que Product Owner réussisse, toute l’organisation doit respecter ses décisions.

Les décisions du Product Owner sont visibles dans le contenu et l'ordonnancement du Product Backlog.

Personne n'est autorisé à dire à la Development Team de travailler à partir d'un ensemble d’exigences différentes, et la Development Team n'est pas autorisée à agir sur ce que quelqu'un d'autre dit.

La Development Team

La Development Team se compose de professionnels qui font le travail de fournir un incrément potentiellement libérable de produit "Done" à la fin de chaque Sprint.

Seuls les membres de la Development Team créent l'incrément.

Les Development Teams sont structurées et habilitées par l'organisation pour organiser et gérer leur propre travail.

La synergie résultante optimise l'efficacité globale de la Development Team et son efficacité.

Les Development Teams ont les caractéristiques suivantes:

Elles sont auto-organisées. Personne (pas même le Scrum Master) dit à la Development Team la façon de tourner Product Backlog en incréments de fonctionnalités potentiellement libérable.

Les Development Teams sont transverses, avec toutes les compétences nécessaires à l’équipe pour créer un incrément du produit.

Scrum ne reconnaît pas les titres des membres de la Development Team autres que développeur, quel que soit le travail effectué par la personne, il n'y a aucune exception à cette règle.

Les membres individuels de la Development Team peuvent avoir des compétences spécialisées et expertises domaine, mais la responsabilité appartient à la Development Team dans son ensemble et, la Development Team ne contient pas de sous-équipes dédiées à des domaines particuliers comme les tests ou des analyses fonctionnelles.

La taille optimale de la Development Taille de la Development Team

Team est assez petite pour rester agile et assez grande pour terminer un travail important.

Moins de trois membres diminuent l'interaction et des résultats en gains de productivité moindre. Les petites Development Teams peuvent rencontrer des contraintes de compétences pendant le Sprint, entrainant l’incapacité de la Development Team de délivrer un incrément potentiellement livrable.

Avec plus de neuf membres cela nécessite trop de coordination.

De grandes Development Teams génèrent trop de complexité à gérer pour un processus empirique.

Les rôles de Product Owner et de Scrum Master ne sont pas inclus dans ce décompte sauf s’ils contribuent dans l’exécution des travaux du Sprint Backlog.

Le Scrum Master

Le Scrum Master est chargé de veiller à ce que Scrum soit compris et adopté.

Le Scrum Master le fait en veillant à ce que la Scrum Team adhère à la théorie Scrum, ses pratiques et ses règles.

Le Scrum Master est un servant-leader pour la Scrum Team.

Le Scrum Master aide ceux qui se trouvent à l’extérieur de la Scrum Team à comprendre lesquelles de leurs interactions aident et lesquelles n’aident pas.

Le Scrum Master permet à chacun de modifier ces interactions afin de maximiser la valeur créée par l'équipe Scrum.

Le Scrum Master pour le Product Owner

Le Scrum Master sert le Product Owner de plusieurs manières, y compris

Trouver des techniques pour la gestion efficace du Product Backlog ;
Communiquer clairement la Vision, les objectifs et les éléments du Product Backlog à la Development Team;
Éduquer la Development Team pour créer des éléments clairs et concis du Product Backlog;
Comprendre la planification des produits à long terme dans un environnement empiriques;
Comprendre et pratiquer l'agilité et,
Faciliter les évènements Scrum comme demandés ou nécessaires.

Le Scrum Master pour la Development Team

Le Scrum Master sert la Development Team de plusieurs façons, y compris

Coaching la Development Team en autogestion et transversalité;
Éduquer et leader la Development Team pour créer des produits de forte valeur;
Supprimer les obstacles au progrès de la Development Team;
Faciliter les évènements Scrum comme demandés ou nécessaires et,
Coacher la Development Team dans des environnements organisationnels dans lesquels Scrum n'est pas encore totalement adopté et compris.

Le Scrum Master pour l’Organisation

Le Scrum Master sert l’Organisation de plusieurs façons, y compris

Diriger et coacher l'organisation dans son adoption de Scrum;
Planifier des implémentations Scrum au sein de l'organisation;
Aider les employés et les intervenants à comprendre et à adopter Scrum et le développement de produits empirique;
Provoquer des changements qui augmentent la productivité de l'équipe Scrum et,
Travailler avec d'autres Scrum Masters pour accroître l'efficacité de l'application de Scrum dans l'organisation.

Les évènements Scrum

Des événements prescrits sont utilisés dans Scrum afin de créer la régularité et de minimiser le besoin pour les réunions pas définies dans Scrum.

Scrum utilise des évènements time-boxés, de telle sorte que chaque événement a une durée maximale.

Cela garantit une quantité appropriée de temps consacrée à la planification, sans permettre des déchets dans le processus de planification.

Autre que le sprint lui-même, qui est un conteneur pour tous les autres événements, chaque événement dans Scrum est une opportunité d'inspecter et d'adapter quelque chose.

Ces événements sont spécifiquement conçus pour permettre la transparence critique et l'inspection.

L'omission d'inclure un de ces événements induit la réduction de la transparence et une occasion perdue pour inspecter et d'adapter.

Le Sprint

Le cœur de Scrum est un sprint, une time-box d'un mois ou moins au cours de laquelle un incrément produit « Done", utilisable et potentiellement livrable est créé.

Les Sprints ont une durée consistante en adéquation avec un effort de développement.

Un nouveau Sprint commence immédiatement après la conclusion du précédent Sprint.

Les Sprints contiennent et se composent du Sprint Planning, des Daily Scrums, le travail de développement, de la Sprint Review, et la Sprint Rétrospective.

Pendant le Sprint

Aucune modification n'est apportée qui pourraient affecter l'objectif de Sprint.

La composition de la Development Team et les objectifs de qualité restent constants et, le cadre peut être clarifié et renégocié entre le Product Owner et la Development Team au fur et à mesure des connaissances acquises.

Chaque Sprint peut être considéré comme un projet avec un horizon d'un mois.

Comme les projets, les sprints sont utilisés pour accomplir quelque chose, chaque Sprint a une définition de ce qui doit être construit, un plan de conception flexible qui guidera sa construction, le travail, et le produit résultant.

Les Sprints sont limités à un mois.

Lorsque l'horizon d'un Sprint est trop long, la définition de ce qui se construit peut changer, la complexité peut augmenter, et le risque peut augmenter.

Les Sprints permettent la prévisibilité en assurant l'inspection et l'adaptation de progrès vers un objectif d’au moins tous les mois du calendrier.

Les Sprints limitent aussi le risque financier d'un mois calendaire.

Annulation d’un Sprint

Un Sprint peut être annulé avant la fin de la Sprint time-box.

Seul le Product Owner a le pouvoir d'annuler le sprint, même si il ou elle peut le faire sous l'influence des parties prenantes, la Development Team, ou le Scrum Master.

Un Sprint serait annulé si l’objectif de Sprint devient obsolète.

Cela peut se produire si l'entreprise change de direction ou s’il y a changement des conditions du marché ou la technologie.

En général, un Sprint devrait être annulé s’il n'a plus de sens étant donné les circonstances.

Mais, en raison de la courte durée des sprints, l'annulation fait rarement sens.

Quand un sprint est annulé, tout items de Product Backlog complets et « Done » sont passés en revue.

Si une partie du travail est potentiellement livrable, le Product Owner l’accepte généralement.

Tous les items incomplets du Product Backlog sont ré-estimés et remis dans le Product Backlog. Le travail effectué sur les items se déprécie rapidement et ceux-ci doivent être fréquemment ré-estimés.

Les annulations de Sprint consomment des ressources, étant donné que chacun doit se regrouper dans une autre Sprint Planning Meeting pour lancer un autre Sprint.

Les annulations de Sprint sont souvent traumatisantes pour la Scrum Team, et donc très rares.

Sprint Planning Meeting

Les travaux à effectuer dans le Sprint sont prévus au Sprint Planning Meeting.

Ce plan est créé avec la collaboration de toute la Scrum Team.

Le Sprint Planning Meeting est time-boxé à huit heures pour un sprint d'un mois.

Pour les Sprints courts, l'événement est proportionnellement plus court.
Par ex., des Sprints de 2 semaines ont des Sprint Planning Meetings de 4 heures.

Le Sprint Planning Meeting se compose de deux parties, chacune étant une fois la moitié de la durée de la time-box du Sprint Planning Meeting.

Les deux parties du Sprint Planning Meeting répondent aux questions suivantes, respectivement :

Qu’est-ce qui sera livré dans l’incrément résultant su Sprint?
Quel sera le travail nécessaire pour que l’incrément soit réalisé?

Part 1: Qu’est-ce qui sera livré dans l’incrément résultant su Sprint?

Dans cette partie, la Development Team travaille pour prévoir les fonctionnalités qui seront développées au cours du Sprint.

Le Product Owner présente les items du Product Backlog ordonnés à la Development Team et toute la Scrum Team collabore à la compréhension du travail du Sprint.

L’input de cette réunion est le Product Backlog, le dernier incrément produit, la capacité projetée de la Development Team au cours du Sprint, et le rendement passé de la Development Team.

Le nombre d’items sélectionnés à partir du Product Backlog pour le Sprint est à la seule appréciation de la Development Team.

Seule la Development Team peut évaluer ce qu'elle peut accomplir au cours des prochains Sprint.

Après, la Development Team prévoit les items du Product Backlog qu'elle livrera dans le Sprint, la Scrum Team conçoit un objectif de Sprint.

L'objectif de Sprint est un objectif qui sera atteint dans le Sprint grâce à la mise en œuvre du Product Backlog, il fournit des conseils à la Development Team, sur quoi elle construit de l'incrément.

Part 2: Quel sera le travail nécessaire pour que l’incrément soit réalisé?

Après avoir choisi le travail du Sprint, la Development Team décide comment elle va transformer cette fonctionnalité en un incrément de produit "Done" pendant le Sprint.

Les items de Product Backlog sélectionnés pour ce Sprint ainsi que le plan pour les livrer est appelé le Sprint Backlog,

La Development Team commence généralement par la conception du système et le travail nécessaire pour convertir le Product Backlog dans un incrément de produit qui fonctionne.

Le travail peut être de taille variable, ou d'effort estimé.

Cependant, assez de travail est prévu lors du Sprint Planning Meeting pour la Development Team pour prévoir ce qu'elle croit pouvoir faire dans le prochain Sprint.

Les travaux prévus par la Development Team pour les premiers jours du Sprint sont décomposés en unités d'une journée ou moins d'ici la fin de cette réunion.

La Development Team s'auto-organise pour entreprendre les travaux dans le Sprint Backlog, à la fois lors du Sprint Planning Meeting et au besoin tout au long du Sprint.

Le Product Owner peut être présent lors de la deuxième partie du Sprint Planning Meeting pour clarifier les éléments sélectionnés du Product Backlog et de contribuer à faire des compromis.

Si la Development Team détermine qu'elle a trop de travail ou trop peu, elle peut renégocier les items du Sprint Backlog avec le Product Owner.

La Development Team peut également inviter d'autres personnes à y assister afin de fournir des conseils techniques ou de domaine.

À la fin du Sprint Planning Meeting, la Development Team devrait être en mesure d'expliquer au Product Owner et au Scrum Master comment elle entend travailler en équipe autogérée pour atteindre l'objectif de Sprint et de créer l'incrément prévu.

L’objectif de Sprint

L'objectif de Sprint donne à la Development Team une certaine souplesse quant à la fonctionnalité implémentée dans le Sprint.

Tout au long de son travail, la Development Team garde cet objectif en tête.

Afin de satisfaire l'objectif de Sprint, elle implémente la fonctionnalité et la technologie.

Si le travail se révèle être différent de ce que la Development Team avait prévu, elle collabore avec le Product Owner pour négocier le scope du Sprint Backlog dans le Sprint.

L'objectif de Sprint peut être un jalon dans l'objectif plus général de la Product Roadmap.

Daily Scrum

Le Daily Scrum est une time-box de 15 minutes pour la Development Team pour synchroniser les activités et créer un plan pour les prochaines 24 heures.

Ceci est fait en inspectant les travaux depuis de dernier Daily Scrum et la prévision de travail qui pourrait être fait avant le prochain.

Le Daily Scrum est tenu au même moment et au même endroit chaque jour afin de réduire la complexité.

Pendant la réunion, chaque membre de la Development Team explique

Qu'est-ce qui a été accompli depuis la dernière réunion?
Quelles mesures seront prises avant la prochaine réunion?
Quels sont les obstacles sur le chemin?

La Development Team utilise le Daily Scrum pour évaluer les progrès vers l‘objectif de Sprint et d'évaluer comment les progrès sont orientés vers la réalisation des travaux dans le Sprint Backlog.

Le Daily Scrum optimise la probabilité que la Development Team va atteindre l'objectif du Sprint.

La Development Team se retrouve souvent immédiatement après le Daily Scrum pour re-planifier le Sprint Backlog.

Chaque jour, la Development Team devrait être en mesure d'expliquer au Product Owner et au Scrum Master comment elle entend travailler ensemble comme une équipe autogérée pour atteindre l'objectif et de créer l'incrément prévu dans Sprint Backlog.

Le Scrum Master s'assure que la Development Team a tenu la réunion, mais la Development Team est chargée de mener le Daily Meeting.

Le Scrum Master enseigne à la Development Team de maintenir un Daily Scrum dans une time-box de 15-minutes.

Le Scrum Master applique la règle selon laquelle seuls les membres de la Development Team participent au Daily Scrum Meeting.

Le Daily Scrum n'est pas un point de situation, mais il est fait pour les personnes transformant les items du Product Backlog en un incrément.

Les Daily Scrums permettent d’améliorer la communication, d'éliminer les autres réunions, d'identifier et d'éliminer les obstacles au développement, à souligner et à promouvoir la prise de décision rapide, et améliorer le niveau de l'équipe de développement de la connaissance du projet.

C’est une réunion clé d’inspection et d’adaptation.

La Sprint Review

Un Sprint Review Meeting est tenu à la fin du Sprint pour inspecter l'incrément et adapter le Product Backlog si nécessaire.

Pendant le Sprint Review, la Scrum Team et les intervenants collaborent sur ce qui s’est fait dans le Sprint.

Basé sur cela, et tout changement du Product Backlog pendant le Sprint, les participants collaborent sur les prochaines choses qui pourraient être développées.

Ceci est une réunion informelle et la présentation de l'incrément qui est destinée à susciter des réactions et de favoriser la collaboration.

Ceci est une réunion time-boxée de 4 heures pour un Sprint d’un mois.

Proportionnellement moins de temps est alloué pour des Sprints courts.
Par exemple: un Sprint de deux semaines a une time-box de quatre heures pour la Sprint Review.

La Sprint Review comprend les éléments suivants

Le Product Owner identifie ce qui a été "Done" et ce qui n'a pas été «Done»;
la Development Team explique ce qui s'est bien passé pendant le Sprint, quels problèmes elle a été confrontée, et comment ces problèmes ont été résolus;
la Development Team démontre le travail «Done» et répond aux questions sur incrément;
le Product Owner discute du Product Backlog tel qu'il est.
Il ou elle projette des dates prévisionnelles d’achèvement en fonction des progrès à ce jour, et,
l'ensemble du groupe collabore sur ce qui est à faire ensuite, de sorte que la Sprint Review fournit une contribution précieuse aux futurs Sprint Planning Meetings.

Le résultat de la Sprint Review est un Product Backlog révisé qui définit les éléments probables du Product Backlog pour le prochain Sprint.

Le Product Backlog peut également être ajusté pour répondre à l'ensemble des nouvelles opportunités.

La Sprint Rétrospective

La rétrospective Sprint est une occasion pour la Scrum Team de s’inspecter et de créer un plan d'améliorations pour être promulguée au cours du Sprint suivant.

La Sprint Rétrospective survient après la Sprint Review et avant le Sprint Planning Meeting suivant.

C’est une time-box de trois heures pour un Sprint d’un mois

Proportionnellement moins de temps est alloué pour des Sprints courts.

Le but de la Sprint Rétrospective est de

Inspecter la manière dont le dernier Sprint s’est déroulé eut égard aux personnes, aux relations, aux processus et aux outils;
Identifier et ordonner les items majeurs qui ont bien fonctionnés ainsi que les améliorations potentielles, et,
La Création d'un plan de mise en œuvre des améliorations à la façon dont l'équipe Scrum fait son travail.

Le Scrum Master encourage la Scrum Team à s’améliorer dans le cadre du processus Scrum, son processus de développement et des pratiques pour le rendre plus efficace et agréable lors du prochain Sprint.

Lors de chaque Sprint Rétrospective, la Scrum Team planifie les moyens pour accroître la qualité des produits, en adaptant la définition de "Done", le cas échéant.

À la fin de la Sprint Rétrospective, la Scrum Team devrait avoir identifié les améliorations qu’elle mettra en œuvre dans le prochain Sprint.

La mise en œuvre de ces améliorations dans le prochain Sprint est l'adaptation et l'inspection de la Scrum Team elle-même.

Bien que des améliorations puissent être mises en œuvre à tout moment, la Sprint Rétrospective fournit un événement dédié axée sur l'inspection et l'adaptation.

Les Scrum Artefacts

Les Scrum artefacts représentent le travail ou la valeur de diverses façons qui sont utiles en matière de transparence et des possibilités de contrôle et d'adaptation.

Les artefacts définis par Scrum sont spécifiquement conçus pour maximiser la transparence de l'information, clé nécessaire pour assurer que les Scrum Teams ont réussi à fournir un incrément « Done ».

Le Product Backlog

Le Product Backlog est une liste ordonnée de tout ce qui pourrait être nécessaire dans le produit et est la source unique d'exigences pour toutes les modifications à apporter au produit.

Le Product Owner est responsable du Product Backlog, y compris de son contenu, de sa disponibilité et de son ordonnancement.

Un Product Backlog n’est jamais complet.

Les premiers développements n'établissent que les exigences initialement connues et les mieux comprises.

Le Product Backlog évolue comme le produit et l'environnement dans lequel il sera utilisé évolue.

Le Product Backlog est dynamique, il change constamment pour identifier ce que le produit a besoin pour être approprié, compétitif et utile.

Tant qu'un produit existe, un Product Backlog existe également.

Le Product Backlog répertorie toutes les caractéristiques, fonctions, besoins, des améliorations et des corrections qui constituent les changements à apporter au produit dans les versions futures.

Les items de Product Backlog ont les attributs d’une description, d’un ordre, et d’une estimation.

Le Product Backlog est souvent ordonné par valeur, risque, priorité et nécessité.

Les items de Product Backlog de haute priorité entraînement des activités de développement immédiates.

Plus l'ordre est élevé, plus un élément Product Backlog a été considéré, et plus il existe un consensus au sujet et sa valeur.

Les items de Product Backlog supérieurement ordonnés sont plus clairs et plus détaillés que ceux inférieurement ordonnés.

Des estimations plus précises sont faites sur la base de plus de clarté et augmenté de détails; plus bas l'ordre, le moins de détails il a.

Les items de Product Backlog qui vont occuper la Development Team pour le Sprint à venir sont à « grain fin », ayant été décomposés de sorte que tout élément peut être «Done» dans la time-box du Sprint.

Les items de Product Backlog qui peuvent être "Done" par la Development Team au sein d'un Sprint sont réputés « Ready » ou "actionnable" pour la sélection lors du Sprint Planning Meeting

Tant que le produit est utilisé et gagne de la valeur, et le marché fournit un feedback, le Product Backlog devient une liste plus grande et plus exhaustive.

Les exigences ne cessent jamais de changer, donc un Product Backlog est un artefact vivant.

Les changements dans les exigences opérationnelles, les conditions du marché, ou la technologie peut causer des changements dans le Product Backlog.

Plusieurs équipes Scrum travaillent souvent ensemble sur le même produit.

Un Product Backlog est utilisé pour décrire le travail à venir sur le produit.

Un Product Backlog attribue que les items des groupes sont alors employés.

Product Backlog Grooming

Le Product Backlog grooming est l'acte d'ajouter des détails, des estimations, et de l’ordre dans les items du Product Backlog.

Ceci est un processus continu dans lequel le Product Owner et la Development Team collaborent sur les détails des items Product Backlog.

Pendant Product Backlog grooming, les items sont examinés et révisés. Toutefois, ils peuvent être mis à jour à tout moment par le Product Owner ou à la discrétion du Product Owner.

Le Grooming est une activité à temps partiel pendant un Sprint entre le Product Owner et la Development Team.

Souvent, la Development Team a les connaissances du domaine pour effectuer elle-même le grooming.

Comment et quand le grooming est fait est décidé par la Scrum Team.

Le Grooming consomme habituellement pas plus de 10% de la capacité de la Development Team.
La Development Team est responsable de toutes les estimations.
Le Product Owner peut influencer l'équipe en aidant à comprendre et sélectionner les arbitrages, mais les individus qui vont effectuer les travaux font l'estimation finale.

Suivi des progrès vers un objectif

A tout moment, le travail total restant pour atteindre un objectif peut être résumé.

Le Product Owner piste ce reste-à-faire total au moins pour chaque Sprint Review.

Le Product Owner compare ce montant avec le travail restant de la Sprint Review précédente afin de mesurer les progrès vers l'achèvement des travaux projetés par le temps désiré pour atteindre le but.

Cette information est rendue transparente à tous les intervenants.

Scrum ne considère pas le temps passé à travailler sur des éléments de Product Backlog.

Le reste-à-faire et la date sont les seules variables d'intérêt.

Diverses tendances de Burndown, de burnup et d'autres pratiques projectives ont été utilisées pour prévoir les progrès.

Celles-ci ont prouvé leur utilité. Cependant, elles ne remplacent pas l'importance de l'empirisme.

Dans les environnements complexes, ce qui va arriver est inconnu.

Seul ce qui est arrivé peut être utilisé pour une prise de décision prospective.

Sprint Backlog

Le Sprint Backlog est l'ensemble des items de Product Backlog sélectionnés pour le Sprint, plus un plan pour fournir l'incrément du produit et la réalisation de l'Objectif du Sprint.

Le Sprint Backlog est une prévision par la Development Team sur ce qui sera une fonctionnalité dans le prochain incrément et le travail nécessaire pour fournir cette fonctionnalité.

Le Sprint Backlog définit le travail que la Development Team produira pour transformer les items du Product Backlog en un incrément « Done ».

Le Sprint Backlog rend visible tout le travail que la Development Team identifie comme nécessaire pour atteindre l'objectif du Sprint.

Sprint Backlog est un plan avec suffisamment de détails pour que les changements en cours peuvent être compris lors du Daily Scrum.

La Development Team modifie le Sprint Backlog à travers le Sprint et le Sprint Backlog émerge au cours du Sprint.

Cette émergence se produit comme quand la Development Team travaille à travers le plan et en apprend davantage sur le travail nécessaire pour atteindre l'objectif du Sprint.

Quand un nouveau travail est nécessaire, la Development Team l’ajoute au Sprint Backlog.

Comme le travail est effectué ou terminé, le travail restant estimé est mis à jour.

Lorsque les éléments du plan sont jugées inutiles, ils sont retirés.

Seule la Development Team peut changer son Sprint Backlog lors d'un Sprint.

Le Sprint Backlog est une image du travail très visible, en temps réel que l'équipe de développement des plans pour réaliser au cours du sprint, et il appartient exclusivement à la Development Team.

Surveillance du progrès du Sprint

A tout moment, dans un sprint, le total du reste-à-faire dans les items de Sprint Backlog peut être additionné.

La Development Team piste ce total du reste-à-faire au mieux lors tous les Daily Scrums.

La Development Team piste ces sommes quotidiennement et projette la probabilité d'atteindre l'Objectif de Sprint.

En suivant les travaux restants tout au long du Sprint, la Development Team peut gérer ses progrès.

Scrum ne considère pas le temps passé à travailler sur les items de Sprint Backlog.

Le reste-à-faire et la date sont les seules variables d'intérêt.

Incrément

L'incrément est la somme de tous les éléments du Product Backlog complété au cours d'un Sprint et tous les Sprints précédents.

A la fin d'un Sprint, le nouvel incrément doit être « Done », ce qui signifie qu'il doit être en état d’usabilité et répond à la définition of « Done » de la Scrum Team.

Il doit être en état d’usabilité indépendamment du fait que le Product Owner décide de le livrer.

Définition of « Done »

Lorsque le Product Backlog item ou un incrément est désigné comme « Done », chacun doit comprendre ce que «Done» signifie.

Bien que cela varie considérablement par Scrum Team, les membres doivent avoir une compréhension commune de ce que cela signifie pour le travail d’être terminé afin d'assurer la transparence.

Voici la "Définition de Done" pour l'équipe Scrum et qui est utilisée pour évaluer quand le travail est terminé sur l’incrément du produit.

La même définition guide la Development Team pour savoir combien d’items de Product Backlog elle peut sélectionner lors d'un Sprint Planning Meeting.

Le but de chaque Sprint est de livrer des incréments de fonctionnalités potentiellement livrables qui adhèrent à la Définition of “Done” actuelle de la Scrum Team.

Les Development Teams délivrent un incrément de fonctionnalités-produit chaque Sprint.

Cet incrément est utilisable, de telle sorte que le Product Owner peut choisir de le délivrer immédiatement.

Chaque incrément est un additif à tous les incréments antérieurs, testé en profondeur, pour s’assurer que tous les incréments travaillent ensemble.

Comme les équipes Scrum mûrissent, il est prévu que leur définition de « Done » s'élargisse pour inclure des critères plus rigoureux pour une qualité supérieure.

Conclusion

Scrum est gratuit et offert dans ce guide. Les rôles Scrum, les artefacts, les événements, et les règles sont immuables, et mettre en œuvre que des parties de Scrum est possible, le résultat n'est pas Scrum.

Scrum n'existe que dans son intégralité et fonctions ainsi qu’en tant que conteneur pour d'autres techniques, méthodologies et pratiques.

Traduction non-officielle du Scrum Guide 2011 (http://www.scrum.org/storage/scrumguides/Scrum%20Guide%20-%202011.pdf)

Les 7 vertus capitales de toute transition agile

2011-10-08T15:14:00.000+02:00

Je ne sais pas ce qui m'a pris aujourd'hui. En lisant les threads sur le coaching agile, en faisant le point sur toutes les discussions sur la réorganisation agile, sur la mise en place de centre de compétence agile, sur la réingénierie de la PMO, je me suis interrogé sur mon comportement face à cela.

Une grande frustration est latente au fonds de moi lorsque j'assiste à certaines présentations où l'on distille les principes de l'agilité dans différentes domaines: les tests, la gestion de portefeuille, les UX, le développement, le support. Chaque intervenant est intéressant, mais en faisant le point, je m'aperçois que nous parlons tout le temps de la même chose en changeant simplement l'emballage. Quelle est la valeur qui se dégage de cela? Pfff... No sé

Bientôt l'Agile Tour avec ses flots de sessions. Je vais participer, je vais écouter, je vais partager, et je vais revenir avec cette lancinante question: qu'ai-je vraiment appris aujourd'hui?

Une de mes forces est la communication et l’intérêt que je porte sur l’avis de chaque personne que je rencontre. Cette force est également ma plus grande faiblesse : car en cherchant à briser les certitudes et éveiller la pensée individuelle, je fais face aux résistances et aux craintes.

Aujourd’hui, je fais ma rétrospective personnelle et je la blogue pour la figer et la partager avec vous.

Le vrai changement commence par soi et va de l’intérieur vers l’extérieur. Mon comportement en tant que coach influe sur l’environnement que je soutiens. Pour discipliner ma démarche vertueuse, il me fallait 7 vertus :

Chasteté: s’abstenir de toute pratique immorale et faire preuve de retenue.

Tempérance: ou sobriété. Une transition se doit d’être sobre : « just enough, just in time », juste ce qu’il faut, juste à temps.

Prodigalité: donner sans compter. Dans un projet de transformation, toute retenue peut affecter la nécessité de transparence. Le « bon coach » se doit de se dévouer sans compter à son projet, ses clients, ses collègues, son entourage, sa communauté.

Charité : faire le bien du prochain. Une transition est un changement vers le meilleur et pas un combat ni une négociation. Le coach ou le Transition Manager est un résolveur de petit maux : il aide les individus et l’organisation sur ce chemin : on dit qu’il accompagne le « Petit Poucet » sur le chemin du retour.

Modestie : faire passer les autres, le projet avant soi.

Courage : capacité à surmonter la peur face aux dangers .S’engager.

Humilité : la mise en avant de son ego est un frein à la transition. Comment une seule personne peut-elle avoir la connaissance d’un ensemble sans impliquer cet ensemble ? Un projet de transition est une action collective dont les lauriers sont partagés.

Et je me dis que la route va longue...

Et je me remémore ma ligne de conduite:

Les règles du conseil

Accentuer le positif
Ne pas insister sur le négatif
Toujours proposer des actions faisables et utiles

Mon process de conseiller

Dans quelle mesure mon client me connaît?
Dans quelle mesure suis-je engagé à aider et protéger mon client de toute nuisance?
Ai-je accepté le rôle que je vais jouer pour aider mon client?
Dois-je donner une performance en solo?
Ai-je fait un processus de conseil clair aux yeux de mon client, et ai-je fait face à ses problèmes de façon constructive?
Mon avis est-il sans impuretés de déloyauté et d'incurie?
Ai-je donné à mon client une idée de comment la relation de conseiller prendra fin?

Mes règles de rapports

Les faire le plus court possible.
Mettre l’objectif du rapport en premier.
Aller directement au vif du sujet. Ne pas philosopher.
Utiliser des titres et sous-titres pour structurer le document.
Toujours utiliser le présent.
Ne jamais répéter une information connue par le client tout au long du message.

PRODUCT BACKLOG, USER STORIES & PERSONAS. COMMENT S’Y PRENDRE?

2011-10-06T14:14:00.001+02:00

Dans Scrum, le Product Owner a un rôle capital qui est de s’assurer que le projet délivre un produit de qualité répondant aux besoins du client . Ces besoins sont souvent définis et priorisés en utilisant l’appellation “Business Value” (valeur métier).

Comment çà marche?

Tout d’abord, le Product Backlog.

Celui-ci doit répondre aux 3 questions suivantes:

· Quoi?

· Quand?

· Pour qui?

Quoi? Il s’agit bien sûr des fonctionnalités et jamais d’exigences techniques.

Quand? Nous voulons savoir quelles fonctionnalités sont prioritaires, donc quel est le scenario de livraison de notre produit.

Pour qui? Notre client a certainement une excellente idée. Mais si son produit sera excellent et de bonne facture mais jamais utilisé, quelle est sa vrai valeur?

Le process Scrum

Avant de commencer votre projet, donc avant d’impliquer l’équipe de développement, il faut clarifier le périmètre du projet.

En langage Scrum, ce périmètre est défini par:

· La Vision

· Le Product Backlog

· La Roadmap

1. Le Product Owner rencontre le client est clarifie la Vision du Produit.

Cette vision doit être claire et “partageable”, c’est à dire que toute personne participant au projet doit être à même de comprendre celle-ci sans que cette dernière soit déformée par un quelconque “téléphone arabe”.

2. Le Product Owner demande au client à qui s’adresse ce produit? Qui sont les utilisateurs du produit?

Roman Pichler écrivait que l’objectif de Scrum est de développer un produit que les utilisateurs vont aimer. Pour être sûr que l’objet du développement va atteindre correctement son public, donc générer de la valeur pour notre client, nous devons donc nous adresser aux intéressés.

3. Le client introduit le Product Owner auprès de ces utilisateurs ou développe un panel d’utilisateur type (personae) avec le Product Owner.

Il s’agit de créer une interaction entre le client et les utilisateurs. Il s’agit d’une étape primordiale pour bien démarrer son projet et rechercher une implication à flux constant des utilisateurs.

4. Le Product Owner rencontre les utilisateurs lors d’un User Story (US) Workshop,

a. le Product Owner introduit la vision du client est demande à chaque utilisateur de rédiger une User Story (personelle) adressant une fonctionnalité souhaitée pour le produit futur.

b. Afin de clarifier les attentes de chaque utilisateur, le Product Owner demande 3 lignes de critéres d’acceptation pour chaque US rédigée.

c. Collectivement avec les utilisateurs, les US initiales sont redécoupées en fonction de nouveaux critères d’acceptation. La découpe s’arrête lorsqu’il n’y a plus de nécessité de découpage (just enough!).

5. Le Product Owner revient vers le client avec les US crées lors du US Workshop:

a. Les US sont mises en “vrac” est le travail avec le client peut commencer.

b. Avec le client, nous allons faire la revue de l’ensemble des US et nous allons les triés en fonction des fonctionnalités émergentes: nous ne souhaitons pas livrer un utilisateur, mais plutôt livrer une fonctionnalité permettant de faciliter la discussion avec tous les utilisateurs lors de prochains meetings.

c. Nous supprimons les doublons, analysons les US qui se chevauchent.

d. Le Product Owner demande au client de classer les US en fonctionnalités.

e. Nous regroupons ces fonctionnalités en cherchant à les grouper en Epics et à laisser émerger des Thèmes.

f. La prochaine étape étant la priorisation, il nous faut connaître la Business Value de chaque US. Seul le client pourra nous la donner. Cette priorisation tient compte des paramètres suivants:

· In ou Out (fait sens ou pas...)

· En phase avec la Vision

· Apporte de la valeur au client

· Utile au client

· Permet de réduire les coûts

· Gestion des risques

· Gestion des incertitudes

· Dépendances

· Livrabilité

g. Comme pour un planning poker, cette Business Value est une valeur relative. Nous utilisons donc une approche basée sur MOSCOW pour attribuer une Business Value (BV) par US. Les critères de définition de la BV seront les suivants:

h. Les BV sont consolidées aux niveaux Epic et Thème.

i. Initial Roadmap. Il s’agit de la feuille de route où le plan de livraison initial émergeant de la consolidation des BV.

· Idéalement, cette feuille de route part du thème le plus valorisé au thème le moins valorisé

· Cette roadmap est un outil de communication permettant de renforcer l’analyse des besoins et des exigences pour entammer l’inspect-&-adapt de l’équipement de développement lors du Sprint Planning Meeting.

6. Maintenant, nous sommes prêt à rencontrer la Development Team est analyser avec elle la faisabilité technique de notre produit.

Conclusion

· Pas de Scrum sans cadre de projet initial.

· Le Client définit la vision.

· Les utilisateurs créent les user stories (user + story)

· Le Client priorise ces stories en fonction de la Business Value

· Le tri des stories en epics et thèmes permet de mieux comprendre les attentes des utilisateurs en fonction des exigences du client.

· Une feuille de route initiale est créée pour connaître le COMMENT du point de vue du client.

· Le cadre de projet est uniquement fonctionnel: l’aspect technique est du ressort de la Development Team.

· Le cadre de projet est une information primaire qui évoluera tout au long du projet en fonction:

o De la montée en compétence de l’équipe

o De la réduction des incertitudes

o De l’implication de tous les acteurs au projet.

SCRUM ET LA COMPLEXITÉ: L’EXPLICATION PAR CYNEFIN!

2011-09-12T12:00:00.001+02:00

“Scrum (nm): Un cadre dans lequel les gens peuvent répondre à des problèmes complexes et adaptatifs, tandis que productivement et créativement ils délivrent des produits de la valeur la plus élevée possible” (Scrum Guide 2011).

Un grand nombre de discussions tournent autour de l’approche complexe et adaptative. Cette terminologie fait appel une analyse de l’Institut Interdisciplinaire de Santa Fe mettant en avant les systèmes complexes auto-adaptatifs (CAS) qui sont des systèmes complexes évoluant en fonction de leurs environnements et aux interactions des acteurs de ce système.

Réf. http://en.wikipedia.org/wiki/Complex_adaptive_systems.

Hormis cette définition « complexe », savoir faire la différence entre un environnement de développement et un environnement de production est primordial pour optimiser la mise en place de Scrum où toute autre démarche agile.

Lors de l’Agile Coach Camp Germany 2010, Pierluigi Pugliese et Joseph Pelrine m’ont fait découvrir une approche permettant de mieux comprendre comment fonctionne ces systèmes. Cette approche s’appelle Cynefin. Après avoir analysé cette démarche et surtout avoir découvert qu’une grande partie de mes maîtres à penser (J. Sutherland, K. Schwaber, C. Mathis, etc.…) l’utilise et s’en réfère, j’ai eu le plaisir de suivre la formation de Dave Snowden à Francfort après le Scrum Day l’an dernier.

La partie orgueilleuse étant passée, allons voir cela de près.

Cynefin

Représentation graphique de Cynefin

Voici en gros le schéma de Cynefin que vous pourrez trouver sur Wikipedia ou que vous auriez déjà pu apercevoir dans de nombreuses présentations ou formations.

Selon Dave Snowden, toute chose interagit avec une autre et son contexte. Cynefin cherche à dessiner un chemin pour rendre la recherche de sens plus naturelle. L’objectif est clair :

· Donner du sens permet de réduire les risques et met en lumière les évidences

· Donner du sens est une motivation que tous nous recherchons

· Dans notre contexte, donner du sens permet également de connecter l’intelligence humaine avec une technologie omniprésente

3 Principes de base (D.Snowden):

1. Des petits éléments bien définis évitent la désintégration

2. Une connaissance distribuée : délivre la sagesse et pas « la folie des foules »

3. La Désintermédiation : connecte les décideurs avec les données brutes

Explication

Le fonctionnement d’un groupe d’individus peut être modélisé en fonction de l’inter-opérabilitité ou la manière dont la communication entre ses individus se forme :

Pour mieux comprendre c’est différents « environnements », voici des tableaux reprenant les caractéristiques de chaque état, le rôle du leader (sommet de la pyramide de communication), les signaux d’alertes et les contre-mesures.

Ce qu’il faut savoir, c’est que chaque état n’est pas figé, et qu’une organisation évolue/régresse tout au long de sa vie, de son projet, de la journée.

L’environnement « Désordre » ne sera pas abordé. Cet environnement est considéré comme une zone de non-existence de relation, un trou noir en quelque sorte. Comme le zéro absolu, elle est indiquée au titre de point de référence.

Entrons dans le vif du sujet.

1. COMPLIQUE

2. SIMPLE

3. CHAOTIQUE

4. COMPLEXE

Et Scrum dans tout cela ?

En reprenant le schéma de Cynefin, Scrum pourrait se définir de la sorte :

1. Le SPRINT

· Le ScrumMaster maintient le Sprint dans une phase complexe où l’équipe interagit et s’interroge sur les solutions de développement à apporter.

· Le Daily Scrum est une phase complexe où l’équipe coordonne ses efforts et fait le point sur les émergences en-cours

· Le Product Owner est compliqué avec l’équipe pendant le Sprint. Son expertise du Product Backlog permet de recadrer les items ou la concentration de l’équipe sur la qualité de son engagement.

2. La Revue de SPRINT (Sprint Review)

· La démonstration des items développés est un évènement « complexe » où l’équipe de développement co-crée (inspect-and-adapt) avec les participants au projet (utilisateurs, clients). Le Product Owner et le ScrumMaster travaillent de concert pour maintenir cet environnement en phase complexe.

· La validation des stories ou du Sprint est une phase compliquée où le Product Owner agit en tant qu’expert du Produit. L’acceptation ou le rejet répond au besoin que le résultat du Sprint est « simple ».

· L’approche idéale, voire naturelle, est une revue en 2 parties : une complexe, une compliquée.

· La conclusion de la revue de Sprint est un compromis simple: « Done » ou « not Done » ; acté en présence de tous les participants. Ce compromis permettra de revoir le cadre de projet (avec les utilisateurs et les clients), d’affiner les process de développement (rétrospective).

3. La Rétrospective

· La rétrospective est en théorie une « célébration » pour faire le point sur ce qui va et ce qui ne va pas. Celle-ci a clairement une vocation « complexe ». Cependant, le ScrumMaster, dans sa qualité de coach (spécialiste Scrum), vérifie la bonne exécution du process. De ce fait, le ScrumMaster est l’élément compliqué tirant une information complexe (retour de l’équipe) pour l’acter. Cet acte est quant à lui un indicateur simple, ex : formations supplémentaires, points de blocages, lead time, communication entre les membres, gestion des ressources, etc.…

· L’objectif de la rétrospective est d’identifier ce qui ne va pas. Pas dans un esprit négatif, mais plutôt pour identifier les points d’amélioration.

4. Le Sprint Planning Meeting

Cet évènement reprend toutes les phases du modèle Cynefin :

Le Product Backlog, la Product Roadmap, le Release Plan sont des éléments simples
La Définition of Done (DOD) et le Level of Done (LOD) sont des éléments complexes
La priorisation et l’estimation sont des éléments complexes
Etc.

La complexité doit cependant être préservée pour créer un compromis juste et nécessaire entre la vision produit, la capacité de le développer et la qualité souhaitée.

5. Le Release Planning

· Il s’agit de la discussion entre le Product Owner, les clients et les utilisateurs afin de définir les points d’étapes du développement, de cadrer le projet.

· Dans la 1^e phase où la vélocité de l’équipe n’est pas encore connue, le Product Owner maintient un environnement complexe pour collecter les idées émergentes venant des participants.

· Dans la 2^e phase où le Product Owner est capable de donner une date de livraison, celui-ci maintien l’environnement complexe pour identifier les risques et améliorer les items de la 1^e release. Cependant, celui-ci est compliqué en repoussant à une prochaine livraison toutes nouvelles fonctionnalités.

Conclusion

Ce n’est pas simple mais compliqué d’expliquer cette chose complexe…. (blague).

Si vous deviez retenir qu’une chose de cette information, c’est que Scrum est un travail d’équipe basé sur le compromis. Le compromis par essence réduit les possibilités de création mais induit un résultat. Apporter un résultat est un vecteur majeur de motivation de l’équipe (achievement) et des participants aux projets (retour sur investissement, réduction des risques).

Cynefin est un des nombreux outils RH permettant aux coachs, ScrumMasters, acteurs de changement, de mieux comprendre comment intégrer une approche agile dans un système différent, de mieux comprendre les synergies de groupe.

De mon côté, Cynefin est mon garde-fou. De part mon passé, je suis très « compliqué », en utilisant cette analyse, cela me permet de mieux comprendre où je suis et mieux comprendre où je vais.

Bonne lecture

Pierre

Agile Summer in the City

2011-07-27T12:22:00.001+02:00

Dear fellows,

August is coming and the city (and of course the business) sounds to be away on the Beaches between St Tropez and Malaga.

No matter of that for you and me... don’t care... now we have

Agile Summer in the City

It is:

· 8 deep-dive coaching sessions on Agile

· 8 pro-active and fun sessions

· 8 sessions in Luxemburg City (5’ walk from the Train Station, with Terrasse)

· Only for this Summer

· An only in the evening

Format: coaching sessions. The session topic is given and in a group of maximum 8 people, I will help you to better understand or pass through some agile techniques.

Audience: ideally agile practitioners, but skeptics and newbies are warmly welcome.

Content:

Session	Date	Time scale	Session	Price (ex. VAT)
1	Thu 04/08/2011	18:00 – 21:00	Visual Management with Kanban	50 €
2	Tue 09/08/2011	18:00 – 21:00	Adaptive Planning	50 €
3	Thu 11/08/2011	18:00 – 21:00	Value Driven Delivery	50 €
4	Thu 18/08/2011	18:00 – 21:00	Stakeholder Engagement	50 €
5	Thu 25/08/2011	18:00 – 21:00	Boosting Team Performance Techniques	50 €
6	Tue 30/08/2011	18:00 – 21:00	Problem Detection and Resolution	50 €
7	Thu 01/09/2011	18:00 – 21:00	Continuous Improvement Tipps & Tricks	50 €

Pricing:

· 1 session: 50 € / person

· 8 sessions: ~~400€~~ 200€ / person

· 4 sessions: ~~200€~~ 150€ / person

· Come with a colleague and get 10% discount for the fist session.

The pricing is VAT 15% excluded. Invoice and training certificate is delivered.

Register here

Pierre Neis

Scrum Coach

coPROcess S.A. - 11 avenue de la Gare - L-1611 Luxembourg

pneis@coprocess.lu - Tel. +352 / 661 727 867

Buging Bug! Scaling the agile evil...

2011-07-19T14:02:00.000+02:00

During my wellcomed sweet holidays I kept connected to my fellow agile communities to read what is happening during my “Summer Sprint”. One of the threads was very interesting and I thought that I have to share it with you.

The theme is ~~double~~ overlapping: on one hand you find “buging the bug”, it’s about managing bugs in an agile product development. In second hand, you have “scaling the agile evil which is about agile project escalation in a traditional organization.

And if you add both bullet points, you find the theme on scaling agile projects when the house is full of bugs! So, I reduce the scope on this.

Let’s start the story. For correctness, I will hide every details that could affect my customer but I know he will recognize “it”self. To make this post a bit more interesting, let’s call “him” Joe.

I have a project...and I’m lost!

Joe send me an email to ask on advice for his project. This is a big project where bug-fixing takes a major part.

To handle this he researched different options to integrate all stakeholder’s requests. The issue was to be the most reactive to fix the bugs (some of them needing to be handled in 2 days max) and to control the chaos they certainly will create without stopping the Sprints.

He checked some practices like firefighter teams, bug treatment as an user story in the Sprint Backlog (only non-bloking one), and Kanban.

Kanban sounds perfectly fitted to his aim. The strategy he wants to follow is to treat each bugfixing activity as a support epic into the Product Backlog. This epic needs then to be sliced down at task level (bug) and then managed into the limits of the Kanban(!).

But, after studying a piece of Kanban, the aspect of «... we’ve broken down in-process into two states: specify and execute. » gives him the aspect of introduction of specialization and it seems to “waterfallish” for him.

What is the best solution? How can he handle this? These are the questions that I’m trying to help him out without knowing the scope of all the project.

When nothing works “ask the team”!

Honestly, I cannot give a relevant advice with this piece of information. But I try to coach him out the bad path.

I didn’t know if the project is runned as an agile project: I just suppose that there is a bit of Scrum because of the utilization of specific vocabular and I understand that is a will to apply agile techniques (e.g. Kanban).

The main problem with methods is our addiction to it, to the detriment of the answers that they should deliver us. All the methods that Joe have marked are “virtually” good but really out of step with his needs: fixing the bugs.

I remember a discussion that I had with a Manufacturing Project Manager about the Toyota Production System (TPS) four years ago. He explaind me that every operator in the chain had a stop button. When an operator detected a defect (bug) he could stop the chain on its own. Clear the problem. Restart the production.

Is this running differently in agile projects? I think no. If a bug is detected, each team member has to have enough empowerment to stop the production of code until the bug is fixed.

... when nothing works ... ask the team! As the whole team is facing this problem, make a review and try to fix it, at last stop the Sprint and make bug-fixing Sprints.

It’s more complicated that it seems...

Joe cames back to clarifiy the scope of the project and let me know that it is more complicated that it seems (I love this sentence!).

The company has started a complete IT Department restructuration as a big bang for 5 years. This internal project consumed more than 100 million euros, have only 10% of the portfolio in production. The whole portfolio isn’t in production because 30% requirements are left, the delivered stuff is too unstable and needs urgent fixings. These are the product management issues.

The projects are managed in a “waterfallish” matter with a taste of Scrum: project teams can pull the specifications and are committed to the Release. (Ok! Hmmm). Joe has been promoted as Project Manager of a 30 headed team in charge with the development and 40% of the maintenance(!!!).

Regarding to my recommandations, Joe evaluates that he needs then to have 10 bug-fixing Sprints and during those Sprint no new or urgent business feature would be delivered. If he should ask his Product Owner, the bug corrections wouldn’t be set as high priorities. And at last, these Sprints might be critical for the team morale.

Learning to say no!

Indeed the scope is getting more complex but I keep my eyes open on the core: quality.

Let’s be logical. Making assumption that if you don’t fix the bugs then you scale up on unstable fundations. According to that, what will be the value of the 70% developped features? Just good for the trash? Or time and budget consumming maintenance projects handled by foreign development teams (e.g. outsourced!). I agree, I was a bit pushy...

Bug-fixing is not a left hand job. In agile, bug-fixing is a core point of the continuous team improvement process (like a Kaizen event in Lean). And if your intentions are to start Scrum, then you must know that in Scrum, the development team commits first to product quality.

In Scrum, like in any other Agile Methodology or Framework, the development team is self-organized.

The strength of self-managed teams is their adult behavior. Leaving spinning quality, thus releases, so risky estimates, etc ... reinforces the idea of an immature approach of Scrum and gives fodder to the "traditional tribes."

My advice on this is:

learn to say no!

Teach your Product Owner to accept only “done” items

If it’s impossible don’t make Scrum

It’s hard to say, but eXtreme Programing (XP) or Kanban fits better because it doesn’t impact the management.

A solution is emerging

Joe is back and balancing between increasing the product quality and respond to Product Owner’s requests. He thinks that at the moment he is unable to fix every bugs and a control chaos approach sounds for him more reasonable to increase its development visibility.

In other hands, the problem is not the existing bugs stockpile but more the incoming unknown and variable one. He confesses that very few unit tests have been made (!).

For the new features, he agrees that only “done” items would be accepted. And those might have a suite of automated unit tests and “OK” UX tests (if possible, automated too).

He understands now that without a minimum of bug’s control, every commitment stands as a problem.

A solution is emerging: Product Backlog cleaning with the help of XP and Kanban sounds promising. And when the development has reached an average level of quality then he wants to start Scrum. But, he agrees that it’s only possible with the agreement of the whole team.

· No bug is a fairy tale. (the best rate I never saw was 95% in a XP Project)
· Define a “Bug Ratio Transition Plan” with an acceptable Level of Done
· According to the volume of bugs to fix, the team should reevaluate its level of done and its capacity to commit to the next Sprint
· The Team focuses on bug fixing, during that time UX tests are managed by the Product Owner
· When you have too much bugs to fix, automate all the tests
· Trick for the Product Owner: if you have too much bugs in your Product Backlog your product is in trouble (really!) and you can start thinking to skip the last quarter of your Product Backlog because it will never been developed

Conclusion

eXtreme Programing (XP) gave the guidance in terms of quality coding and these practises are now widely adopted by agilists. In Scrum, these practises are know as Level of Done (LOD).

The LOD is the quality constraints that each team member needs to follow to address its commitment.

LOD is:

· the code adheres to standards

· the code is clean

· the code has been refactored

· the code has been unit tested

· the code has been built

· the code has a suite of unit tests applied to it

To reach this coding standard, the development environment must have:

· a source code library

· coding standards

· automated built facility

· unit tests harness

Scaling the agile evil!

Using agile techniques for your development is not a warranty to make good and stable software and it is not the Messia to solve all your problems. Contrariwise, using agile techniques reveals the defects and fosters people to learn through improvement.

When you are facing the same problem as Joe (it’s very common!), push the “stop” button, ask the team, fix the problem, deliver every month, improve, push the “stop” button, etc...

Scrum & PMI, how can that go well?

2011-06-08T14:34:00.003+02:00

Scrum & PMbok @ pmi

View more presentations from Pierre NEIS.

ALE2011 Unconference Berlin Sept. 7-9 – Industry Call for papers

2011-05-30T15:15:00.000+02:00

The Agile Lean Europe (ALE) network is a Europe-wide open network for people passionate about Agile and Lean practice and thinking. It encourages people to share knowledge and experience. ALE fosters learning and continuous improvement of the network members and the people they relate to. ALE uses its European scope to bring different perspectives of different European cultures together.

The ALE 2011 unconference is a European melting pot of Agile and Lean practitioners with many diverse perspectives and influences. It is intended as a cross-border, non-profit collaboration event for mutual learning and continuous improvement.

We are looking for industry-based practitioners working in Europe to speak at the conference and share experiences combining lean and agile thinking, management and product and software development with their fellows. We take a very broad view of what constitutes agility and leanness and highly value diverse approaches.

The community wants to hear from developers, testers, program managers, project managers, user experience designers, coaches, functional managers, directors, scrum masters, product owners, customers and anyone else involved in creating products or delivering services.
We particularly welcome short case studies, stories and experiences reports from industry practitioners: stories of success and failure or stories of how you applied well-known concepts like Scrum, XP and Kanban, or lesser-known concepts, and how this impacted your product or team.
We are interested in all kinds of challenges in small or big, collocated or distributed agile product development regarding organization of the project, teams, productivity and leadership.

We would be glad to hear from you about system change topics that go beyond the single agile project: getting rid of organizational hierarchies; interfacing with large-scale non-adaptive planning; applying systems thinking; how to go beyond budgeting; intelligently combining hardware and software development; and transferring lean and agile principles to the service organization.
In the spirit of the cross-border collaboration that ALE is trying to foster we would especially encourage talks from two speakers coming from or working in two different countries.

You are, however, welcome to submit a talk as a single speaker. As we expect contributions from all participants, for instance in the open space, speakers and participants will share the conference costs by paying the same fee. We try to keep the costs as low as possible.
Please submit your abstract and short bio before June, 30th, 2011, to the web site: http://www.ale2011.eu/
The selection of the best speakers by the organizers and participants will take place by July 6th. A high number of votes will result in a strong indication of preference, so it is helpful to submit early. However, the final selection will also take into account the diversity of topics and represented countries.

Industry Sofa
For any questions, please contact the Industry Sofa, or ask on the ALE Network LinkedIn group.
Andrea Heck, Siemens AG Healthcare, Erlangen, Germany | AgileAndrea@googlemail.com
Ken Power, Cisco Systems, Galway, Ireland | ken.power@gmail.com
William Gill, Nokia, Berlin | william.gill@nokia.com

Agile Lean Europe (ALE): the Luxemburgish Vision

2011-05-02T14:17:00.002+02:00

Ale lux v1

View more presentations from Pierre NEIS