Le débat est dans Scrum… n’est-til pas?

Je vais être sincère: ce débat était entendu.

Je m’explique: l’approche Scrum en France est fortement dépendante d’XP (il me semble que la communauté XP en France et très puissante… positivement).
Faisant partie de la Scrum Alliance, je suis au désespoir de voir si peu de CSPO en France, alors encore moins de CSP, et je crois qu’il n’y a pas de CSP. Désolé pour XP, mais chez nous, nous aimons les certifications ;o))

Dans XP, on recherche la proximité directe avec le client (validation agile: OK), donc il n’y a pas de projet, etc….

Scrum est moins souple (et j’accepte moins agile, c’est exact) est repose sur l’équilibre des trois forces l’équipe, le Scrum Master et le Product Owner. L’inexistance de l’une ou l’autre de ces « forces » désorganise le process(petit provoc vs Manifesto). Comme par ex. dans l’Agile Modelling, l’absence du Scrum Master remplacé par l’unique Product Owner crée un déséquilibre.

Cher ami « jouteur », il serait peut être intéressant de démontrer les aspects Projet de Scrum?

Sujet à réflexion N° 1: Scrum ne serait-il pas un LEAN (Hoshin Kanri)? avec des itérations plus courtes? une plus grande réactivité au changement? un LEAN pour des projets critiques?

Cordialement

Pierre

N.B. faites donc un petit tour par http://www.systematic.com/, Systematic a utilisé Scrum pour implémenter LEAN (étonnant non?)
et pour nos amis XP, l’université de Trèves (D) a accompagné un projet de développement de puces électroniques uniquement avec XP!

J’ai lu avec attention votre article que j’ai trouvé très enthousiaste mais truffé de contre vérités. Une chance qu’à la conclusion vous signalez apprécier XP (du coup je comprends beaucoup mieux).
Soyons clairs : je suis pro XP, mais surtout Scrum, Lean.
L’approche Kan Ban dans Scrum est extrêmement bien expliquée dans le livre blanc de Kniberg & Skarin (dispo chez infoQ)…. mais je vais rajouter mon petit grain de sel
1. Rappel de Scrum
Artifacts: Backlogs (Product, Sprint), Burndown Charts (Product, Sprint, Release), Impediment List… Vélocité
Objectif: livrer un produit apportant le maximum de valeur
Scrum Team: une équipe (Dev, Archi, DBA, Tester, Ergo, etc.…), Scrum Master (Resp. du Process), Product Owner (Resp. du Produit)
Process :
a. Le PO définit une Vision avec les « stakeholders » (Business, MOA, Clients, utilisateurs)
b. Le PO rédige des User Stories (merci XP !) relatives aux exigences des utilisateurs, les prioritisent, et construit un Product Backlog initial
c. Le PO construit une Roadmap et un Release Plan Initial avec les utilisateurs et élabore une Definition of Ready et les critères d’acceptation des utilisateurs (Definition of Done initiale)
d. Le PO vient ensuite rencontrer l’équipe et le Scrum Master pour soumettre les exigences des utilisateurs : Sprint Planning
e. L’équipe analyse les stories sur leur clarté, faisabilité, testabilité (cf. Mike Cohn)
f. L’équipe estime : Planning Poker (merci XP !)
g. Le PO discute avec l’équipe sur la Definition of Ready et la Definition of Done du Sprint
h. Le Sprint se déroule :
i. Découpage des users stories en tâches (habituellement la DOR convient qu’une story ne doit pas dépasser une journée de développement, et la compréhension de celle-ci ne doit pas dépasser les 30’ : dans la négative, il s’agira d’un IMPEDIMENT et devra être traité par le Scrum Master)
ii. Daily Scrum
iii. Revue de Backlog ou de Stories avec le Product Owner (surtout en début de projet)
i. Fin de Sprint : Sprint Review Meeting : présentation du produit développé lors de l’itération et validation ou non du résultat par le Product Owner conformément à la DOD.
j. Retrospective : faite par le Scrum Master, point de situation sur le Process Scrum. Calcul de la vélocité.
k. Le Product Owner prend les informations concernant la vélocité, analyse la taille du backlog, traduit la vélocité en terme de j/h, calcule le temps nécessaire pour livrer le produit, revoit le Release Plan et calcule le ROI.
l. Le Product Owner fait le reporting aux utilisateurs et au Business en tenant compte de : date prévisionnelle de fin de Scrum (Go Live), valeur crée
2. Et Kan Ban dans tout çà :
Kan Ban intervient dans la planification des tâches de l’équipe (Kniberg l’explique mieux que moi).
En effet, par défaut toutes les tâches du Backlog sont ouvertes sur le tableau de progression. Kan Ban induit une notion de flux, c.à.d. Toutes les tâches sont « ouvertes (par ex.), ensuite chaque membre s’attribue une tâche qu’il doit remplir, si il n’y arrive pas, celle-ci passe dans l’Impediment List et analysée par le SM.
Donc Kan Ban renforce la notion de rythme dans Scrum afin d’améliorer :
- La vélocité de l’équipe
- L’affinage des user stories (par le PO)
L’objectif derrière ceci est de mettre le SCRUM en mode d’hyper productivité (cf. Sutherland).

Pourquoi réinventer la roue?

L’approche Scrum est intéressante et dans le retour d’expérience de Kniberg, je reste toute fois un peu sceptique.

Je m’explique: il y a une démarche Scrum venant d’XP qui promeut l’abscence de Chef de Projet dans cette démarche.

Pour ma part, je partage la Vision de Cohn et de Pichler, qui mettent en avant la puissance de l’organisation Scrum: 1 gestionnaire du Process (SM), 1 gestionnaire du Produit (PO). De ce fait, la conduite du projet est partiellement bi-polaire (partiellement car l’équipe est active dans la gestion du projet) et les responsabilités clairement définies: le SM dans sa compétence technique et le PO en tant coordinateur du métier (MOA).
A l’instar des approches traditionnelles, le PO n’est pas à l’extérieur de l’équipe, mais dans l’équipe. Cela permet à l’équipe de gagner en éfficacité: la modification des stories, l’ajout et le retrait se fait durant les sprints.

Dans les projets matures, l’approche se fait de cette façon car elle permet de découper le backlog/release plan en différentes parties: scrum de dév., scrum de test, scrum de documentation, etc… (c’est un example) et dans ce cas la direction est prise vers un meta scrum.
A ce niveau, les PO alignent la Vision globale et gèrent une partie du backlog en mettant davantage l’accent sur les tests de fonctionnalités.

Groomer le Backlog:
- entretenir, nettoyer, vider le fonds fu backlog.
- Activité principale du PO qui met en place (si possible) 15′ de Grooming Meeting avec l’équipe après chaque Daily Scrum.

Backlog: Product Backlog & Sprint Backlog.

Bien à toi

Pierre

Si je comprends bien, Kanban sert à groomer le Backlog?
Si Kanban sert à groomer le Backlog, que fait l’équipe? le PO?
s’il n’y a pas d’équipe ou PO, il n’y a pas de Scrum, non?

Pour ma part, Scrum ne se réduit pas seulement au développement de logiciels, il s’agit avant tout d’une méthodologie de management participative.

Adopter les principes de Lean sont très efficaces, mais à utiliser en amont de l’équipe dans la relation avec le Management (Business) afin de définir la Vision et la Roadmap.
L’approche Lean est excellente, cependant, la réaction au changement, comme décrite dans l’article, est un peu en deçà de la réalité: le rythme (vélocité) dans Lean est un peu plus long que dans Scrum.

Rappel Scrum:
- si bug il y a, alors DoD pas défini et rejet par le PO (cf. Kent Beck dans XP)
- si modif. du Backlog, alors analyse par le PO et réajustement lors du Review.

Non?