---

Qu’est-ce qui peut provoquer le chaos et la frustration avant Scrum ? La réponse pourrait vous surprendre !

Pour mieux comprendre l’influence de Scrum sur nos pratiques de génie logiciel et nos entreprises, examinons une journée dans la vie d’un projet logiciel.

Je souhaite donc évoquer brièvement un ancien projet logiciel, avant l’adoption du cadre Scrum de développement et de livraison dans nos organisations.

Quelques jours avant d’écrire ces lignes, nous avons déjeuné avec un ancien collègue avec qui nous travaillions il y a près de 20 ans.

Marcus a obtenu sa certification Scrum Master et certification Scrum Product Owner auprès de International Scrum Institute™. Il travaille aujourd’hui comme Scrum Master dans l’un des principaux éditeurs de logiciels de gestion de projets agiles.

Marcus accompagne désormais une équipe Scrum agile dont les membres sont répartis dans différents lieux à travers le monde.

Pendant le déjeuner, Marcus a reconnu que les équipes Scrum agiles distribuées rencontrent de nombreux défis courants. Il a notamment cité les problèmes suivants dans son projet logiciel :

• Des styles de travail différents entre membres de l’équipe Scrum,
• Les décalages horaires,
• Les incompatibilités culturelles, et
• Les contraintes linguistiques.

Malgré ces difficultés, Marcus a ajouté que mener un projet logiciel avec Scrum agile était plus agréable, productif et enrichissant que notre façon de travailler il y a 20 ans. Il comparait cela à l’époque où nous n’utilisions pas les processus Scrum de développement et de livraison de logiciels.

Cette déclaration était un témoignage de poids en faveur de Scrum, venant d’un responsable, Scrum Master et Product Owner très accompli et expérimenté.

Merci, Marcus !

Nous lui avons ensuite décrit un ancien projet logiciel, antérieur à notre adoption de Scrum. Je suis certain que de nombreux Scrum Masters reconnaîtront des expériences similaires dans leurs projets avant l’obtention de leur certification.

À la fin des années 1990, nous faisions partie d’un groupe de génie logiciel chargé de créer une infrastructure à clés publiquesbasée sur des cartes à puce. Celles-ci protégeaient les clés privées des membres de l’infrastructure ; les clés publiques associées et leurs certificats étaient librement distribués, comme l’indique leur nom.

À l’époque, il s’agissait déjà d’un projet informatique relativement complexe, exigeant plusieurs équipes interdépendantes de génie matériel et logiciel. Nous devions mener d’importants travaux de recherche et développement (R&D) pour construire un système matériel et logiciel pleinement fonctionnel.

Rappelons que, dans ce projet, nous n’utilisions pas encore le concept de produit minimum viable (MVP) pour expérimenter, créer, apprendre et expérimenter à nouveau.

Sans Scrum, créer une infrastructure aussi sophistiquée, composée de nombreux éléments matériels et logiciels, représentait un véritable défi.

Voici trois difficultés majeures que nous rencontrions sans Scrum Masters ni personnes titulaires d’une certification Scrum Master dans nos équipes.