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