Au fur et à mesure que les 20th anniversaire du Scrum, je suis frappé par la façon dont l'idée s'est répandue. Des dizaines de milliers de personnes sont titulaires d'un certificat Scrum. Des milliers d'entreprises à travers le monde utilisent Scrum. Le ministère américain de la défense dispose d'un mandat pour être Agile. Groupe Gartner dit que la cascade est morte. Qu'est-ce qu'on fait ensuite ?
L'avenir est Scrum en dehors de l'informatique. Récemment, nous avons mentionné des initiatives telles que eduScrum Le Scrum apporte de la valeur à la salle de classe en motivant les étudiants, en encourageant l'auto-organisation autour des objectifs d'apprentissage et en leur apprenant à travailler en équipe. Le Scrum dépasse également le cadre des technologies de l'information dans un nombre croissant d'entreprises.
Historiquement, le développement était toujours "le problème" : il était en retard, dépassait le budget et produisait trop de bogues. Maintenant que le développement n'est plus le problème, nous voyons d'autres départements se demander : "Pourquoi ne pouvons-nous pas utiliser cette chose Scrum ?" J'en ai récemment vu un bel exemple lors d'une visite chez un client.
Dans cette entreprise comme dans beaucoup d'autres, les logiciels n'étaient jamais livrés à temps. Malgré de nombreux diagrammes de Gantt, personne ne savait vraiment quand le produit allait être terminé. La direction n'était pas contente. La situation était pénible. Puis, il y a deux ans et demi, certains de leurs collaborateurs en Europe ont entendu parler de Scrum, et les responsables du monde entier se sont réunis pour trouver un moyen de piloter Scrum. Lentement et régulièrement, des équipes Scrum ont été constituées. Certaines ont doublé leur vitesse, mais Scrum n'était pas une solution miracle. Les équipes de développement se sont heurtées à des obstacles liés aux dépendances avec des départements de la chaîne de production qui n'étaient pas concernés par le Scrum. Bientôt, les "vagues" de Scrum ont commencé à prendre de l'ampleur.
La première vague a touché la production, car les équipes avaient besoin de nouveaux équipements pour tester le code plus rapidement. La production s'est impliquée et a réduit le délai d'exécution des équipements de test de 2 mois à 2 semaines, et les développeurs ont pu découvrir des bogues pendant le sprint. Une autre vague a touché l'ingénierie mécanique lorsque des problèmes de qualité de l'équipement ont été découverts au cours des tests. Le personnel de l'ingénierie mécanique a reçu un retour d'information immédiat sur les problèmes et a travaillé avec le service Fiabilité pour les résoudre. C'est ainsi qu'a été créé le "Scrum technique des Scrum" afin de réunir tous ces départements de manière plus formelle.
Aujourd'hui, la Technical Scrum of Scrums se réunit tous les jours après les réunions de préparation des équipes de développement. Les représentants des équipes (cochons) rencontrent les poulets, les responsables de l'ingénierie électrique, de l'ingénierie mécanique, de la qualité et de la fiabilité. Certains de ces autres départements ont commencé à intégrer dans leur rythme quotidien une réunion d'état devant un tableau Kanban.
Lorsque les équipes de Scrum parviennent à résoudre des problèmes informatiques difficiles, nous voyons de nombreux exemples de ce type de collaboration interdépartementale. Elle favorise le sentiment d'un objectif commun dans la construction d'un produit, crée un but plus commun et fait tomber les barrières du "nous" contre "eux". C'est l'avenir de Scrum.
French 
English 
Spanish