Planet Valtech Alumni

9:00 - 10:30 - Scrum Metrics for Hyperproductive Teams: How They Fly Like Fighter Aircraft, Jeff Sutherland et Scott Downey

Mes tweets :

• clean up the product backlog by relying on the INVEST acronym (Independent, Negotiable, Valuable, Estimable, Sized appropriately, and Testable).
• First start with time to fix bugs to get the first X2 productivity
• Sprint planning meeting: anchoring the Scale - using the INVEST & Value, Voice & Visibility
• Changes to Scrum meetings: teams want to start by the easiest story, Scrum Master set the story points at 3! It always work to set the scale
• 3 is OK if user stories are well written. Always true even if not agile (my opinion) but less visible from the beginning
• If a user story is too large to put in a Sprint Backlog, let the user, PO?, break it in terms of business value
• Try RoboCoach (metrics for hyper-productive teams) - http://rapidscrum.com/RoboCoach�

(Please visit the site to view this media)�

• la v�locit�,
• la capacit� de travail,
• le facteur de focus (v�locit� / capacit� de travail�),
• le travail adopt� en cours de sprint => encourager l'�quipe � s'engager plus
• le travail d�couvert en cours de sprint => encourager l'�quipe � mieux analyser les estimations initiales des stories pour mieux anticiper sous-estimations potentielles
• l'augmentation de value cibl�e (valeur de la v�locit� du sprint courant / la v�locit� originale)
• l'exactitude des estimations,
• l'exactitude des engagements de l'�quipe

• Using Collaborative Product DIscovery to Plan Agile Projects
• How do you decide what to build? How do you know when you are ready to start building?
• Discovery: understand the right product to build vs Delivery: build the product right -> find the right balance
• Learn about the context to identify the solution: context in terms of business strategy, user goals, Product usage, Regulatory constraints
• Target solution to maximise outcome, not output: starting context -> ideas (features, ...) -> incremental dev -> delivery :-)
• Resulting context -> outcome is user happy with the output of the incremental dev.
• User really happy -> great impact in the resulting context
• Try more to maximise outcome than output -> fit to the user expectations in the resulting context
• Prioritize outcomes, not outputs
• Use Workshops for effective collaboration with larger groups: understand purpose, customers and users of products
• Don't hesitate to use videos to explain ideas in distribued teams
• Use story map & storyboard to collaboratively discover product - then simulate use !!!!
• Slice the backlog into incremental releases with "goals"

• RT @estherderby: containers, difference , exchanges: structures that drive behavior in organizations. http://bit.ly/j8pyv
• RT @estherderby: every team is self-organizing within their constraints. trick is neither over nor underconstraining the team.
• Scrum Masters think about a project as a 1 hour race, project managers as a 10k race!

• Concept -> ideas -> main features -> features + screens -> cost -> user stories
• Use Case still interesting to capture features !
• From features to user stories? Paper storyboard of the project to derive story cards (usages of the app)
• Clarify requirements with Story Tests - success & failure paths

9:00 - 10:30 - An Unplugged Retrospective on the Agile Decade - Mirror Mirror on the wall are we really the most beautiful of all?, Dave Thomas

La journ�e commence par le keynote de Dave Thomas�sur les dix ans de l'agilit�. Parmi les points abord�s par�Dave Thomas, j'ai retenu :

• le Test-Driven Design ou TDD (cf. l'introduction au Test-Driven Design par�Scott Ambler) pr�sent� comme avanc� importante de l'Agilit�.�Effectivement, les tests unitaires et surtout les tests d'acceptation connaissent aujourd'hui un int�r�t important dans une optique de validation par des �quipes m�tier de l'�tat de d�veloppement d'un produit,
• l'id�e classique�dans la communaut� agile�que le meilleur outil est le Post-It permettant aux �quipes de se concentrer avant tout sur des activit�s apportant de la valeur � l'utilisateur du produit d�velopp� (rappelons, que l'agilit� n'exclue pas les outils contrairement � certaines id�es propag�es par de nouveaux "convertis" comme le rappel Kent Beck, cr�ateur de l'Extreme Programming,�dans son whitepaper Tools for Agility�ou encore Ken Schwaber avec les formations Scrum.org),
• la position nuanc�e concernant la certification, consid�r�e comme acceptable. Dave Thomas pr�f�re l'accr�ditation et cible le compagnonage (cf. le mouvement Craftsmanship et son manifeste). Comme pour les Compagnons, l'id�e est d'obtenir une habilit� technique importante (craftsmanship en anglais) par un apprentissage aupr�s de plusieurs ma�tres. A suivre aussi les actions de l'Agile Skills Network�o� Ron Jeffries et Chet Hendrickson montre l'int�r�t d'une formation CSD (Certified Scrum Developer) ;-)

�La vid�o de pr�sentation de la formation CSD avec Ron et Chet :

J'ai aussi not� :

• la d�finition d'un�code�"legacy" : un code legacy est un code sans tests ! Bon, le volume de code legacy vient d'augmenter de fa�on ph�nom�nale ;-)
• un point vue int�ressant sur Lean : "Lean is top-down, Agile is bottum-up and Agility is in the mix". Lean peut aider effectivement les pratiques Agile � s'inscrire dans les pratiques d'une organisation qui a besoin d'une vision globale de ses actions, d'o� l'Agilit�, le c�t� pragmatique du mouvement Agile.
• les entreprises doivent investir dans les tests et d'apr�s l'exp�rience de Dave, il faut entre 18 et 36 mois pour r�ellement voir des changements !!!
• les exigences non-fonctionnelles n'existent pas !!! Il s'agit aussi d'exigences fonctionnelles. A ce sujet, je me souviens d'un prof. de Berkeley parlant de l'Airbag. Le fait qu'un Airbag doit se d�clencher�en moins de 150 ms (environ le temps de clignement de l'œil) est une exigence bien fonctionnelle ;-) Dans ce cas, il faut bien imaginer un moyen de mesurer les performances ! Pour le logiciel, c'est pareil.
• une entreprise ne doit pas h�siter � faire plusieurs versions d'un produit pour afiner sa vision du produit, m�me si le produit comporte des parties mat�rielles (�lectronique, etc.).
• Dave Thomas conseille fortement de lire le livre "Structure & Interpretation of Computer Programs"�par H. Abelson et G. Sussman�(livre au format PDF), l'un des livres les plus marquant sur le logiciel.

Difficile de brosser les 10 ann�es du mouvement Agile, Dave met encore en garde la communaut� : "Agile is still FrAgile", "IT value is still not understood by many business!"

11:00 - 12:00 - �Product Owner as Agile Leader – Oxymoron or Critical Success Factor, Robert Galen

Quelques notes :

• PO only 1 per product - need one voice!
• Use research spikes to gain understanding / sort of sprint #0
• PO strategizes with the Scrum Master�=> no surprise!
• PO stay engaged in the entire process if you are in the team
• PO - drive everything with "goals"
• PO - understand the team dynamics - strength & weakness - talk to your team -share "goals"
• PO - MARKET your team - status email
• PO - concluding remark - PO should be a leader to market his team & drive by "goals"

Session tr�s int�ressante et pratique. Robert Galen a d'ailleurs �crit un livre bas� sur son exp�rience tr�s riche et proche de l'esprit du livre de Henrik Kniberg's Scrum & XP from the Trenches : Scrum Product Ownership - Balancing Value From the Inside Out (pdf).

Tout d'abord, il faut que je vous pr�sente�cette conf�rence. La conf�rence "Agile" est l'un des �v�nements les plus importants�de l'ann�e dans la communaut� agile. J'ai d�couvert cette conf�rence en 2008 (Agile 2008), o� j'avais pr�sent� un retour d'exp�rience sur le passage � l'agilit� d'une organisation d�veloppement des applications d'assurances sur plateformes Java/.NET dans un contexte "mainframe".

Cette conf�rence vise�:

• � proposer aux participants les derni�res id�es dans le domaine de l’agilit�,
• � enrichir les connaissances, � multiplier les axes de r�flexion, � encourager les d�bats et � promouvoir les id�es innovantes.

Elle vise aussi � r�unir des dirigeants, des manageurs, des praticiens du logiciel et des chercheurs. Cette conf�rence n’est pas d�di�e � une m�thode ou une approche, mais plut�t propose un forum d’�changes d’informations sur toutes les technologies agiles. Ainsi en 2009, la r�partition des participants par m�tier �tait la suivante�:

La conf�rence attirait principalement des d�veloppeurs et consultants (43%) et des chefs de projet et dirigeants (30%). En 2010, 1400 personnes, provenant de 38 pays, �taient pr�sentes � la conf�rence. Il y avait 180 orateurs pour 227 sessions.

Apr�s la r�cup�ration de mon sac, direction les deux sessions de la journ�e (chacune de 180 mn) :

9:00 - 12:30 Leader's Workshop: Making Change Happen and Making it Stick, Mary Poppendieck

Mary Poppendieck

Pour les minutes, je vous recommande ce post ! La salle �tait, comme on pouvait s'y attendre pleine � craquer ;-)

��

C'est l'une des sessions qui m'a le plus marqu� ! J'ai not� au passage les points suivants :

• Money don't motivate people�but autonomy, mastering, self direction,
• Open source is an inflection point for collaboration -> motivation 3.0,
• Employees must be managed as volunteers and especially knowledge workers,
• Look at what is working to scale it, not a what is failing to fix it. Because, roots of failures may be impossible to change,
• Script the critical moves with checklists to capture key steps based on existing working practices. Don't add how to do steps,
• Shareholders are better served by a long term focus over quarterly results.

Quelques livres ont �t� cit�s :

• Switch: How to Change Things When Change Is HardSwitch: How to Change Things When Change Is Hard

13:30 - 17:00 Agile Estimating & Planning: From Basics to Brain Stumpers, Mike Cohn

Mike Cohn

Aussi beaucoup de monde pour cette session de l'un des fondateurs de la Scrum Alliance�et auteur des livres incontournables que sont� Agile Estimating and Planning, User Stories Applied for Agile Software Development, et Succeeding with Agile Software Development using Scrum.

�Mike insiste sur la notion de pr�cision des estimations et de son ajustement progressif en fonction de son niveau de compr�hension des user stories : "It's better to be roughly right than precisely wrong", John Maynard Keynes.

Des user stories peuvent �tre estim�es plus grossi�rement et seront mieux estim�es en fonction des user stories d�j� r�alis�es aux pr�c�dentes it�rations. Il s'agit de profiter des it�rations pass�es pour mieux ajuster le nombre de story points pour chaque user story en les comparant aux user stories d�velopp�es.

La planification agile utilise finalement le changement comme un outil d'ajustement et de convergence des estimations.

A voir aussi,�cet interview abordant l'estimation�:

�Peu de sessions ce premier jour, mais des sessions denses et par des orateurs exceptionnels :-)

Scrum Guide

La traduction en fran�ais par nos amis qu�b�cois : Guide Scrum