Xanpan - une méthode agile hybride centrée sur l'équipe

9489b8d6f2dbdc3e7d26b8702143b86e?s=47 Yoan
June 16, 2020

Xanpan - une méthode agile hybride centrée sur l'équipe

Dans la vie, il n'y a pas que Scrum ou Kanban, il y a Xanpan aussi.
Xanpan, comme vous l'avez peut-être déjà deviné, est un croisement entre les mots XP et Kanban.
Il tire ses fondements du Kanban (flux), du Lean (culture de l'amélioration continue), de l'XP (pratiques techniques), de Scrum (rythme et certains événements) et de la gestion des produits.

Son objectif principal est de résoudre certaines questions que vous vous êtes probablement déjà posées avec des frameworks comme Scrum :
"comment gérer la maintenance dans mon sprint ?"
"comment assurer la qualité des incréments du produit ?"
"Comment améliorer la prévisibilité ?"

9489b8d6f2dbdc3e7d26b8702143b86e?s=128

Yoan

June 16, 2020
Tweet

Transcript

  1. Xanpan A team centric agile method story Pronounce it Zan

    pan
  2. @yot88 Who am I yoan thirion Technicalagile coach https://yoan-thirion.com

  3. @yot88 Allan kelly Agile coach Software engineer

  4. What limitations have you already lived or observed with Kanban

    or Scrum ?
  5. #nomagicmethod #nomagicframework

  6. @yot88 What is xanpan? A process for agile teams Team

    at the heart Principles practices
  7. @yot88 XP scrum lean kanban Product management xanpan pragmatism

  8. @yot88 PRINCIPLES Work in iterations Team-centric Work to improve Flow

    Quality is free (invest in quality) Visualize
  9. @yot88 Work in iterations 2 weeks iterations from mid-week to

    mid-week releasable product at the end of each iteration continuous integration -> continuous deployment Deadlines help to focus : limit wip
  10. @yot88 Planning -3 players Product Owner played by a product

    manager, or a BA The creators Software engineers, Testers, UX, UI,… The facilitator Dedicated or not Product ownership is considered a practice rather than a role.
  11. @yot88 Planning -artefacts vertical slices of business functionality from multiple

    projects or products Blue cards Tasks related to blue cards Bugs White cards Red cards Planning board Planning poker
  12. @yot88 Planning Meeting

  13. @yot88 Retrospective “Teams may also hold a retrospective as part

    of the iteration end routine, although not all teams hold retrospectives, and even those who do may not hold them at every iteration.” Formal or not (dialogue)
  14. @yot88 Work in routine Event Frequency Iteration Every 2 weeks

    –10 working days Stand-up meeting Everyday -Maximum 15 Minutes Iteration review meeting End of every iteration 20 minutes at end of Iteration Retrospective event End of every iteration Formal retrospective End of every iteration (new teams) (60-90 minutes) every second (mature teams) Informal retrospective Every second iteration (30mins) for mature teams Demo At least every iteration which does not release Release Minimum quarterly high-performing teams will release many times during Iteration Sanitize the board & count the points
  15. @yot88 Plan beyond the iteration The quarterly plan looks at

    most 12 weeks into the future Roadmap looks at the next quarter Iteration plan : output of the next two weeks More certainty Filled to approximately the capacity of each iteration : WIP limit for iterations
  16. @yot88 Plan beyond the iteration Quarter & Roadmap are only

    horizons planning != scheduling Plan = looking into the future to learn about what might happen : perhaps preparefor it with Design thinking for example
  17. @yot88 where is the Kanban part in it ?

  18. @yot88 Kanban-style flow Xanpanallows both planned and unplanned work Commitment

    Work can flow from iteration to iteration Blue cards must bring value (Small stories regularly don’t)
  19. Team-centric the team may be working on more than one

    product or project at a time.
  20. @yot88 visualise Sprint backlog Stock of unplanned work Work For

    today
  21. @yot88 visualise State of the team and their work See

    to learn
  22. Quality is free All successful software needs rework how easy

    is the rework? Low quality makes rework harder, and therefore slower. High quality makes rework easier, and therefore faster.
  23. Poor quality Rework destroys flow stories and tasks can’t truly

    be considered ‘done’ hidden work is flowing between iterations Metrics are destroyed Inordinate amounts of time prioritizing, reporting, doing rework instead of delivering value inordinate amounts of money on testing resources and cycles
  24. How to define quality of a software product ? Defects

    Maintainability
  25. @yot88 How to build quality in ?

  26. @yot88 Technical practices some of Test-Driven Development (Unit, ATDD) Refactoring

    Frequent builds Continuous Integration Source code control Code reviews Pair programming Static analysis Coding Standards
  27. @yot88 "create your own process, don’t follow someone else’s prescription.”

    – Allan Kelly
  28. @yot88

  29. @yot88 Just do it : action over words Keep or

    drop Identify a practice, tool, technique, whatever from somewhere else. Decide what it would mean to your team: what would you do differently? Set a time frame Make the change at the end of the period : check
  30. @yot88 experiment more

  31. @yot88 https://www.linkedin.com/posts/maurostrione_scrum-agile-devops-activity-6650103984235298819-Zb5a

  32. @yot88 “xanpan is the kind of stuff that should emerge

    from every agile teams when not constrained by some “agile” dogms.”
  33. https://agnosticagile.org/

  34. What could you try to implement in the near days

    to solve the limitations you observed ?
  35. @yot88 ANY QUESTION ? REMARKS ? OPEN YOUR MIC

  36. @yot88 PLEASE GIVE YOUR FEEDBACK #CONTINUOUSIMPROVEMENT https://roti.express/r/mdfvjy

  37. @yot88 ressources

  38. @yot88 thank you yoan thirion Technicalagile coach https://yoan-thirion.com