THE ENTERPRISE AND SCRUM, KEN SCHWABER

En plus d'un an, nous avons beaucoup travaillé sur la mise en pratique de Scrum. Notamment, nous cherchons des solutions pour notre équipe qui monte encore en charge. Nous sommes dans le cadre d'un gros projet de développement.

Alors, je me suis beaucoup documenté sur Scrum et avec Nicolas Blanpain nous avons même effectué la formation certifiante ScrumMaster.

J'ai commencé par la lecture de Agile Software Development With Scrum puis de Agile Project Management With Scrum. Je viens de clore la trilogie de Ken Scwhaber avec The Enterprise And Scrum.

LA FOLIE DES GRANDEURS?

Ken a un sacré appétit. Il voit grand. De plus en plus grand.
Etape 1: Scrum permet de bien piloter un développement de logiciel (Agile Software Development With Scrum);
Etape 2: Scrum permet de bien piloter un projet. Scrum ne se limite plus au développement de logiciels. (Agile Project Management With Scrum);
Etape 3: Scrum permet de bien piloter une entreprise. (The Enterprise And Scrum).
La progression est notable.

AGILE WORLD MANAGEMENT WITH SCRUM?

Et bien, je dois avouer que la gestion d'entreprise avec Scrum m'a ennuyé. Je n'ai pas accroché. Je suis fan de Ken Schwaber et de son style mais il ne m'a pas convaincu. Je ne dois pas être la cible type de ces propos. Pour autant, je ne regrette pas la lecture de ce livre. Au lieu de m'étendre sur mes déceptions je vais me concentrer sur ce qui m'a plu.

QU'EST-CE QUI FREINE SCRUM?

Un chapitre est dédié aux comportements qui minimisent le retour sur investissement de l'application de Scrum. J'ai pu (malheureusement) reconnaitre dans mon expérience chacun des points identifiés. Je dois commencer à me faire vieux ... Notamment, j'ai bien reconnu l'engagement défiant les lois de la nature. Plus concrètement, une équipe identifie le restant à faire. L'équipe mesure et confirme sa vélocité sur plusieurs itérations. Mathématiquement, l'équipe voit qu'elle ne peut tenir le délai avec avec le contour souhaité par le client. Alors le management pousse à coup de "allez, on se retrousse les manches et on va réussir". Et bien non, on ne peut s'engager en défiant les lois de la nature. Cette attitude mène directement au point suivant.

LA DETTE TECHNIQUE

Dans ses conférences (chez Google et Agile 2006), Ken Schwaber explique comment une organisation peut accumuler une dette technique et se saborder en essayant d'être trop ambitieuse sur sa vélocité. Un chapitre du livre et consacré à ce sujet. En deux mots: l'équipe s'engage (ou est poussée à d'engager) au delà des lois de la nature. Pour tenir les délais l'équipe lâche sur ce qui ne se voit pas : la qualité. Cette réaction marche à très court terme. Par contre, à moyen et long terme la dette technique accumulée immobilise le développement.

SCRUM ET LES PRATIQUES TECHNIQUES

C'est le grand sujet du moment: Scrum n'est pas efficace sans l'ajout de sérieuses pratiques techniques. Ken Schwaber doit être lassé d'entendre cela car il insiste souvent sur le fait que tout incrément doit être potentiellement livrable. Cet objectif ne peut être tenu que si de solides pratiques techniques sont en place.

L'ORGANISATION DE GRANDES EQUIPES

J'ai retenu de bons conseils pour l'organisation de grosses équipes en petites sous-équipes Scrum. Pour minimiser les dépendances, les sous-équipes doivent produire des fonctionnalités orthogonales. Par contre, cela implique qu'aucune équipe n'est réellement responsable de la production d'un incrément de produit complet incluant toutes les fonctionnalités développées dans le sprint par les sous-équipes. C'est pourquoi Ken Schwaber recommande d'utiliser une sous-équipe Scrum chapeau ayant une vision produit complet. Cette équipe comprend le Product Owner du produit complet ainsi que toutes les compétences nécessaires pour transformer les fonctionnalités développées dans le sprint en un produit complet. Par exemple, cette équipe peut être responsable des moyens d'intégration et de recette du produit complet.

SCRUM POUR LES PRODUITS CRITIQUES

Dans le cadre du développement de logiciels critiques, Ken Schwaber recommande une pratique que nous appliquons déjà depuis plusieurs années. Chaque incrément doit être livré avec une traçabilité des exigences à jour.

EN CONCLUSION

Finalement, je pense avoir bien fait de lire ce dernier livre de la trilogie. Je vais essayer d'en appliquer certaines recommandations concernant l'organisation des grosses équipes. Par contre, je vais désormais me remettre aux livres abordant des sujets techniques! C'est parti avec le pavé sur le remaniement des tests xUnit.