Différences entre Scrum et Kanban : l'éclairage TOC

Je reviens sur la différence entre Scrum et Kanban. Réfléchir sur leurs différences m'a finalement amené à réfléchir sur les fondamentaux qu'ils partageaient.
J'avais déjà évoqué l'approche empirique des processus, support de mon introduction à l'agilité lors de l'étape Nantaise d'Agile Tour.
Dans la présentation sur laquelle je travaille, je parle également des systèmes complexes adaptifs en introduction. Mais il manquait un élément fondamental sur lequel je reviens aujourd'hui: La Théorie des Contraintes (TOC):

La Théorie des Contraintes a pour principe fondamental que le flux généré par une organisation est limité par au moins un processus (i.e. un goulet d’étranglement). La production de valeur ne peut donc être augmentée qu’en augmentant la capacité de production au niveau du goulet d’étranglement.

Concevoir un processus c'est savoir ou placer son goulot d'étranglement:


Scrum
Pour Scrum, le goulot d'étranglement est placé, par conception, au niveau de l'équipe de développement.


* Exploiter ce goulot:

• Veiller à garder l'équipe concentrée sur son travail et qu'elle ne soit pas bloquée, c'est le rôle du Scrummaster.
• Prioriser son travail sur ce qui apporte de la valeur et veiller à ce qu'elle est toujours du travail, c'est le rôle du Product Owner
• Ne pas surcharger le goulot, qui tire son travail (le Sprint Backlog lors du Sprint Planning Meeting) de la file d'attente (le Product Backlog).

* Subordonner le reste du système au goulot:

Le flux de production est nivelé par la vélocité de l'équipe au rythme des itérations. Le travail du Product Owner doit s'adapter à cette vélocité, le travail de réception du client s'adapte au rythme des itérations. En amont et en aval, le reste du système s'adapte bien à la vitesse de l'équipe.

* Elever le goulot:

Ce sont les rôles de coach d'équipe du ScrumMaster et de leadership du management.

Mais puisque par conception on place le goulot sur l'équipe, le Scrummaster doit travailler sur les goulots d'étranglements potentiels. Entre autre, le Product Owner peut rapidement devenir le goulot d'étranglement d'une équipe Scrum. C'est d'ailleurs le cas explicite des équipes Scrum de type A.

Cette vue par la théorie des contraintes donne un éclairage sur les rôles d'une équipe Scrum intéressante.

Passons maintenant au Kanban

Par conception, le goulot est placé sur le client. La capacité du système doit donc s'adapter au rythme du client, nivelée par le Heijunka au rythme du takt time.

* Exploiter ce goulot:

Cela passe par son implication: Pour une entreprise Lean, cela passe par une réorganisation de l'entreprise par familles de produits et chaines de valeur, puis de persuader les fournisseurs et clients de suivre la même voie. L'entreprise Lean est une entreprise transverse qui dépasse ses propres frontières avec une approche plus globale.

* Subordonner le reste du système au goulot:

Cela se fait en positionnant des limites sur les états du processus pour mettre en place le flux tiré par le client.

On comprend mieux qu'il n'y ait pas de rôle à part entière dans le Kanban si ce n'est le responsable de la chaine de valeur (value stream) et que la difficulté va être d'impliquer le client dans cette démarche et d'établir la bonne cadence, ce qui passera par de l'expérimentation sur les limites des états.

Dans les deux approches, on repose bien sur la théorie des contraintes en positionnant le goulot d'étranglement dans notre système (équipe de développement ou client) puis en exploitant ce goulot.

Présentation de Scrum au Kanban

En embarquant la TOC en tant qu'élément fondamental pour définir ou comprendre les différentes approches agiles, cela m'a amené à reprendre une partie de l'introduction et de mon premier retour d'expérience, vive le refactoring!

Donc une version V0.2 pour la présentation ici.