Lean or Scrum

Article très intéressant de Jeff sur son blog: « The First Scrum: Was it Scrum or Lean?« , mais comme il est assez long, profitez d’un moment de calme pour le lire.

Jeff nous fait un historique de la création de Scrum afin de nous montrer que Lean et Scrum ont les mêmes origines: la théorie des systèmes adaptatifs complexes. Mais Jeff positionne clairement Lean et Scrum sur 2 plans différents. Scrum intrduit le chaos dans le processus de développement et utilise un système de contrôle empirique pour rapidement inspecter et adapter ce système qui évolue rapidement. En ce sens, Scrum est un moyen d’implémenter Lean au niveau du développement de logiciels. Lean de son coté est un bon outil de communication à destination des managers, et permet à des équipes Scrum de comprendre pourquoi elle ne réussissent pas avec Scrum, en implémentant du Kaizen et/ou des principes de’arrêt de production au moindre défaut (Stop-the-line).

Jeff rappelle également quelques principes de Scrum dont je retiendrais ceux-ci:

  • Le nombre de testeurs et de documentalistes doit être supérieur au nombre de développeur afin d’éviter qu’ils produisent trop de code trop vite
  • Rien n’est plus convaincant pour le management que de voir régulièrement (démo) du code qui marche
  • Il est impossible pour les développeurs de développer du code de qualité sans avoir un environnement d’intégration continue en place

Management Agile

Intéressant article trouvé sur le site de Scrum Alliance décrivant le rôle du manager dans un contexte Agile.

L’article indique le besoin pour le manager de disposer de 3 grandes compétences et d’une méta-compétence.

Compétence 1: Gérer les équipes

  • Etre un Leader ou un coach plutôt qu’un chef.
  • Faciliter la résolution des problèmes par l’équipe elle même
  • Gérer les ressources pour maximiser le flux de sortie (création de valeur) et non l’utilisation maximale des ressources (100% d’occupation)
  • Adapter la mesure de performance au principe Agile (Inspect & Adapt) et donc éviter le bilan annuel comparatif des objectifs définis 12 mois plus tôt

Compétence 2: Gérer les investissements

  • Investir dans ce qui crée de valeur immédiate et mesurer le ROI sur la base des métriques fournies par l’équipe
  • Avoir des cycles plus courts de remise en cause du « portfolio « de produits.

Compétence 3: Gérer l’environnement

  • Utiliser des approches issues du LEAN pour gérer les partenaires internes (Finance, RH …)
  • Gérer la sous-traitance (locale ou off-shore) en s’assurant que la création de valeur reste maximale (surtout si le choix s’est fait sur des critères purement financiers)

Méta-Compétence : Gérer les changements organisationels

  • Faire en sorte que cela fonctionne en facilitant l’adoption des méthodes Agile et le changement des pratiques établies

Un petit questionnaire est également disponible pour savoir quel est votre degré de maturité dans le management Agile

Comment faire de la doc ?

Personnellement, Je n’ai jamais trouvé que l’agilité donnait une réponse précise à cette question 🙂

Par contre, j’ai trouvé une forme de réponse coté Lean. En effet, si le prend le point de vue de l’utilisateur final, la documentation qui n’est pas lue par l’utilisateur final peut souvent être considérée comme du « gâchis » et je considère qu’il y a donc une opportunité de réduction des coûts de production.

Depuis quelques temps, chaque fois que quelqu’un veut écrire un document, je lui pose la question suivante:

  • QUI VA LA LIRE ?

Les réponses sont le plus souvent l’une des suivantes:

  1. Untel la lit et l’utilise
  2. Je n’en sais rien mais quelqu’un devrait le faire
  3. Ce document est contractuel
  4. Notre processus dit qu’il faut la produire

Sur la réponse 1, je réponds : « C’est Ok, ce document est utile ».

Sur la réponse 2, je réponds simplement : « Mais pourquoi l’écris-tu ? », et bien souvent ce document est abandonné

Sur la réponse 3, je dis : « Ok, mais as-tu essayé de la réduire au strict minimum ? », car il y a souvent une volonté de bien faire alors que le juste nécessaire suffit souvent.

Sur la réponse 4, je dis : « Viens avec moi on va voir le responsable de ce processus pour voir si on peut le modifier ».

Lean à l’Ensimag

Le chemin est encore long pour avoir un cours sur le Lean Software Development à l’Ensimag, mais hier soir c’était l’unique sujet dont on parlait dans les locaux de l’école.

L’association des anciens élèves organisait une soirée « diner/débat » et j’étais l’orateur pour présenter le Lean de mary et tom poppendieck à une audience d’une 30aine de personnes constituée d’anciens élèves, de professeurs et de membres du groupe agile de Grenoble.

Je prends toujours un vrai plaisir à présenter les 7 concepts du Lean, même si le format limité à 1h15 me laisse un peu sur ma faim car je ne peux que survoler certains aspects et surtout, et à mon grand regret, je dois réduire le nombre d’anecdotes amusantes qui permettent de mieux comprendre « comment » implémenter le Lean.

Même si une partie de l’audience (les agilistes) était acquise à cette cause, il est vraiment toujours intéressant de batailler pour que certaines résistances s’ouvre un peu au Lean. Je suis conscient que les personnes ne sont pas ressorties entièrement convaincues, en 1h15 cela n’est pas possible, mais j’ai vraiment eu la sensation que ma présentation et la discussion qui a suivi les avait au moins amené à réfléchir sur leurs façons de faire … Je ne demande rien de plus !