Cet article est réellement le premier à présenter Scrum, c’était en 1995. Petit détail que j’ignorais, Ken Schwaber l’a mis en oeuvre pour le développement de Delphi ! Déjà l’auteur présente son approche comme étant « boite noire » et empirique, bien adapté au développement de systèmes complexes. Et oui, Scrum est bien en rapport avec le Rugby !
Bien sûr, à cette époque, il n’était pas encore question du mot « agile ». Ken Schwaber situe Scrum comme une évolution des procesus itératifs, non comme une disruption.

Quand il parle du développement logiciel, c’est toujours à la notion de complexité que revient l’auteur. Il la définit comme suit :

Complexité = f(dev. environnement var. + target env. var.)

Toutes ces varaibles changeant par ailleurs au cours du projet.

Quand il compare Scrum aux procesus classiques, Ken Schwaber ne se contente pas de le comparer au cycle en cascade, déjà il met en évidence que la nature intrinsèque du modèle en spirale de Boehm est identique au cycle en V en cela que l’approche reste linéaire par essence ! Il pousse même ce raisonnement vers les processus itératifs dont il met en évidence qu’ils restent aussi « linéaires ». Une démarche qui reste incomprise de beaucoup plus de 20 ans après ! Car toutes ces méthodes sont basées sur l’illusion que le processus de développement peut être défini !

La méthodologie Scrum

Dans cet article, Ken Schwaber présente Scrum comme structuré en 3 phases

• Planning et architecture système
• Sprints
• Clôture

Une structure que l’on ne retrouvera guère par la suite. Si la 1ère et la dernière sont des phases « définies », l’auteur qualifie la phase des sprints « d’empirique ». Notons aussi que l’auteur inclut dans la phase de clôture un « pré-release testing »… qui va à l’encontre du « potentially shippable » dont on parle aujourd’hui (et dont il ne parlait pas à l’époque) ! Par contre la durée des sprints est présentée simplement comme allant de 1 à 4 semaines, et non 30 jours (ou moins) ! Bref, comme on dit, c’était mieux avant !

A cette époque, on ne parle pas non plus encore « d’inspect and adapt » et donc encore moins de rétrospective !

Au niveau de la structure d’équipe, on ne reconnait guère la description actuelle : un management et des équipes de 3 à 6 personnes (donc l’équivalent de feature teams), responsables de sous-ensembles du backlog ! On ne parle pas encore de Product Owner.

Une emphase importante est mise sur l’utilisation des technologies objet, qui apportent la flexibilité nécessaire à une mise en oeuvre réussie de Scrum.

Les estimations se font en utilisant les points de fonction. Mais … Ken Schwaber met en garde sur la productivité qui est au moins le double du standard ! Sacré garnement !

Scrum an tant que processus

Dans cette partie, l’auteur rentre d’avantage dans la théorie des méthodes de développement, comment elles se définissent par le biais de métamodèles et en quoi il est important de reconnaitre si elles sont définies ou empiriques. Cela permet à l’auteur de revenir sur l’inadéquation des processus théoriques par rapport aux systèmes complexes sous un autre angle.

Et de conclure cet article !