Publié par
Il y a 9 mois · 6 minutes · Agile

Oubliez les Frameworks Agile, pensez Patterns !

Les Patterns Organisationnels sont une technique de modélisation des organisations qui a émergé dans les années 90 chez Bell sous la direction de Jim Coplien, Neil Harrison et Brendan Cain, avant d’intégrer les contributions d’autres auteurs, notamment Alistair Cockburn et Ward Cunningham, co-signataires du manifeste Agile.

Dans le même temps, Jeff Sutherland (l’un des co-auteurs de Scrum avec Ken Schwaber) commençait à conduire les recherches et à accumuler les observations qui lui permettraient de développer le Framework Scrum quelques années plus tard. Certains des travaux de Bell arrivèrent aux oreilles de Sutherland, notamment une certaine notion de « daily stand-up » dont il s’inspira.

A la fin des années 90, Michael Beedle (autre signataire du manifeste Agile) rencontre Jeff Sutherland et Ken Schwaber pour écrire un document intitulé : SCRUM: An extension pattern language for hyperproductive software development dans lequel la notion de Patterns organisationnels est omni-présente.

Cette histoire de Scrum, cette chronologie des événements, peu de personnes la connaisse. Pourtant, elle est fondamentale pour appréhender Scrum pour ce que c’est – et ce sera tout le propos de cet article : comme tous les Frameworks, c’est un conglomérat de Patterns organisationnels. Un conglomérat cohérent, dans le sens ou les éléments de Scrum se supportent mutuellement (c’est ce qui fait sa force), mais un conglomérat néanmoins.

Qu’est-ce qu’un Pattern Organisationnel ?

En ingénierie logicielle, un Design Pattern (« patron de conception » en français) est une solution générale et réutilisable à un problème récurrent dans un contexte donné dans le domaine du Design (« de la conception » en français).

Par analogie, un Pattern organisationnel est une solution générale et réutilisable à un problème récurrent dans un contexte donné dans le domaine de l’organisation. Dans notre cas, ce qui nous intéresse ce sont les organisations qui ont vocation à construire ou à maintenir des produits.

Du Framework au Pattern Organisationnel

Prenez un des éléments de Scrum les plus emblématiques : le Daily Scrum. Essayez d’identifier le Pattern qui se cache derrière. Pour cela imaginez une équipe qui fait tout ce qu’il y a dans Scrum … sauf qu’il lui manque le Daily Scrum. Quel problème cette équipe rencontre-t-elle selon vous ? Avant d’aller plus loin, je vous invite à jouer le jeu et à essayer de répondre à la question.

Si je m’essaye à l’exercice, cela donne quelque chose comme : « L’équipe Scrum a un objectif de Sprint et un plan initial pour l’atteindre. En cours de Sprint, de nouvelles informations émergent du travail réalisé et des obstacles sont rencontrés. Le plan initial devient  alors obsolète, incohérent et les membres de l’équipe ne sont plus alignés. »

Une solution possible à ce problème – la solution proposée par Scrum – serait alors : « L’équipe se rencontre quotidiennement, pendant pas plus de 15 minutes, afin d’identifier les obstacles, de s’auto-organiser pour atteindre l’objectif, et de créer un plan pour les prochaines 24 heures. »

framework-vs-patternsFrameworks vs. Patterns

 

Or c’est chacun des éléments de Scrum qui peut être reformulé de la sorte !  L’avantage de raisonner ainsi, c’est que ça redonne du sens au contenu du Framework. Cela limite aussi le risque de voir des équipes faire des Daily Scrums chaque jour de l’année sans réellement comprendre à quoi ça sert par exemple.

Cela rend également le Framework plus modulaire et met en évidence que l’implémentation complète de Scrum n’est pas forcément nécessaire. Qu’elle n’est probablement pas suffisante non plus ! C’est donc à chaque équipe d’analyser la situation dans laquelle elle est, d’identifier ses problèmes, puis de choisir les bons Patterns à mettre en œuvre.

 

Il en va de même pour tous les autres Frameworks. Et plus le Framework est riche, plus il est nécessaire d’avoir cette lecture, car cette cohérence qu’on a dans Scrum par exemple s’effrite à mesure que le Framework grossi …

Prenons le Framework d’agilité à l’échelle LeSS pour exemple maintenant. Dans LeSS, jusqu’à 8 équipes, il y a un unique Product Owner pour tout le monde. C’est un parti pris fort. Une solution typique, à un problème, dans un contexte donné … Mais à quel problème ? Si vous « faites du LeSS », j’espère que vous savez répondre à cette question.

Dans SAFe, en plus des itérations classiques, les équipes rythment le travail en « Program Increment ». Des itérations d’itérations qui durent entre 2 et 3 mois. Même question alors : quel problème cela cherche-t-il à résoudre, et dans quel contexte ? J’espère que tous ceux qui « font du SAFe » sauront répondre à la question.

Quelques références de Patterns

Il a été documenté de nombreux Patterns Organisationnels par ceux qui se consacrent à l’étude des organisations. Jeff Sutherland considère par exemple que pour les équipes Scrum qui font du logiciel, il faut ajouter à Scrum les patterns suivants :

Il dit aussi appliquer systématiquement les Patterns suivants dans les équipes qu’il accompagne, celles qui démarrent comme celles qui veulent passer à la vitesse supérieure :

  • Stable Teams (pérenniser au maximum la composition des équipes pour gagner en efficacité et en prédictibilité)
  • Yesterday’s Weather (ne pas planifier plus que ce que l’équipe a réalisé dans le ou les Sprints précédents)
  • Swarming: One-Piece Continuous Flow (maximiser l’effort de l’équipe sur l’élément le plus important à livrer afin de le finir au plus tôt)
  • Illegitimus non Interruptus (allouer explicitement du temps pour les interruptions dans le Sprint, et interdire les interruptions au delà du temps alloué)
  • Daily Clean Code (faire en sorte de toujours pouvoir fixer l’ensemble des défauts du produit en un jour)
  • Emergency Procedure (l’équipe établit une procédure claire qu’elle met en oeuvre lorsque le Sprint va dans le mur)
  • Scrumming the Scrum (à chaque Sprint l’équipe identifie le problème numéro 1 et le résout)
  • Happiness Metric (l’équipe mesure sa satisfaction au travail, identifie une chose qu’elle pourrait faire pour accroitre sa satisfaction et l’implémente au Sprint prochain)
  • Teams that finish early accelerate faster (prendre moins de chose dans les Sprints pour finir rapidement, puis ajouter des choses au Sprint au besoin)

Vous retrouverez le détail (contexte, problème, proposition de solution, effets attendus, etc.) de ces Patterns sur scrumplop.org. Le site est vieillot et il est parfois difficile de s’y retrouver, mais c’est la source la plus aboutie pour quiconque s’intéresse aux organisations et à leur performance. Courez-y !

Car si la communauté agile toute entière connaissait ces Patterns sur le bout des doigts, et si nous raisonnions en terme de contextes, de problèmes et de solutions, nous pourrions alors arrêter d’opposer les Frameworks – ces conglomérats de Patterns – entre eux ; pour à la place avoir une discussion riche, précise, et constructive. « Faire du Scrum / du Kanban / du LeSS / du SAFe / du DAD » ne voudrait alors plus dire grand chose, et la communauté agile ne s’en porterait pas plus mal !

Grégory FONTAINE
Grégory a 10 ans d'expérience au cours desquels il a été Chef de Projet puis Responsable Qualité avant de se trouver une passion pour l'agilité et de devenir Scrum Master et Coach. Développeur sur son temps libre, Grégory aime aussi bien accompagner des équipes de développement dans l'implémentation de pratiques d'ingénierie que travailler sur des transformations organisationnelles à grande échelle.

7 réflexions au sujet de « Oubliez les Frameworks Agile, pensez Patterns ! »

  1. Publié par Sylvain, Il y a 9 mois

    merci.

  2. Publié par Greg, Il y a 9 mois

    J’aime bien le livre de Coplein et Harrison depuis des années. Bravo pour ton archéologie et parage des idées importants. J’aime bien une préférence pour essayer des patterns dans le contexte, et je suis contre trop de prescription.

    Je ne trouve pas qu’il faut oublier totalement les frameworks, par contre. LeSS, avant que ce framework avais son nom (publié comme « Scaling Lean and Agile » depuis 2008), n’était pas du tout prescriptif, juste ~600 experiments – patterns et anti-patterns, si tu veut.

    C’était en réponse a beaucoup des demandes de plus des règles que les autres ont finalement publié le plus léger prescription de règles qu’ils int ou. Le compliment des patterns (experiments ou celui de Coplien et Harrison, et d’autres) à un framework de minimus à du sens. Avec SAFe, il faut être prèt de de-scaler le framework, comme l’auteur Dean a commencé de faire lui-même avec « SAFe Essentials » l’annee passée.

    Pour le plupart du monde, je crois qu’il demandera une collection coherent des patterns pour commencer. Le plus simple et plus adaptable, le mieux.

    Une bonne suggestion pour tout nos coaches à lire le bouquin sur des patterns.

    J’ai publié moi-même une présentation sur les patterns et anti-patterns de l’adoption agile en 2007, je partagerai prochainement après un mise-a-jour!
    -greg

  3. Publié par Grégory FONTAINE, Il y a 8 mois

    @Greg tout à fait d’accord !

    Pour ceux qui aimeraient mieux comprendre d’où vient LeSS, je vous recommande l’histoire racontée par Bas Vodde himself ici : https://www.youtube.com/watch?v=TZOFtrxprP0

    Et j’attends avec impatience ta présentation mise à jour Greg ;)

  4. Publié par David Brocard, Il y a 7 mois

    Merci pour ce billet
    Rappeler l’histoire est fondamental pour comprendre ce qu’on fait aujourd’hui
    Je suis en phase avec la philo générale que tu décris
    Par contre, quelle est pour toi la différence entre un pattern et un principe ?
    « L’architecture agile », c’est valeurs->principes->pratiques->outils
    Dans cet ordre d’idée, je n’ai jamais trouvé très pertinent de vendre des framework sur mesure, puisqu’il suffit de piocher dans les patterns (ou principes pour moi c’est la même chose) et d’en faire un conglomérat adapté à notre contexte. Et pour justifier le « pourquoi », de remonter aux valeurs.
    Enfin, faut-il rappeler que les frameworks sont aussi une histoire de sous et de certif… bref, de business, parfois au détriment de la pureté cognitive
    Mais bon ca rassure les grosses organisation et leur permet de se lancer
    @+

  5. Publié par Grégory FONTAINE, Il y a 7 mois

    Bonjour David,

    Un pattern c’est grosso-modo une réponse possible, à un problème donné dans un contexte donné. C’est beaucoup plus concret qu’un « principe ».

    Pour préciser un peu ma pensée, et au risque de contredire le titre volontairement provocateur de mon blog :), je ne pense pas que les frameworks soient inutiles. Lorsqu’on est à l’étape « Shu », ils rendent un grand service. Je pense même que ça aideraient certaines équipes de coller un peu plus aux frameworks au départ, jusqu’à ce qu’elles comprennent vraiment ce qu’elles font, pour ensuite se mettre à questionner d’avantages. Par exemple, Jeff Sutherland cite régulièrement en exemple des équipes performantes de chez Google qui sont partis de Scrum mais ne font aujourd’hui plus de Daily Scrum.
    a+

  6. Publié par David Brocard, Il y a 7 mois

    Hum je demeure septique

    Je comprends l’idée de faciliter l’adhésion à l’étape Shu en utilisant un framework sur étagère

    Cela évite à se poser trop question quand c’est déjà assez compliqué de comprendre les concepts agiles pour ceux font l’objet d’une transformation
    Mais mon expérience montre que cela pose finalement plus de problème que de de construire une méthode ad’hoc sur la base des valeurs, principes et donc aussi des PATTERNS agiles, puisque tu en as précisé la différence
    En effet, combien de fois ai-je vu des entreprises engluées dans un framework qui ne correspond pas à leur modèle d’organisation / état d’esprit ?
    C’est même parfois catastrophique car on superpose une couche complexe sur une qui l’est déjà
    Les gens n’y comprennent plus rien et c’est le refus

    Vraiment, désolé mais je demeure extrêmement septique sur la mise en oeuvre de LeSS ou SAFe dans les entreprises car peu osent vraiment y coller en abandonnant tout ce qui pourraient venir en contradiction (voir mon billet sur le renoncement ici : http://www.soagile.eu/blog/renoncement)
    L’architecture de ces frameworks est irréprochable, c’est même un formidable travail d’agrégation de « patterns » et de « principes » de l’air du temps agile
    mais une fois plus, les experts veulent aller plus vite que leurs clients, pas aussi matures qu’on le voudrait, même 16 ans après le Manifeste

    Peut-être n’ai-je pas la chance de tomber la plupart du temps sur des transfos suffisamment sponsorisées où LeSS et SAFe donnerait leur plein potentiel ?

    En tous cas merci pour ces échanges autour des PATTERNS qui rappellent les fondamentaux et la possibilité de construire sa propre maison avec ses propres briques

  7. Publié par Rémi, Il y a 7 mois

    Un grand merci pour votre article !! Il m’a permis de mieux comprendre la genèse des frameworks Scrum, Kanban etc… et de s’ouvrir aux Patterns qui permettent de définir une organisations adaptée à nos besoins.

  8. Publié par MEKKI RAFIK, Il y a 6 mois

    Hello !

    Superbe article, fond et forme, qu’on adhère ou pas .. qu’on suive le SHU en appliquant un framework, ou qu’on soit dans l’utilisation d’un panier de patterns, je salue le travail d’investigation.

    Rafik.

Laisser un commentaire

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