Kanban/Scrum amélioration globale et/ou locale

Communauté Scrum Life
1

Bonjour,

Je viens à la recherche de réponses, piste de réflexion car après avoir réétudier Kanban et l’avoir transposé à mon organisation, une question demeure.

Affirmation 1. Agile essaie de remplacer le modèle Waterfall. C’est-à-dire on veut être Agile de A à Z. C’est-à-dire de l’analyse à la livraison

Affirmation 2. Scrum étant un framework Agile alors quand on fait du Scrum c’est de A à Z. Donc à la fin de chaque Scrum on livre au client (DONE == livré

Mais dans de grosse organisation ou gros projet il peut être compliqué de faire un Scrum avec livraisons régulières. Dans mon organisation j’ai remarqué que Scrum est concentré sur l’équipe de Développement.

  • L’analyse et les spec sont fait en amont
  • La conception, le code et les tests sont fait en « Scrum »
  • L’intégration et la livraison est fait en aval

Donc l’organisation n’est pas Agile si on la regarde globalement MAIS localement une équipe essaie d’appliquer un framework Agile.
Maintenant si on met du Kanban et la définition suivante (où le mot organisation est soulignée)

Kanban is not a project management or software development lifecycle method. It is an approach to change management - a framework for catalyzing change in an organization

Avec Kanban on essaie d’optimiser TOUTE l’organisation avec un process léger (plus léger que Scrum).
L’objectif est donc d’optimiser globalement plutôt que localement.

  • On pourrait imaginer plusieurs kanban d’équipe qui se succèdent. Kanban de l’équipe d’analyse, Kanban de l’équipe de DEV, Kanban de l’équipe d’intégration. Les cartes passent d’un Kanban à l’autre.
  • Et chaque équipe gère son process interne comme elle le veut. Analyse fait du classique, DEV du Scrum par exemple.
  • Kanban devient donc un outil pour optimiser le flux GLOBAL dans l’organisation
  • On va essayer de réduire le gaspillage et livrer plus vite. En effet si on optimise que l’équipe de DEV en Scrum il n’y aura presque aucun impact car le temps gagné dans cette équipe sera caché par les équipes en amont et en aval

Est-ce que ma vision de Kanban est juste (optimiser globalement plutôt que localement) ?

Note : Scrum devrait être pareil mais dans de grosse organisation il est compliqué de mettre Scrum de A à Z de la chaine, Kanban peut être plus simple à mettre en place.

1 « J'aime »
2

Les deux frameworks ont des portées globales et les deux frameworks sont difficiles à implémenter dans de grosse organisations à cause de deux facteurs:

  • Le degré de verticalité de l’organisation
  • L’inertie inhérente à une « masse » importante

Aucune des deux approches n’est une approche ‹ silver bullet › qui sauvera le monde fordien et capitaliste de ses egarements.

1 « J'aime »
3

Donc l’application de Scrum au sein de gros projet/orga ne peut se faire que localement. On optimise les équipes locales dans forcément optimiser les gaspillage inter-équipe qui peuvent causer des délais. (employer Kanban ou Scrum est donc une erreur dans ce cas là)

Quels framework Agile pourrait s’adapter à une grosse organisation de manière globale. En transformant de A à Z le processus sans une contrainte « énorme »

4

Est-ce que système avec deux équipes et des files d’attente peut fonctionner ou sera voué à l’échec :

  • L’équipe de conception travaille en Scrum en interne
  • L’équipe de développement travaille en Nexus en interne

Le tableau Kanban permet d’avoir un management visuel. On y applique du flux poussé, une priorisation Juste à Temps, etc … mais en interne les équipes s’organisent comme elles veulent

image
image924×560 49.7 KB

5

Encore une fois, n’importe quelle « solution » proposée à ce niveau se heurtera aux mêmes problèmes que je décris plus haut. Elles ne sont que des composantes d’un système qui est régie par un paradigme, et c’est justement ce paradigme qui est en cause. Une Scoop par exemple rencontrera fondamentalement bien moins ces problèmes, parce sa réglementation et ses enjeux économiques sont autres que ceux d’une entreprise du cac40. Sans aller jusqu’à ces extrêmes, la potentielle soumission d’une équipe à une hiérarchie fluctuante (ex: changement d’organisation à cause d’un rachat/vente) entraîne invariablement des risques pour la structure ou l’equipe en place, aussi performante qu’elle soit. Ces variables sont bien heureusement surmontables, mais elles restent une barrière quoi qu’il arrive, et peu importe le degré d’agilité de l’équipe.