Une grande partie de l'histoire du Scrum a été écrite sur le blog Scrum de Jeff Sutherland il y a près de 20 ans. Il est peut-être encore accessible à l'adresse suivante jeffsutherland.org/scrum mais elle doit être transmise à scruminc.com pour que l'histoire ne soit pas perdue.
Aujourd'hui, de nombreux praticiens ne comprennent pas les origines de la méthode Agile, qui a commencé avec les modèles d'organisation et le Scrum. Les travaux sur les modèles et le Scrum ont été partagés avec Kent Beck pour lancer l'eXtreme Programming et la réunion du Manifeste Agile a rassemblé les fondateurs de XP et du Scrum ainsi qu'un groupe de consultants et de leaders d'opinion. Il n'y avait pas d'autres cadres largement déployés à l'époque, à l'exception peut-être de DSDM en Europe, qui est aujourd'hui largement remplacé par Scrum.
Ce billet de 2003 a été cité par Jim Coplien dans sa présentation de 2008 sur la l'histoire de Scrum en tant que modèle d'organisationqui vaut également la peine d'être lu.
Blog de Jeff Sutherland sur le Scrum : 11 mars 2003
Voici quelques commentaires sur les besoins d'un Scrum, motivés par des messages sur la liste scrumdevelopment@yahoogroups.com. Je parle ici d'entreprises de produits. Il existe des parallèles pour le développement interne des SI.
Les Scrum avec lesquelles je travaille s'occupent des modifications des exigences au cours de l'itération du sprint. Le chef de produit (en tant que Product Owner) fait partie de la Scrum pour cette raison. La Scrum de développement ne définit pas les exigences initiales, à moins qu'il ne s'agisse d'une Scrum de marketing produit.
Nous avons toujours commencé un développement Scrum avec un code fonctionnel. Ainsi, un Scrum est conçu pour améliorer une base de code. Les spécifications fonctionnelles fournies par le marketing doivent être basées sur des prototypes en cours d'exécution montrés à des clients ou à des clients potentiels qui conviennent que c'est ce qu'ils veulent pour la prochaine version. Il peut s'agir d'un seul sprint ou de plusieurs pour arriver à la version.
Mes clients actuels sont des médecins et ils n'ont pas le temps de se rencontrer dans le cadre des Scrum quotidiennes, de sorte que les médecins chargés du marketing des produits doivent les remplacer. Les médecins m'ont appris qu'un produit NE SERA PAS UTILISÉ, à moins qu'il ne réponde soigneusement à leur flux de travail, qu'il soit extrêmement réactif et qu'il puisse être personnalisé rapidement lorsqu'il présente des lacunes. Étant donné que l'échec est immédiat en raison du refus du médecin d'utiliser le produit, celui-ci doit être presque parfait du premier coup et corrigé dans le mois qui suit, sinon vous échouez et devez trouver un autre client.
Cette discipline rigoureuse exigée par l'environnement médical m'a fait comprendre que tous les projets devraient être menés avec cette discipline. Dans le cas contraire, l'échec peut prendre plus de temps, mais le système ne se vendra pas bien ou ne sera pas bien utilisé. Je pense donc que mes commentaires s'appliquent à d'autres environnements. Vous ne gagnerez pas gros si vous ne le faites pas.
En outre, si le marketing produit ne connaît pas clairement les besoins des clients (ou du marché), la direction générale ne le sait pas non plus. Si la direction générale ne soutient pas un produit, les priorités seront confuses. Cela détournera l'attention et les ressources du Scrum et réduira les chances de succès.
Si le marketing produit ne peut pas fonctionner, le développement doit s'en charger. Ils ne le feront pas aussi bien et ne doivent pas le traiter comme un code de découpage. Ils doivent sortir du bureau, faire des études de marché et se rendre dans les bureaux des clients ou amener le client à eux. Ils doivent soutenir les ventes et être présents lorsque le client achète ou n'achète pas et comprendre pourquoi il achète ou n'achète pas. Ils doivent abandonner leur travail de développement suffisamment longtemps pour définir les cas d'utilisation, obtenir une interface utilisateur que les clients aiment et clarifier le flux de travail du client et la logique d'entreprise. Lorsque cela est fait, ils peuvent penser à coder le produit.
Dans le cadre d'un nouveau projet sans code existant, j'ai vu un développeur Scrum travailler sur un prototype pendant une semaine et en faire sa base de code.
La tâche consiste alors à affiner la base de code pour mieux répondre aux besoins du client. Si cela n'est pas clair, les programmeurs ne devraient pas écrire une ligne de code. Chaque ligne de code coûte de l'argent à écrire et encore plus d'argent à supporter. Il vaut mieux que les développeurs surfent plutôt qu'ils n'écrivent du code dont ils n'auront pas besoin. S'ils écrivent du code qui n'est finalement pas utilisé, l'entreprise paiera pour ce code pendant toute la durée de vie du système, qui est généralement plus longue que la vie professionnelle du développeur. Si les développeurs allaient surfer au lieu d'écrire du code inutile, ils s'amuseraient, et l'entreprise aurait un système moins coûteux et moins de maux de tête à entretenir.
Lorsque le besoin du client est clair, écrire les lignes de code minimales pour répondre au besoin défini. C'est la méthode de travail XP (qui était la pratique de l'équipe originale de Scrum) et devrait être la méthode de travail de Scrum.
Cela dit, le marketing produit devrait être géré comme un Scrum de Product Owners (aujourd'hui appelé Metascrum). J'ai déjà dirigé une équipe de cadres supérieurs (PDG, vice-président, vice-présidents et directeurs du marketing produit) en tant que Scrum du marketing produit. Avec un déjeuner de travail par semaine, ils ont apporté plus de changements et d'innovations aux produits en six mois qu'ils n'en avaient fait au cours des cinq années précédentes. Ce Scrum a également contribué à la création d'entreprises Internet prospères telles que Lycos et Altavista, une société de recherche de premier plan avant l'existence de Google.
French 
English 
Spanish