Collaboration spéciale

Dave West, Product Owner de Scrum.org

DaveSquare Dave West est le Product Owner à Scrum.org. Souvent invité à titre de premier conférencier, il est l’auteur de nombreux articles. Il est aussi l’auteur du livre acclamé par le public : Head First Object-Oriented Analysis and Design. Il a dirigé l’élaboration du processus RUP (rational unified process). Il a par la suite travaillé avec Ivar Jacobson à la direction de la division nord-américaine d’Ivar Jacobson International en plus de diriger la pratique de livraison de logiciels chez Forrester Research à titre de vice-président et de directeur de recherche. Avant son arrivée à Scrum.org, il était le directeur de produit chez Tasktop où il était responsable de la gestion, de l’ingénierie et de l’architecture des produits.

 

Le 18 octobre 1995, dans le cadre de la conférence Object-Oriented Programming, Systems, Languages & Applications (OOPSLA)1, Ken Schwaber présentait une approche de livraison de logiciels nommée Scrum. Son texte jetait alors les bases d’un mouvement qui allait radicalement changer la façon de livrer les logiciels dans le monde entier. Ainsi, en supposant que 18 millions2 de personnes œuvrent dans la livraison de logiciels, et que 90 % des équipes3 se réclament de l’Agilité sous une forme ou une autre, Scrum étant présent dans 70 %4 des cas, c’est plus de 11 millions de personnes qui utilisent Scrum, au moins en partie. Et même si ces chiffres semblent très gros, il reste que Scrum est devenu la norme de facto dans l’organisation des équipes et la livraison des logiciels. Comment ne pas parler de succès?

Pour bien des gens, Scrum n’a pas tenu promesse

Ken Schwaber, cocréateur de Scrum, y va d’un point de vue intéressant : « Scrum a connu plus de succès que je n’aurais imaginé, mais je suis encore déçu par la plupart de ses implémentations. »

Cette différence entre le succès d’adoption et la manière dont Scrum est adopté faisait l’objet de mon discours présenté conjointement avec Ken au Scrum Day London5. Nous y décrivions les problèmes liés aux implémentations de Scrum :

 

  1. Le taux d’échec ou de difficulté des projets continue d’avoisiner les 60 %.
    Même si les projets Agiles continuent d’avoir trois fois plus de chances de réussir que les projets en cascade, l’amélioration véritable semble toujours utopique. Au cœur de Scrum se trouve la notion que les développeurs de logiciels professionnels se concentrent, à l’aide d’une approche empirique, sur ce qui importe pour créer une relation différente avec les clients et les intervenants, relation qui en retour engendre plus de succès dans les projets, produits et logiciels.
  2. Un logiciel terminé n’est pas vraiment terminé.
    Comme en témoignent la livraison continue et les mouvements DevOps, pour la majorité des organisations, un
    logiciel n’est pas « terminé » durant un sprint, mais requiert d’autres actions avant de passer à l’étape de la production. En fait, les développeurs de logiciels possèdent plus de définitions du terme « terminé » que les Inuits n’ont de mots pour décrire la neige. Scrum et l’Agilité consistent en des livraisons fréquentes de logiciels fonctionnels à des clients qui donnent une rétroaction. Et lorsque Scrum utilise le terme « fonctionnel », il signifie « aussi près que possible de la production ». Une production qui, idéalement, procure une rétroaction à l’équipe.
  3. Le « cascado-Scrum » est encore une réalité.
    En tant qu’analyste, j’ai inventé le terme « cascado- Scrum6  » pour décrire la réalité entourant l’adoption de l’Agilité par la majorité des grandes entreprises de TI. Et la tendance se poursuit. Ainsi, une approche comme le Scaled Agile Framework ou SAFe (Agilité dans un cadre étendu), bien que je la déconseille, s’inscrit dans cette mouvance cascaco-Scrum, où Scrum est confiné à de petites équipes, faisant que les entreprises ne profitent pas des avantages de l’Agilité opérationnelle.
  4. Tout le monde prétend faire du Scrum.
    Mais le manque de régularité et de partage d’information engendre de la confusion et réduit les valeurs. Scrum gagnant en popularité, de plus en plus de personnes le pratiquent. Ce qui est bien, en autant qu’elles le pratiquent pour vrai. Scrum est un cadre de travail léger qui permet de la flexibilité, mais tout ce qui est léger n’est pas nécessairement Scrum. Le Guide Scrum procure une définition approuvée et définitive de ce qu’est Scrum, mais bien des gens ne l’ont pas lue et ne l’appliquent pas. Des consultants ont ajouté plusieurs bonnes choses à leur manière d’appliquer Scrum, mais ces ajouts l’ont complexifié et ont engendré de la confusion. Il est donc pratiquement impossible de s’assurer que les gens « de la rue » qui disent connaître Scrum ont une vision cohérente de ce dont il s’agit.

En examinant ces quatre problèmes au regard des 20 prochaines années, notre communauté doit travailler à améliorer l’adoption de Scrum par des évaluations, aider les organisations à arriver plus vite à un produit « terminé », étendre la pratique de Scrum dans l’entreprise sans toutefois tomber dans la cascade et favoriser une meilleure connaissance de Scrum.

L’évaluation doit porter sur la valeur, pas sur la rapidité

Les graphiques d’avancement et de rapidité sont d’excellents outils pour améliorer le rythme de travail ainsi que l’estimation et la planification. Mais ils ne font pas porter les efforts sur le succès du produit et son adoption professionnelle. L’Evidence- Based Measurement (EBM) consiste en un ensemble d’idées développées par Ken Schwaber, encourageant les organisations à se concentrer sur la valeur. L’EBM focalise, en effet, sur trois dimensions : la valeur actuelle, le délai de commercialisation et la capacité d’innover. En tenant compte de la valeur, non seulement la relation change entre les équipes Scrum, le Product Owner et les intervenants, mais le changement des items du carnet de produit, la priorisation, l’élaboration de rapport et les revues de sprint sont aussi encouragés.

Terminé signifie vraiment terminé, pas presque terminé

Au cours des 21 dernières années, l’expression « potentiellement livrable » a permis aux professionnels de donner leur propre définition au terme « potentiellement ». À l’origine, sa signification devait permettre au Product Owner de décider si un logiciel pouvait être livré, pas d’ajouter de la flexibilité à la définition de terminé ni de permettre à un logiciel non livrable de faire partie de l’incrément. Ajoutez à la confusion que l’incrément et la revue de sprint sont pris pour un processus à paliers7, et le logiciel ne sera pas livré régulièrement par l’équipe Scrum.

La livraison continue et le DevOps sont deux mouvements qui encouragent les équipes à intégrer les capacités de publication et d’opérations et à livrer du logiciel plus fréquemment. Ces mouvements ne sont pas différents de Scrum, mais leurs pratiques associées doivent être intégrées à la façon d’implémenter Scrum, en entourant le processus empirique central de Scrum de pratiques d’ingénierie modernes.

Intensifier la livraison de produit avec Scrum

Étendre l’Agilité comprend deux dimensions : la largeur, l’ajout d’équipes Agiles ; et la profondeur, l’ajout de groupes en amont et en aval de l’initiative Agile. Scrum a réussi à changer la façon de fonctionner des équipes en leur apportant une Agilité de manière incrémentielle. Logiquement, la prochaine étape d’intensification consiste à donner un pareil soutien aux équipes qui livrent un produit. Et Nexus8 , un exosquelette de Scrum, procure au cadre de travail Scrum des ajouts qui permettent à de multiples équipes Scrum de travailler ensemble de façon efficace.

Professionnalisme, valeurs et cohérence Scrum

Il y aura toujours des tensions entre l’établissement du processus qui vous convient à vous ainsi qu’à vos équipes et la mise en place cohérente et normalisée de l’approche de livraison de logiciels au sein de toute l’entreprise. Scrum favorise l’optimisation locale des équipes, ce qui ne signifie pas toutefois que celles-ci peuvent utiliser une terminologie et une approche incohérentes uniquement pour se démarquer. Dans le Guide Scrum9, la communauté Scrum fournit une définition claire de ce qu’est Scrum. Cette source de connaissance devrait se situer à la base des équipes qui utilisent Scrum, éliminant ainsi toute ambigüité quant à ce qui est ou n’est pas Scrum. Le Guide Scrum présente aussi les cinq valeurs de Scrum : concentration, engagement, ouverture, respect et courage. Toutes ces valeurs renforcent le système social qui soutient Scrum. Elles devraient toutes être au cœur des équipes qui l’utilisent.

Bandeau_PSM

La livraison de logiciel professionnel sera toujours empirique

La popularité de Scrum a amené bien des gens à remettre en question sa validité face aux projets modernes. Après tout, « moderne » implique une approche différente de livraison de logiciel, n’est-ce pas ? Mais au cœur de Scrum se trouve la notion que ce processus doit être empirique. Un tel processus empirique s’applique par l’inspection et l’adaptation au changement dans la transparence. Ces concepts se situent au-dessus de la technologie ou de la pratique; ils jettent les fondations de la livraison professionnelle de logiciel.

 

sa-vol1

Cet article est tiré de la première édition du magazine Savoir Agile. Téléchargez votre copies afin de lire tous les articles.

Billet précédent

L’Agiliste du quotidien réfléchit à la culture Agile

Billet suivant

Comment rendre votre leadership plus puissant avec l’apprentissage en boucle

Savoir Agile

1 Commentaire

  1. evan@boissonnot.fr'
    04/10/2017 at 03:44 — Répondre

    Bonjour

    Je vous remercie pour cet état des lieux sur Scrum.

    Le problème lorsqu’un système, un produit devient populaire, c’est que tout le monde adhère sans vraiment savoir pourquoi il adhère.

    Même si l’on ne parle d’une méthode mais bien d’un framework, il faut une certaine méthodologie dans l’application de Scrum.

    Avec un cadre, un vrai cadre, qui est et doit être respecté, on s’assure que cela va mieux fonctionne.

    Je vous rejoins tout à fait sur la définition du Fini. C’est le plus important.
    Bien des fois je vois des équipes oublier la notion de fini, ou bien ils la définissent sans le client.

    Ce n’est pas Scrum qui n’a pas tenu ses promesses, ce sont les personnes qui ont mis en place Scrum qui n’ont pas bien appliqué les promesses de Scrum.

    Encore une fois, nous voyons qu’il s’agit encore et toujours, et quelque soit la façon de gérer le projet, un problème humain.

    Au plaisir
    Evan

Laissez un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *