Devops for Growth

Ce guide comprend trois chapitres :

• « Comprendre l’attente du client »

• « Visualiser le challenge et les problèmes »

• « Trouver les leviers de l’amélioration »

Chaque chapitre est organisé de la façon suivante :

• Une description des pratiques agiles sur le thème abordé.

• Trois cas réels d’équipes agiles ayant intégré le management lean dans leurs pratiques. Ils décrivent leur contexte, les exercices qu’ils appliquent, et ce qu’ils y gagnent. A la fin de chaque cas, nous analysons et développons les principes lean mis en œuvre.

• Une description des pratiques lean sur le thème du chapitre.

• Les « premiers pas » que nous proposons de mener pour se lancer.

• Des références de lecture pour aller plus loin.

Bonne lecture et du succès dans vos expérimentations !

The 4-Part Scrumban Kickstart Event

The first step to using this adaptive approach is to run a Kickstart Event, a meeting in which the team will nail down the foundational elements of Scrumban so they can start using it to manage their work.

Like Kanban, Scrumban is designed to fit within your current work management approach, which means you don’t have to change anything about how you work before you implement it.

An Agile coach can guide you through an intensive Kickstart that includes exercises and detailed walkthroughs of all the intricacies of Scrumban,  but if you want to handle it on your own you can boil it down to just four steps:

1. Visualize the Workflow
2. Identify Work Types & Build the Backlog
3. Set Preliminary WIP Limits
4. Schedule Major Cadences

1. Scrumban doesn’t limit Work in Progress (WIP) by time. Instead, it limits WIP for each stage. This resolves the team composition issues and makes swarming natural. Swarming in agile is the act of coming together and getting a task done quickly and efficiently.

3. Teams can bring on board stories of varying sizes. They do not have to adjust sprint boundaries if there is an unplanned change in the team composition, say someone falls sick and takes 2 days off during the sprint.

4.  

5. Scrumban aims at maintaining a continuous flow of work. This means once you’ve pushed a story into various phases, the remaining work is completed using the pull approach.

6.  

7. Continuous improvement means issues raised by the team can be brainstormed and resolved soon after.

8. In scrumban you can visualize the steps in your workflow. This makes it easy to identify areas of improvement and eliminate the not-so-useful steps.

9. The project progress is easier to explain to the stakeholders and others in the organization, as you can map your workflow and process.

10. Scrumban saves time by using the planning on demand technique. Instead of having daily meetings or spending hours on task estimations, Scrumban teams plan only when the need arises. This gives them additional time to invest in project development. The time thus saved is invested in quality control and product development.

11. Scrumban increases waste minimization efficiency. Using flow diagrams and in-process buffers, Scrumban highlights the weaknesses and opportunities of the process. This way the team can eliminate anything which is not a value add for the customer.

12. In Scrumban environment, the level of productivity is defined using Lead Time and Cycle Time. Cycle time is the timeframe between starting work on a story to completing it. Lead time is the total time for which a story sits on Scrumban board.

1. Since Scrumban utilizes the pull system to address technical tasks and other priority tasks, team foundation is strengthened and team building process is accelerated.

1.  

2.  

3.  

4. No need to set rigid estimations in Scrumban, especially during initiation. Instead, you can put them up dynamically depending on the outputs of daily scrum.

La principale différence est que seules les US transitent du début à la fin du board, et on ne rend pas visible leurs check lists de tâches internes. L’intérêt est de ne pas ajouter des détails spécifiques à l’US qui nuiraient à la clarté nécessaire pour que l’équipe prenne des décisions efficaces au quotidien.

1. La première conséquence est de suivre un état par US. Donc au lieu de se dire “J’ai effectué 70% de l’US” ou “j’ai fait 7 taches sur 10”, on ne s’attarde que sur la colonne dans laquelle il est, ou s’il présente des points de blocage. L’équipe a ainsi une vision plus synthétique de l’évolution de la fonctionnalité.
2. La deuxième conséquence est que les estimations – en temps, en taille de t-shirt ou en point de complexité – sont définies à un niveau de granularité “US” et non pas par tâches.
3. Enfin, les développeurs sont responsabilisés sur l’ensemble du périmètre fonctionnel de l’US et pas uniquement sur l’un de ses aspects techniques. (Ex: IHM uniquement, Back uniquement …)

Dès lors, le process de l’équipe est modélisé de façon générale – et non spécifique par ticket – en définissant chaque colonne par laquelle l’US devra transiter obligatoirement.

Ajouter des colonnes dans le board visuel c’est formaliser visuellement les étapes réelles du processus par lesquelles les user stories passent.

Une colonne correspond idéalement à un type d’activité qu’un collaborateur peut effectuer seul ; le passage d’une colonne à une autre formalise le fait que l’US passe à un autre état et est prise en charge par une autre personne. Cette transition répond à une règle, un contrat formalisé et accepté par l’équipe, appelée “Definition of Done” (ou DoD).

Tous les projets sont différents, et à fortiori le process et donc les colonnes du board sont généralement spécifique à chaque équipe projet. Néanmoins, voici les colonnes qu’on a l’habitude de voir lorsque l’équipe étend le traditionnel “Todo – Doing – Done”