Préparation Express / Démarrage de projet agile

Les pratiques Agiles les plus utiles sont souvent celles qui émergent sur le terrain, en collaboration avec ceux qui vivent le projet. J’ai eu la chance de le vivre dans le cadre de ma pratique. Lors de l’accompagnement de projets de différentes tailles, on m’a demandé d’épauler le démarrage rapide de petits projets Agiles dans une grande organisation de la fonction publique. Dans un environnement de cette ampleur, il est facile de blâmer la taille de l’organisation pour justifier la lenteur et le coût de démarrage de chacune des initiatives. Le printemps dernier, un directeur du côté client m’a demandé de transformer une initiative à faible budget en succès. Lors de ma pratique en clientèle, en collaboration avec des collègues internes, j’ai assemblé un amalgame d’ateliers existants et créé une démarche répétable pour les petits projets. Plusieurs privilégiés ont eu la chance d’expérimenter cet outil via des ateliers pratiques à l’Agile Tour 2016 de Québec (sous le nom d’architecture express).

Cette démarche a été utilisée à plusieurs reprises en environnement réel. Les types de projets possibles varient entre de nouveaux développements, des améliorations à un système existant, des intégrations d’un produit logiciel ou du développement sur un progiciel. Cette préparation de projet rapide se prête bien aux projets de quelques semaines à quelques mois. Afin de mener à bien la préparation, on vise normalement un noyau de leaders variant de 2 à 5 personnes pour animer des ateliers variant entre 5 à 12 personnes, et une réalisation Agile par la suite. Vous pouvez voir les détails dans notre section outils.

Ce genre de démarrage requiert une implication intensive de 1-3 jours dans un tour d’horizon en 10 ateliers. Par la suite, dépendamment du focus de l’équipe de préparation, une série d’ateliers de préparation (écriture de récits, modélisation Agile etc.) s’étalent sur 1 à 3 semaines. Une fois cette étape de préparation complétée, l’équipe de réalisation peut faire un estimé à haut niveau (ex: via une session murale) et ensuite se lancer en réalisation avec la méthode Agile de son choix.

Même les premières versions ont eu beaucoup de succès, chacune d’elles nous ayant permis d’en apprendre sur l’écosystème affaires et TI de l’organisation. L’outil peut sembler intimidant au premier regard, mais n’ayez pas peur de l’essayer, d’expérimenter et de démarrer vos projets dans une collaboration énergisante! Si toutefois vous souhaitez vivre cette démarche avec accompagnement, contactez-nous et il nous fera plaisir de vous appuyer dans son application.

Pour plus d’information sur la méthode: Éric Lessard

Pour plus d’informations sur notre offre d’accompagnement sur la Préparation Express: Christian Savard, Directeur

Pourquoi avons-nous arrêté de faire des sprints de 3 semaines?

(English follows)

Quelle longueur devrait avoir nos sprints?  1, 2, 3 ou 4 semaines?  Toutes les équipes Scrum et les organisations Agiles se posent cette question et, dépendamment du contexte, certaines organisations peuvent laisser les équipes ou leur imposer un rythme standardisé. Regardons les deux côtés de la médaille afin de comprendre pourquoi les sprints de 3 semaines sont OK… jusqu’à ce qu’ils ne le soient plus.

La grosseur, ça compte

Prenons un petit détour pour expliquer comment les sprints courts donnent plus de contrôle à l’équipe Scrum pour adapter et guider le projet vers un atterrissage en douceur. Imaginez un projet de 4 mois.  Combien de points d’adaptation pouvons-nous avoir pendant cette période?  Si vous avez livré plusieurs projets Scrum, vous savez que les 2-3 premiers sprints servent au ‘décollage’ et à la stabilisation alors que les 1-2 derniers sprints servent à ‘atterrir’ et fermer le projet.  Sachant ceci, à moins que votre équipe de développement soit une bande de vétérans unis, un projet de 5 sprints ne donnera pas le temps à votre vélocité (d’effort) de devenir prévisible.   Une autre façon de calculer le nombre de points d’adaptation d’un projet Scrum est de retirer la première et la dernière planification de sprint.  Sans mesure précédente, la première planification n’adapte rien alors que la dernière planification est plutôt utilisée pour fermer les travaux et ne prendre aucun risque.  Si on regarde un projet de 4 mois, ceci ne donne que 2 points de contrôle pour des sprints de 4 semaines et 6 points de contrôle pour des sprints de 2 semaines.  Donc, des sprints courts, c’est mieux.

En défense de la liberté

La flexibilité de pouvoir choisir la longueur de sprint est un des avantages de Scrum.  Pour l’équipe Scrum, choisir et adapter cette variable fait partie de leur auto-organisation, permettant de balancer la grosseur des incréments avec la fréquence d’itération.

En défense de la standardisation

À l’autre bout du spectre, imposer un longueur de sprint a comme avantage de synchroniser les sprints, ouvrant ainsi une fenêtre d’opportunité pour le personnel flottant (ne faisant pas partie des équipes « noyau ») de transférer d’équipe.  C’est aussi un moment où l’avancement global peut être mesuré simultanément.  Ceci est particulièrement important pour comprendre l’avancement des projets/programmes composés de plusieurs équipes.

Comment avoir le meilleur des deux mondes?

En éliminant les sprints de 3 semaines

Si toutes les équipes limitent leur choix de longueur de sprint à 1, 2 ou 4 semaines, il est alors possible de synchroniser la fin de tous les sprints à la semaine #4.  Bien sûr, pour que cela fonctionne, certaines équipes devront ajuster leur cadence en ajoutant ou soustrayant une semaine à l’un de leurs sprints.  Une fois cette réinitialisation faite, les équipes auront un sprint synchronisé à toutes les 4 semaines.

Alors, à moins de vouloir synchroniser vos sprints, il n’y a pas de problème à faire des sprints de 3 semaines.  Sinon, ils deviennent le mal incarné.

 

Phillipe Cantin

 

Why did we stop doing 3-week sprints?

How long should our sprint be? 1, 2, 3 or 4 weeks? Every Scrum team and Agile organization will eventually ask that question. Depending on the context, some organizations will let the teams decide, while others will impose a standard pace.  Let’s take a look at both sides of the coin and explain why 3-week sprints are OK… until they are not.

Size matters

Let’s take a little detour to see how short sprints give more control points to the Scrum Team for adapting and steering the project toward a soft landing.  Imagine a 4-month project. How many points of adaptation can we have during this period?  If you have delivered many Scrum projects, you know that it takes 2 to 3 sprints to ‘take off’ and stabilize, whereas the last couple of sprints are used for landing and closing the project. Given that, unless your Development Team are a tight-knit band of veterans, a 5-sprint project will not give you enough time to gain a predictable effort velocity.  Another way of calculating the number of adaptation points in a Scrum project it is to remove the first and last sprint plannings.  By having no previous measure, the first planning is not adapting anything while the last planning is normally used to close things with zero risk. If we look at a 4-month project, it only gives you 2 points of control for 4-week sprints, and 6 points of control for 2-week sprints. Therefore, shorter is better.

In defence of freedom

The flexibility of being able to choose the sprint length is one of the many advantages of Scrum.  For the Scrum Team, choosing and adapting this variable is part of their self-organization, enabling them to balance the increment size with iteration frequency.

In defence of standardization

At the other end of the spectrum, imposing a sprint length has the advantage of synchronizing the sprints, which opens a window of opportunity where floating personnel (employees who are not part of a core team) can hop from one team to another.  It is also a moment where overall progress can be measured simultaneously. That is especially important when we want to be able to follow the progress of projects/programs composed of several teams.

How can we get the best of both worlds?  

By getting rid of 3-week sprints.

If all the teams limit their sprint length to 1, 2 or 4 weeks, it is then possible to synchronize the end of all the sprints at week #4.  Of course, some of the teams will have to adjust their sprint cadence by adding a week or subtracting a week from one of their sprints. After this simple ‘reset’, everybody will reach a synchronized sprint every 4 weeks.

So, unless you want to synchronize your sprints, 3-week sprints are totally fine. Otherwise, they are pure evil.

 

Phillipe Cantin

 

Échec : le chemin le moins fréquenté

J’ai raté 9000 tirs dans ma carrière. J’ai perdu presque 300 matchs. 26 fois, on m’a fait confiance pour prendre le tir de la victoire et j’ai raté. J’ai échoué encore et encore et encore dans ma vie. Et c’est pourquoi j’ai réussi. – Michael Jordan

Je n’ai pas échoué, j’ai trouvé 10 000 solutions qui ne fonctionnent pas. – Thomas Edison

  • Est-ce qu’ils se sont sentis mal? OUI.
  • Est-ce qu’ils ont senti la pression de leurs pairs? Certainement.
  • Ont-ils voulu abandonner, revenir en arrière? Assurément.
  • Ont-ils appris de leurs échecs? Qu’en pensez-vous?

Lors d’un échec, est-ce que revenir en arrière est une solution pour essayer autre chose? Bien non! Car j’ai évolué, je ne suis plus le même. Je ne peux pas revenir dans l’état et l’écosystème d’avant, c’est impossible. Et pourtant, c’est ce que nous faisons tout le temps.

Essayer autre chose est-il vraiment garant d’un succès?

La phrase du gestionnaire « OK gang, on va essayer de faire du ABC » se résume dans la tête des gens : « Pis si cela ne marche pas, on va revenir comme avant. ». « Essayer », est-ce une façon d’annoncer un échec?

Voici un autre chemin possible :

  • Faire quelque chose;
  • Célébrer l’échec;
  • Faire une rétrospective, s’améliorer, se perfectionner;
  • Et revenir à la première étape.

Bref, le faire vraiment. Autrement, mais vraiment. Et cela jusqu’au jour où vous prendrez le succès à deux mains avec fierté, en regardant en arrière pour contempler tous ses alliés d’échecs qui vous ont aidé à grandir.

Je termine avec une phrase d’un vieux sage:

N’essaie pas ! Fais-le, ou ne le fais pas ! Il n’y a pas d’essai. – YODA

Tester du Legacy Code, mission impossible ?

Dans nos accompagnements techniques, nous observons régulièrement des problèmes de Legacy Code, aussi appelé Code Patrimonial. Ces problèmes surviennent notamment lorsque des équipes font un virage Agile et qu’on leur demande soudainement de faire des tests unitaires automatisés. Pas si facile que ça, car le système en question n’a pas été prévu pour des tests unitaires.
C’est ce qui nous a donné l’idée de monter une présentation en abordant le sujet avec les points suivants :
  • Description de quelques techniques pour nous aider à tester le Legacy Code.
  • Comment avoir le droit de travailler sur du code pour le rendre plus facile à travailler?
  • Quelques pratiques et outils afin de s’en prémunir autant que possible, au jour le jour.
Voici les disapositives utilisées:
Cette présentation a été donnée aux dates suivantes:
  • 10 Novembre 2016 – Beer And Learn (Québec)
  • 16 Novembre 2016 – Agile Tour Montréal
Si vous avez des questions ou besoin de plus amples explications, n’hésitez pas à m’écrire.
Karl Métivier
kmetivier@facilite.com

Notre matériel présenté à Agile Tour de Québec 2016

img_3597

Merci chers participants de l’Agile Tour pour votre fort intérêt envers le contenu proposé par Facilité !

Nous sommes flattés par l’engouement autour des conférences et ateliers Passez un test de la vue – outils visuels pour y voir clair présentée par Nicolas Mercier et Christian Savard, Architecture Express pour petits projets par Frédéric Paquet et Éric Lessard et Mon Agilité est plus grosse que la tienne de Jean-René Rousseau. 

 Des ateliers ou conférences comme celles que nous vous avons présentés ne sont un succès que si les participants s’investissent dans l’activité.  Merci à notre auditoire, nous espérons que vous avez tiré des bénéfices à la hauteur de votre implication durant nos séances.

Vous n’avez pas pu assister à notre atelier puisqu’il était complet ou vous avez manqué une de nos conférences ? Nous serions heureux de vous offrir une séance privée ! N’hésitez pas à manifester votre intérêt à Facilité (christian.savard@facilite.com) pour une offre sur mesure. Parlez-en à vos gestionnaires !

Pour ceux qui ont assisté à nos présentations ou ateliers et qui aimeraient consulter le matériel présenté ou obtenir plus d’informations, notez que celui-ci a été mis en ligne ici. Vous y retrouverez les documents de présentation originaux ainsi que les coordonnées des présentateurs afin de leur poser vos questions.

Au plaisir de vous outiller dans vos projets !

Ne copiez pas le modèle Spotify!

crop380w_boy_cheating_on_test

J’imagine qu’on se rejoindra sur le principe, particulièrement dans le contexte de transformation Agile, que « one size does not fit all ». Même si la culture actuelle de nos clients les invite à vouloir standardiser leur façon de faire Agile, en tant que coach il faut être vigilent pour s’assurer que leur niveau de standardisation est suffisamment macro et adaptable pour permettre aux équipes de faire des choix relatif à leur contexte.

J’ai donc bien aimé cet article paru sur InfoQ  cette semaine qui nous invite à ne PAS copier le modèle de Spotify, modèle largement acclamé par la communauté Agile.

https://www.infoq.com/fr/news/2016/10/no-spotify-model

Bonne lecture, et comme dirait nos amis de DAD  « Context count and choice is good »  (sourire)

Passez un test de la vue – Outils visuels pour y voir clair!

Tout d’abord, Nicolas et moi tenions à remercier tous ceux qui ont assisté à notre conférence « Passez un test de la vue – outils visuels pour y voir clair! » que nous avons présentée hier à l’Agile Tour Québec 2016, qui s’est tenu au Centre des congrès de Québec.

Pour ceux qui l’ont manquée, nous vous présentions des outils ainsi que des techniques de conception et de facilitation afin de vous aider à mettre en place des outils de gestion visuels favorisant l’innovation, l’alignement, la créativité et l’engagement.

À la demande de plusieurs, voici les diapositives que nous avons utilisées :

Si vous avez des questions ou besoin de plus amples explications, n’hésitez pas à nous écrire.

Nicolas Mercier
nmercier@facilite.com

Christian Savard
csavard2@facilite.com

Mes notes suite au cours de Daniel Vacanti

danielvacanticlassroom
Avertissement

Ce billet a la pure intention de vous inciter à suivre les formations Intro Kanban et Kanban Avancé de Daniel Vacanti qui se tiendront à Montréal et Québec à la mi-novembre.

Si vous croyez tout savoir à propos de Kanban (comme moi dans l’temps), je vous encourage à lire ce billet jusqu’à la fin. La formation de Daniel Vacanti en mai dernier m’a permis de devenir meilleur dans ma mise en application de Kanban.

J’aimerais donc vous partager les notes que j’avais conservées lors de a formation:

  • If work is piling up, ask the customer to stop.
  • A shorter cycle time gives a shorter feedback loop.
  • Achieve self-improvement in your team by using cycle time. 
  • Spending more time estimating, means spending less time doing the work.
  • To get more done, work on fewer things at once.
  • Focus on the workflow versus the roles.
  • WIP is the biggest influencer of cycle time and throughput.
  • How much will it cost? as a function of how long it will take.
  • Kanban board = Reality board
  • The key insight of Lean is that inventory is perishable. It is not an asset. It is a liability.
  • Policies are helpful when it comes to handling variability.
  • When work is piling up, move the WIP down. 
  • The flow is more predictable if we can throttle the input and output of my Kanban system.
  • The backlog column doesn’t have a WIP Limit, so it’s not considered part of the Kanban system.
  • An expedite process kills your predictability. You have to set the bar high to get into the Expedite lane.
  • Rename the Expedite Lane, switch to Flow Destroyer Lane.
  • Stair steps on CFD are indicative of batch work.
  • 11-12 dots with a good management of WIP Limit to have a good scatterplot.
  • Drive out uncertainty by doing the work.
  • Queue replenishment meeting = Sprint planning.
  • Handoffs is the way known to create columns.
  • 2-tier Kanban board: Workflow within workflow.
  • Bigger epics are sagas, legends and bibles.

Si certaines phrases vous paraissent floues ou incompréhensibles dans la liste précédente, c’est peut-être un signe qu’il reste certaines zones à explorer dans votre connaissance Kanban. Personnellement, je crois que vous avez le meilleur prof Kanban, Daniel Vacanti, pour vous aider à grandir avec cette organisation du travail.

Les 10 meilleurs citations du livre de Daniel Vacanti

danielvacanti

Après avoir lu l’excellent excellent excellent livre Actionable Agile – Metrics for Predictability de Daniel Vacanti, j’aimerais vous partager les 10 meilleures citations du livre.

1. Delay is the enemy of flow.

2. Remember that being predictable is not completely about making forecasts. The bigger part of predictability is operating a system that behaves in a way that we expect it to.

3. Kanban cannot work because there are no commitments. Nothing could be further from the truth. It is just that the approach to commitment is very different than, say, Scrum.

4. The first thing to know about variation is that it will always exist.

5. Think about all the time you have wasted in your life doing estimation. Think about all the time wasting in « pointless » debates of whether a story is a two points or three points. Using these percentiles is a means to get rid of all that. Measuring to get an SLA allows us to adopt a much lighter approach to estimation and planning.

6. If a team follows all of the principles presented in this book, then the SLA can be used as a substitute for many upfront planning and estimation activities.

7. Use your Scatterplot’s percentiles to collaborate with your customers in choosing a Service Level Agreement (SLA) for your process.

8. Predictability is the ability to make a quantitative forecast about a process’s future state.

9. A forecast is a calculation about the future completion of an item or items that includes both a date range and a probability.

10. Whenever uncertainty is involved then a probabilistic approach is necessitated.

11. The older a work item gets, the greater chance it has of aging still more.

12. The second reason is that CFDs (Cumulative Flow Diagram) are for looking backward.

Je sais. Il y en a 12 finalement. Honnêtement, j’ai pris plus de 50 notes dans cet excellent excellent excellent livre. Je me suis arrêté après 12 mais j’aurais pu facilement vous les beurrer ici, vous auriez trouvé ça trop long pis seriez retournés sur Facebook regarder des photos de chats.

By the way, Vacanti sera au Québec dans la semaine du 14 novembre pour donner ses cours Kanban. Le 14 novembre, il donne le cours Kanban Avancé à Québec. Et les 17 et 18 novembre, il sera à Montréal pour donner son cours Intro Kanban. Des formations incroyables à ne pas manquer pour toute personne qui désire monter en compétences avec cette approche.

Bonne lecture!

Les 3 clés de la vélocité : Dynamiser, converger et anticiper

Les clés

Dans ma pratique, je me suis rendu compte que j’utilisais souvent les mêmes leviers pour déverrouiller la vélocité (ou le débit en Kanban)… Dynamiser, converger et anticiper.  Ces 3 clés m’ont souvent suffi et ont souvent été nécessaires.

Elles ont émergé des questions suivantes:

  1. À quoi sert de planifier si le temps de mes équipiers n’est pas passé de manière active et délibérée à contribuer au projet? (Dynamiser)
  2. À quoi sert de se démener si on ne fini jamais rien? (Converger)
  3. Pourquoi faire un plan quand on ne livre jamais? (Anticiper)

Les clés en action

Dynamiser

Dans le contexte de ces clés, dynamiser consiste à transformer la présence simple en une participation active et délibérée.

Quelques questions pour inspirer l’intervention

  • Si un équipier est engagé à temps plein sur le projet, est-ce que son temps est vraiment passé sur le projet ou détourné vers des activités satellites hors projet? (Éliminer/réduire le détournement de ressources)
  • L’équipier a-t-il les outils et le savoir-faire pour faire son travail? (Appuyer et faire grandir)
  • L’équipier est-il mobilisé/énergisé à réaliser le projet? (Partager la mission et la vision, soulever l’intérêt)
  • Est-ce que l’équipe est appuyée pour traiter les éléments bloquants? (Implication du Scrum Master)
  • Est-ce que l’équipe s’auto-organise en vue faire plus et mieux? (Rétrospectives efficaces)

Converger

Dans le contexte des clés, converger consiste à transformer  la participation en résultat.

Quelques questions pour inspirer l’intervention

  • Est-ce que l’équipe s’entend sur un point de départ commun? (La définition de prêt)
  • Est-ce que l’équipe s’entend sur un point d’arrivée commun? (La définition de terminé)
  • Est-ce que l’équipe s’entend sur la finalité de la livraison? (La définition de terminé, au niveau du sprint, livraison, projet etc.)
  • Est-ce que l’équipe s’auto-organise en vue d’atteindre rapidement les définitions de terminé à tous les niveaux?

Anticiper

Dans le contexte des clés, anticiper consiste à préparer le carnet de manière à converger plus rapidement et plus régulièrement, tout en gardant un bon équilibre au niveau du juste-assez et juste-à-temps.

Quelques questions pour inspirer l’intervention

  • Est-ce que le niveau de découpage est propice à un débit rapide? (Petits éléments qui permettent une convergence rapide)
  • Est-ce que l’ordonnancement des éléments du carnet est adéquat? (Éviter les conflits entre récits qui causent des bloquants)
  • Est-ce que la discussion entre le PO et les équipiers permet de faire évoluer le carnet en vue d’une consommation plus véloce de celui-ci?
  • Est-ce que la gestion/gouvernance laisse suffisamment de marge au PO et son équipe en vue de réviser le carnet de manière à favoriser sa consommation de manière plus véloce?

Conclusion

Ces outils mettent plutôt l’accent sur la mécanique. Il serait réducteur de penser que ces clés peuvent combler 100% des lacunes d’une équipe. De nombreux enjeux de collaboration, dynamique organisationnelle, savoir-être, gestion etc. peuvent entrer en ligne de compte pour le succès de l’équipe et méritent l’attention.   Par contre, lorsque l’enjeu en est principalement un de vélocité, ces clés peuvent s’avérer très intéressantes.

La chose que je dis le plus souvent aux équipes aux prises avec un enjeu de vélocité?

Soyons excellents chez nous avant d’essayer de transformer les autres.