Gérer ses projets agiles avec Scrum: les documents de base pour bien commencer

Pour démarrer un projet agile avec Scrum, Product Owner et Scrum Master ont à travailler ensemble pour préparer le terrain du projet.

Un des fondamentaux de scrum à côté de Inspect-and-Adapt, c’est que tout part de « READY » pour aller vers « DONE »…

 

Capture d'écran 2014-10-06 23.08.48

 

en clair cela pourrait donner cela:

 

Capture d'écran 2014-10-06 23.09.01

4 commentaires Ajoutez le vôtre

  1. Bonjour Pierre

    J’ai eu à faire ce difficile exercice il y a quelques mois : énoncer les documents nécessaires à la vie des projets. J’ai fait le choix de restreindre le nombre de documents à moins de 10. J’avais en tête la méthode SAFe et son processus trop bien huilé pour y laisser place à de l’auto-organisation. J’avais en tête le retour d’expérience que l’on trouve dans Rupture Douce 2 qui parle de l’abandon d’une transition agile à cause d’un manque d’adhésion des opérationnels submergés sous les nouveaux « livrables » à produire.

    Comment fais-tu pour éviter ces écueils ?

    1. PierreENeis dit :

      Stéphane,
      En fait, le tableau que je présente est très détaillé et il reprend l’ensemble des éléments a maxima pour définir le projet.
      Avec l’évolution de l’adoption de l’agilité, nous sommes confrontés à différentes interprétations de celle-ci.
      Dans le modèle présenté, je m’adresse plus particulièrement à Scrum. Par nature, Scrum avance de « ready » à « done » et la majorité des problèmes rencontrés viennent de l’absence de Vision et de connaissance de la gestion de projet.
      En 2008, lorsque que j’ai donné mes 1ères formations PO, je me suis inspiré de M.Cohn et R.Pichler qui démontraient que Scrum démarre avec une Vision et un cadre de projet clair. La clarté permet d’assurer à la Scrum Team d’être sur le bon projet et les reviews car le contrat entre le Business et le Dev est clair.
      Dans des équipes projet matures (sous Prince2, PMBok, Hermès par ex.), cette approche rassure car le language est proche et cela permet d’agiliser le système existant.

      L’ELEVATOR STATEMENT est un MUST Have.
      TRUE NORTH est une option (si tu as le temps de passer à LKFR14, je fais une présentation de Hoshin Kanri qui explique le principe)
      HOSHIN KANRI est une option qui peut résoudre de nombreux problèmes avant de démarrer un programme ou une implémentation de SAFe, DAD, LESS ou ASAP8.

      Les autres documents sont présents dans les équipes scrum mais trop souvent de manières implicite.

      Pour SAFe, je ne peux te répondre ni pour « Rupture Douce » que je n’ai pas lu.

      De mon expérience, je peux seulement te dire que l’absence de ces documents peuvent créer un risque: équipes multi-projets, pas de projet, scrumbut, un Product Backlog ne se vidant jamais.
      La force de ces documents est de renforcer la position tant du Scrum Master que du Product Owner est assure une dynamique d’équipe engagée dans la livraison de valeur business.

      Pour éviter ces écueils?
      – je fais la différence entre transition agile qui fait appel au Change Organisationnel
      – et la gestion de projet qui délivre un projet, un produit, un service dans un cadre, un temps et un budget donné

      Mais, je dois te l’avouer, je travaille souvent dans des projets ou des programmes « matures » en terme de gestion de projet.

      Je ne sais pas si j’ai pu te répondre correctement à ta demande. N’hésite pas à me répondre, cela pourrait être l’objet d’une prochain post … en commun?

      Pierre

      1. Pierre merci pour ce retour !

        Pour une équipe habituée à Prince2 ou autre, je comprends qu’il soit rassurant de « retrouver leurs petits » dans une méthode Agile. Je ne crois cependant pas que cela puisse constituer une « bonne pratique » généralisable à toutes les équipes. Je connais pleins d’équipes qui seraient immédiatement démotivées à devoir produire tant de « livrables » en plus d’une solution fonctionnelle et d’une remise en question de leur méthode de travail. En disant cela je ne t’apprends rien, tu es un fin connaisseur de Cynefin, tu sais que les bonnes pratiques ne portent pas leurs fruits dans tous les cas.

        Si je comprends bien, les 5 phases du second graphique ont lieu durant le temps de Vision et de Spéculation du premier graphique ? Pour prendre volontairement un vocabulaire « classique » c’est un temps de cadrage et de « spécification » ?

  2. Pierre Neis dit :

    Stéphane,
    Pour une équipe agile, je peux le concevoir. Pour une équipe Scrum, j’ai plus de mal.
    Passons en revue les livrables:
    1. Vision (must have pour Scrum, le 1e travail du PO)
    – Elevator Statement: c’est l’ABC pour tester la vision
    – True North: permet de vérifier que celle-ci est comprise par toutes les personnes impliquées au projet: management, scrum team, client et utilisateurs
    – Hoshin Kanri: est un « Nice to have » que j’utilise en tant que Coach « Ri »
    2. Roadmap (could have Scrum pour le PO)
    – Theme sorting (could have): on regroupe les US en Epic et Theme (Features, c’est quand le Product Backlog est partagée entre plusieurs PO i.e. plusieurs Scrum teams). La Roadmap livre d’abord le Theme 1, ensuite le 2 etc….ou pas car ceux-ci peuvent être revu lors de la Review de Release du Theme 1 (je te ferai un post là-dessus).
    – MVP (should have) (minimal viable product), pour une fois que j’utilise du jargon Lean Start’up. Si pas de MVP, alors quelle est la business value du projet?
    – Story Mapping (should have): c’est un atelier UX où le PO collecte les stories des users (User Stories)
    – priorisation en Business Value: must have dans Scrum, c’est le B.A.BA de la gestion de product backlog
    – priorisation financière par le business sous l’autorité du PO: should have, cela renforce la priorisation en Business Value
    – risk impact (could have): le risque léger en premier, le risque important en dernier. Selon le contexte (ex. Finance), l’approche fait ± de sens. Un Fisbone peut suffire et c’est inclut dans Hosin Kanri pour la partie A3 Thinking.

    3. Business Case (should have). Si on ne sait pas pour quelle raison ont fait le projet, pourquoi le faire?
    – Vision: must have (a été définie précédemment)
    – Product Backlog: must have
    – Roadmap: (could have, définie précédemment)
    – Definition of Done: must have
    – Budget: must have
    – Cadre de projet: must have
    – Justification du projet: c’est quand même la raison du business? Should have
    – Architecture d’entreprise (should have), en France, vous appelez cela urbanisation. C’est quand même bien de savoir où se situera le produit. (pas valable pour les start’ups où les petites structures).
    – Risques: ont été adressés précédemment
    – Bénéfices attendus: font partie du Business Case
    – Solution identifiée: peut être assimilée au MVP

    4. Project Charter (charte de projet): must have
    On reprend les éléments précédents. Le PO travaille maintenant avec le SM et le ou les architectes techniques.
    – audience cible: on fait cela pour quels utilisateurs
    – Rôles et responsabilités: surtout pour s’assurer de répartir le travail entre Scrum Team et participants au projet et de n’oublier personne.
    – Definition of Ready: must have
    – Gestion des ressources pour le SM : qui fait quoi, s’assurer que la Scrum Team est dédiée à 100% au projet
    – Gestion de la Documentation: s’assurer que le minima de doc et prévu et qu’une DoD de documentation existe (pour le SM)
    – Gouvernance: planifier les meetings et qui participe
    – Gestion de la communication: Wiki? Skype ou Communicator, Jira, TFS, Source Code, etc…
    – Architecture fonctionnelle et technique a minima pour assurer le MVP
    – Plan d’intégration: a quel moment les DevOps vont-ils intervenir? Sommes-nous synchro avec les OPS? etc…

    Ici, il faut voir cela comme une check list pour démarrer « Simple ». Les documents sont souvent léger: 1 verso A4.

    Tu noteras que le principal producteur de document est le Product Owner suivi de loin par le Scrum Master. Les équipes sont épargnées.

    90% des informations fournies sont les bases du Product Ownership et sont recommandées par le Scrum Guide depuis 2012.

    Le 1er graphique n’est pas moi, je l’ai juste « designé ». Mais, je l’ai trouvé très pertinent. Tu as raison de comparer les 2 premières phases par cadrage et spécification, même si je pense que ma pensée de spécification peut être plus légère. Ces deux phases, je les utilise en tant que Sprint « 0 » ou POC. Celles-ci durent aux maximum le temps de 4 sprints de 2 semaines.

    Cette approche n’est pas réellement contraignante pour la Scrum Team. Celle-ci assoit le comportement de la Scrum Team dans sa relation présente et future avec le management en évitant les écueils de:
    – nous n’avons pas de client
    – l’objet du projet n’est pas défini mais faites ce que je vous demande
    – changer le cadre est permis dans Scrum
    – un Product Owner qui n’est autre qu’un Business Analyst déguisé
    – un Scrum Master qui est également un développeur ou plutôt un développeur qui est de temps à autre Scrum Master.

    En fait, cette check list est incrémentale et elle garantit une saine communication entre les parties prenantes. En terme de charge de travail, cela représente le temps d’un Sprint « 0 » par un Product Owner formé.

    Prince2, c’est beaucoup plus lourd. XP et DSDM aussi.

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s