L'automne dernier, j'ai rendu visite à certains des plus grands acteurs technologiques de la Silicon Valley (PayPal, Twitter, Salesforce, Wallmart.com, etc.). Premièrement, les gens, principalement les dirigeants, voulaient savoir comment faire évoluer leurs implémentations Scrum ; et deuxièmement, les équipes ne faisaient pas de tests au sein du Sprint.
Je retourne dans la vallée à la mi-février pour enseigner à la fois au public et au public. CSM et CSPO ainsi qu'un cours d'une journée Atelier de mise à l'échelle et j'ai l'intention d'aborder ces deux questions de front.
Mise à l'échelle: De plus en plus de cadres de mise à l'échelle sont mis en ligne chaque jour. Je trouve la plupart d'entre eux trop normatifs et limités dans leur efficacité. Toutefois, des cadres comme SAFe constituent un bon point de départ pour les entreprises dont la mise en œuvre est très récente.
Il est important de se rappeler que le Scrum a été conçu pour s'adapter. La première fois que j'ai fait évoluer des équipes Scrum chez IDX au milieu des années 90, c'est devenu très clair. Scrum est basé sur une architecture modulaire ou orientée objet. Elle permet à plusieurs équipes de travailler simultanément sur tous les modules sans effet d'entraînement. C'est ce qu'on appelle tout-en-un-Scrum et c'est le modèle d'équipe mis en évidence par Nonaka et Tachieuchi dans leur article de la HBR qui a inspiré Scrum. Une Scrum d'entreprise vraiment efficace doit être conçue de manière modulaire. L'équipe Scrum Inc. a mis au point un cadre échelonné qui permet aux entreprises de brancher et de retirer les modules dont elles ont besoin en fonction de leur contexte spécifique.
Quel est votre contexte ? Êtes-vous dans une grande industrie mature comme un entrepreneur gouvernemental ? Ou êtes-vous un éditeur de logiciels prospère qui sent l'innovation pointer le bout de son nez ? En fonction de votre vision, de vos besoins et de votre secteur d'activité, vous souhaiterez probablement donner la priorité à certains aspects de la mise à l'échelle plutôt qu'à d'autres.
Test à l'intérieur du sprint: L'aspect le plus important de Scrum est sans doute la boucle de retour d'information. L'équipe présente un logiciel fonctionnel à toutes les parties prenantes à la fin du sprint. Les parties prenantes l'essaient et donnent ensuite à l'équipe un retour d'information sur les améliorations possibles. L'amélioration continue est vraiment l'objectif final ici, donc sans logiciel fonctionnel, le processus Scrum s'effondre.
Il faut qu'il fonctionne pour obtenir un retour d'information. Vous ne saurez pas qu'il fonctionne tant que vous ne l'aurez pas testé.
Si vous ne testez pas pendant le sprint, vous n'obtiendrez pas de retour d'information de la part de vos clients et parties prenantes lors de la revue de sprint. Vous avez besoin de ce retour pour évaluer ce qu'ils aiment et ce qu'ils n'aiment pas, et pour apporter des changements rapidement.
Les tests sont difficiles et beaucoup d'équipes n'ont pas l'impression d'avoir les compétences ou l'opportunité de tester dans le cadre du Sprint. Faites entrer des testeurs dans l'équipe. Utilisez des outils prêts à l'emploi et développez un régime de test de manière incrémentale. Avec des objectifs clairs et une équipe motivée et concentrée, les tests peuvent être effectués avant la révision.
-- Jeff Sutherland
French 
English 
Spanish