(English follows)

L’objectif de cette série d’articles de blogue est de démystifier l’application du cadre Scrum dans un contexte réel où, au final, des compromis sur le cadre sont presque toujours nécessaires.

Introduction

Même si l’on respecte un cadre (ou une approche) Lean-Agile, la simple application de certaines pratiques plutôt que d’autres crée souvent une mésentente entre praticiens et praticiennes. Cette mésentente est décuplée s’il est suggéré de sortir du cadre. Comme exemple, j’ai choisi Scrum, car c’est le cadre Agile avec lequel j’ai le plus d’expérience, bien que j’applique aussi Kanban, Lean-Flow and SAFe.

Voici un petit résumé de mon application de Scrum, afin de communiquer au lectorat les assises d’expériences pratiques qui soutiennent mon analyse. Entre 1999 et 2004, dans des rôles de développeur (full stack), de lead développeur et d’architecte, j’ai commencé à appliquer les principes d’Extreme Programming (XP) ^[1] et à les introduire dans mes équipes. J’utilise Scrum de façon appliquée depuis 2005. Au début, j’utilisais cette pratique dans mes équipes où je jouais un ou plusieurs rôles simultanément tel que développeur, lead, architecte, PO et gestionnaire. Depuis 2014, j’ai principalement un rôle de coaching et de conseiller en Lean-Agile. Dans ce rôle, j’ai aidé plusieurs équipes à livrer de la valeur en Scrum et SAFe-Scrum. Au moment de l’écriture de ce texte, ma dernière utilisation de la boucle Scrum dans le rôle de SM-PO-équipier date de décembre 2021. Avant la première publication du guide Scrum ^[2] en 2010, mes sources de connaissance Scrum étaient des livres (papier) dont « Agile Software Development with Scrum » ^[3] par Schwaber et Beedle. Depuis 2010, je lis les versions du guide Scrum. Aussi, en 2017, j’ai publié le livre « Rally-Point Backlog », dans lequel je partage des principes et pratiques Scrum qui m’ont été très utiles. Au cours de ces 17 années de Scrum, dans plusieurs domaines et contextes différents, je peux dire avec confiance que je n’ai jamais appliqué Scrum deux fois de la même façon et je n’ai jamais appliqué 100 % du cadre Scrum au même moment.

Mise en contexte

Je vous présente ici ma dernière intégration du cadre Scrum, réalisée dans le contexte des escouades de consultants CGI à distance. Les fondements du modèle des escouades CGI sont majoritairement les résultats de la recherche du Dr Forsgren (publiés dans le livre « Accelerate » ^[4]) et des principes Lean-Flow ^[5]. Ceci crée l’environnement minimalement structurant, mesurable et contractualisable à l’intérieur duquel les équipes Scrum ou Kanban peuvent travailler. Si l’on se concentre sur l’aspect Scrum, les éléments méthodologiques documentés dans le modèle sont, comme le Guide Scrum l’indique ^[a][b][c], un ensemble de pratiques, modèles, processus, techniques, tactiques et méthodes. L’évolution du modèle est soutenue par les praticiens et praticiennes qui utilisent le modèle dans leur travail.

Voici des éléments que nous devons prendre en compte lors de l’application de Scrum dans le contexte de ce modèle et en considérant les membres des escouades, les clients et l’organisation (CGI) :

• Assurer un niveau de service en qualité et en quantité, en prenant en compte la variation sur les niveaux de compétences des personnes ainsi que le taux de roulement du personnel
• Uniformiser et appliquer des normes et standards ^[d][e] de développement logiciel et organisationnel
• Encadrer les développeurs juniors et intégrer les nouveaux équipiers
• Créer et entretenir une culture cohésive et engageante de développement logiciel

Après les 16 premiers mois de fonctionnement des 10 à 12 escouades en place, voici les écarts notables constatés avec le cadre Scrum:

1. Il y a une hiérarchie dans l’équipe Scrum.
2. Plusieurs équipiers ont une spécialisation.
3. Les changements, en milieu de Sprint et impactant l’objectif de sprint, sont acceptés.
4. Les projections ne sont pas basées à 100% sur l’empirisme.
5. La décision d’annuler un Sprint n’est pas prise seulement par le PO.
6. Des personnes externes à l’équipe Scrum peuvent influencer la planification de Sprint.

Les 6 prochains articles de cette série couvriront donc chacun de ces écarts.

---

Adapting Scrum — Return on experience 1/7

The objective of this blog series is to examine the application of the Scrum framework in a practical context where, eventually, compromises are almost always necessary.

Introduction

Even if we respect a Lean-Agile framework (or approach), the simple application of certain practices over others often creates discord between practitioners. This discord is multiplied if it is suggested to step out of the framework. As an example, I chose Scrum as I have most experience with this approach over others I have used, like Kanban, Lean-Flow, and SAFe.

Here’s a short overview of my Scrum track record, in order to communicate to the reader the practical experiences supporting my analysis. Between 1999 and 2004, as a full-stack developer, tech lead, and architect, I began applying Extreme Programming (XP) ^[1] principles and introducing them to my teams. I have been applying Scrum since 2005. Initially, I used this practice in my teams where I played multiple overlapping roles such as developer, lead, architect, PO and manager. Since 2014, I mainly assume a coaching and consulting role in Lean-Agile. In this role, I helped multiple teams deliver value using Scrum and SAFe-Scrum. As I’m writing this, my last proper application of Scrum in an SM-PO-Developer’s role was in December 2021. Before the first publication of the Scrum Guide ^[2] in 2010, my knowledge sources were physical books such as “Agile Software Development with Scrum” ^[3] by Schwaber and Beedle. Since 2010, I’ve read all the Scrum Guide versions. Also, in 2017, I’ve published “Rally-Point Backlog”, a book where I share some principles and Scrum practices who served me well over the years. During those 17 years of Scrum, in many application domains different contexts, I can confidently say that I never applied 100% of the Scrum framework at one given time.

Some Context

In this series, I will present my last integration of the Scrum framework in the context of the CGI remote squads. The foundations of the CGI squad model are mostly based on the results of Dr. Forsgren research (published in the book “Accelerate” ^[4]) and the principles of Lean-Flow ^[5]. This creates an environment that is minimally structuring, measurable, and able to be contractualized, inside which Scrum and Kanban teams can work. Looking at Scrum, the methodological elements documented in the model are, as the Scrum Guide indicates ^[a][b][c], a collection of practices, models, processes, technics, tactics, and methods. The evolution of the model is supported by the practitioners using the model for their daily work.

Here are the elements to consider when applying Scrum, in the context of this model and considering the squads’ members, the clients and the organization (CGI):

• Ensure a level of service, both in quality and quantity, considering the varying skill levels of people and turnover rate.
• Standardizing and applying software development and work organization norms and standards ^[d][e].
• Supporting junior developers and integrating of new members
• Creation and maintenance of a cohesive and engaging software development culture.

After 16 months of operations with 10–12 squads, here are the divergences highlighted with the Scrum framework:

1. There is a hierarchy in the Scrum team.
2. Many team members are specialized.
3. Changes, in the middle of a sprint and impacting the sprint objectives, are accepted.
4. Projections are not 100% based on empiricism.
5. The decision to cancel a sprint does not only fall to the PO.
6. People outside the Scrum team can influence the sprint planning

The next six articles in this series will cover each of those divergences.

---

Extraits du Guide Scrum/Extracts from the Scrum Guide ^[2]

[a] “As Scrum is being used, patterns, processes, and insights that fit the Scrum framework as described in this document, may be found, applied and devised. Their description is beyond the purpose of the Scrum Guide because they are context sensitive and differ widely between Scrum uses. Such tactics for using within the Scrum framework vary widely and are described elsewhere.” Section titled “Purpose of the Scrum Guide”.
[b] “Various processes, techniques and methods can be employed within the framework.” Section titled “Scrum Definition”.
[c] “Various practices exist to forecast progress, like burn-downs, burn-ups, or cumulative flows.” Section titled “Scrum Events, The Sprint”.
[d] “If the Definition of Done for an increment is part of the standards of the organization, all Scrum Teams must follow it as a minimum.” Section titled “Scrum Artifacts, Increment”.
[e] “If there are multiple Scrum Teams working together on a product, they must mutually define and comply with the same Definition of Done.” Section titled “Scrum Artifacts, Increment”.

Références/References

[1] Wells D., Extreme Programming, Online link: http://www.extremeprogramming.org
[2] Sutherland J. Schwaber K., The Scrum Guide, November 2020 version, Online link: https://scrumguides.org/scrum-guide.html
[3] Schwaber K. Beedle M., Agile Software Development with Scrum, Prentice-Hall, 2002
[4] Forsgren N. Humble J. Kim G., Accelerate, Building and Scaling High Performing Technology Organizations, IT Revolution, 2018,
[5] Reinertsen D., The Principles of Product Development Flow, Second Generation Lean Product Development, Celeritas Publishing, 2009