Toujours pour Chlouchloutte, les design patterns organisationnels (supposés rendre scrum, kanban et agile manière générale obsolètes).

Beaucoup de doc à backuper en tout cas, en voici un extrait pour mémoire d'ailleurs :

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 :

• Work Flows Inward (l’information aux équipes de développement ne doit pas venir de la hiérarchie)
• Architect Controls Product (l’architecte donne la direction et agit avec leadership)
• Architect Also Implements (l’architecte est également développeur pour garder le contact avec la réalité du terrain)
• Domain Expertise in Roles (recruter des experts dans leur domaine)
• Get On With It (même si votre plan est incomplet, prendre ce que vous savez déjà et commencer à construire le produit)

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 !