Knowledge-base
  • Home
  • Samman Technical Coaching
  • Software craftsmanship
    • Practices
      • Pair Programming
      • Code Review
      • Co-designs
      • Design sessions
      • Interview Domain Experts
      • Dev ethics
    • The Software Craftsman
    • Egoless Crafting
    • Technical debt workshop
    • Functional Programming made easy in C# with Language-ext
    • F# for OO programmers
    • Domain Modeling Made Functional
    • Testing
      • Clean Tests
      • Improve the design and testing of your micro-services through CDC Tests
        • CDC testing made simple with Pact
        • Pact broker : the missing piece of your Consumer-Driven Contract approach
      • Improve your test quality with Mutation testing
      • How to name our Unit Tests
      • How to write better assertions
    • Katas
      • TDD
        • Stack kata
        • Fizzbuzz
        • Outside-in TDD (London Style)
      • Improve your software quality with Property-Based Testing
        • A journey to Property-Based Testing
      • Clean Code
      • Clean Architecture
      • Write S.O.L.I.D code
      • Mocking
      • Gilded Rose (Approval Testing)
      • Mikado method
        • Mikado kata
      • Pure functions
      • Theatrical players refactoring Kata
        • Let's refactor (OOP style)
        • Let's refactor (FP style)
      • Functional Programming made easy in Java & C#
      • Refactoring journey
      • Refactoring du Bouchonnois
        • 1) Se faire une idée du code
        • 2) "Treat warnings as errors"
        • 3) Let's kill some mutants
        • 4) Améliorer la lisibilité des tests
        • 5) "Approve Everything"
        • 6) Définir des propriétés
        • 7) Tests d'architecture
        • 8) Use Cases
        • 9) Tell Don't Ask
        • 10) "Avoid Primitives" - Commands
        • 11) "Avoid Exceptions"
        • 12) "Event Sourcing"
    • Software Design X-Rays
      • Workshop
    • The Programmer's Brain
      • How to read code better
  • Software Architecture
    • Fundamentals of Software Architecture
    • Aligning Product & Software Design
    • DDD re-distilled
    • Test your architecture with Archunit
    • NoSQL
  • Agile coaching
    • How to run a Community of Practices (COP)
    • The developers — the forgotten of agility
      • The secrets to re-on-board the devs in agility
    • Coaching toolbox
      • Echelle
      • Learning expedition
    • How to improve Team Decision making ?
      • Decision Making Principles and Practices
    • Learning 3.0
    • Retrospectives
      • Back to the Future
      • Mission Impossible
      • Movie themes
      • Rétro dont vous êtes le héros
      • Sad/Mad/Glad
      • Speed boat
      • Star wars theme
      • Story cubes
    • Technical Agile Coaching with the Samman Method
    • Xanpan - a team centric agile method story
    • XTREM WATCH — Découvrez la puissance de la veille collective
    • Become a better speaker through peer feedback
    • Project-to-Product Principles
  • Leadership
    • Bref. J'ai pris une tarte dans la gueule (et ça fait extrêmement de bien)
    • Forward Summit 2020
    • Learn leadership from the Navy SEALs
    • Learn to lead and help your team(s) to be successful
    • Towards a learning organization and beyond
    • Leadership is language
  • Serious games
    • My serious games
    • Libérez vos entretiens d’embauche avec la gamification
    • How to create a game
    • How to debrief a game ?
    • Lego Serious Play (LSP)
      • LSP in your job interviews
  • Xtrem Reading
    • Cultivate Team Learning with Xtrem Reading
    • My Book Infographics
    • How to make book infographics
    • En route vers l’apprenance avec Xtrem Reading
    • Resources
      • Book notes
        • Agile People: A Radical Approach for HR & Managers
        • Agile testing : A Practical Guide for Testers and Agile Teams
        • Boite à outils de l'intelligence émotionnelle
        • Building a better business using Lego Serious Play method
        • Building evolutionary architectures
        • Code that fits in your head
        • Culture Agile
        • Culture is everything
        • Domain-Driven Design: The First 15 Years
        • Dynamic Reteaming - The Art and Wisdom of Changing Teams
        • How to avoid a Climate Disaster
        • La liberté du commandement
        • Réaliser ses rêves, ça s'apprend
        • Refactoring at Scale
        • Succeeding with OKRs in Agile
        • Team Topologies
        • The Good Life
        • Tu fais quoi dans la vie
        • Who Does What By How Much?
  • My Activity
    • Retour sur mon année 2020
Powered by GitBook
On this page
  • What is it?
  • Work in iterations
  • Why use iterations?
  • Planning
  • 3 roles
  • Planning artefacts
  • Planning meeting
  • Retrospective
  • Work in routine
  • Plan beyond the iteration
  • Where is the Kanban part in it?
  • What about commitment?
  • Team centric
  • Visualise
  • Unplanned work
  • What about technical practices?
  • How to define quality of a software product?
  • Practices
  • Experiment
  • Just do it: action over words
  • Wrap up
  • To go further

Was this helpful?

  1. Agile coaching

Xanpan - a team centric agile method story

Xanpan is an agile method created by Allan Kelly.

PreviousTechnical Agile Coaching with the Samman MethodNextXTREM WATCH — Découvrez la puissance de la veille collective

Last updated 4 years ago

Was this helpful?

Allan has really done a great job by explaining it in his book “”.

It differs from other agile methods or frameworks because it’s the team itself at the center of the method (not a product nor a process).

In this article I won’t explain the entire method (to do so I invite you to read the book), I will focus on the elements that differ from what we can experiment with other agile methods.

What is it?

As you have probably already guessed by its name, Xanpan is a mix of Kanban, XP (eXtreme Programming), Lean, Scrum and Product Management.

Everything in Xanpan is based on a simple but hard to use principle: pragmatism.

The building blocks of Xanpan are:

  • Work in iterations

  • Team-centric

  • Work to improve Flow

  • Quality is free (invest in quality)

  • Visualize

Work in iterations

Just like in Scrum, you will use iterations in Xanpan. An iteration is a 2 weeks period from mid-week to mid-week.

Allan explains in his book that many studies have proven people are more effective at the start of a new week. So, the idea is not to start the week with meetings but to work on the iteration backlog.

At the end of each iteration, the team should have produced a releasable product.

Why use iterations?

Well, with the iterations the team defines small deadlines that help to focus, it avoids multi-tasking and so limits the work in progress naturally and improve efficiency.

Planning

3 roles

There are 3 roles in the planning:

  • Product Owner: this role is usually played by a product manager, or a business analyst acting as a proxy for the real customer

  • Creators: software engineers and testers mainly, although sometimes others, such as user interface designers are involved

  • Facilitator: sometimes there is a dedicated facilitator who is not the Product Owner or a member of the building team. They may be, for example, a project manager, Scrum master or Agile coach.

Product ownership is considered a practice rather than a role.

Planning artefacts

The outcome of the planning is cards that will be fixed onto the team board (it’s the iteration backlog), like in Lean cards are Blue, White and Red:

  • Blue cards: vertical slices of business functionality from multiple projects or products

  • White cards: Tasks related to blue cards. Those are written during the planning meeting, and there are usually multiple white task cards for each blue card.

  • Red cards: those are bugs, defects that need to be handled

Blue and white cards are estimated in points in Xanpan, to do that teams use planning pokers like in XP. Because of their unpredictable nature, Red cards are those “estimated” after having been completed.

Those cards are then used to setup the Team board (physical or virtual).

Planning meeting

This is how it is suggested to run the end of each iteration:

Retrospective

Retrospective could be formal or not (simple dialogue). It could be held at the end of the iteration routine or not. It could happen or not… At the end it’s a team decision.

“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.” — Allan Kelly

Work in routine

Here is the recommended routine:

Plan beyond the iteration

Quaterly plan is a plan for the 12 next weeks, filled to approximately the capacity of each iteration (consider it as the WIP limit of the iterations). Quaterly plan is a rolling plan; it is in a constant — perhaps daily — state of flux.

Allan explains something fundamental and often forgot : planning is not scheduling.

Plan: looking into the future to learn about what might happen.

It helps to prepare a possible future (For it we can use technics like Design thinking for example).

Where is the Kanban part in it?

From here, I have explained mostly mechanisms you may already know from Scrum (iterations, planning, …) but Xanpan is also a Kanban-style flow:

  • It allows both planned and unplanned work

  • Work can flow from iteration to iteration

The Work can flow because we really want Blue cards to bring value. Often by splitting too much them to make them pass in a single iteration we do not produce any value. The idea is to keep them big enough to truly bring value.

What about commitment?

Teams are encouraged to try and do more work than they expect to do. Everyone needs to accept that not all work taken into the iteration will get done.

Statements about what will be delivered at the end of the iteration are statements of probability.

Team centric

In Xanpan, we admit than a team can work on multiple work streams at a time it is more realistic don’t you think?

Visualise

To organize our work in Xanpan we use a big board that represent the state of the team, not the state of a particular project or product.

  • Planned: stock of cards for the current iteration

  • Unplanned: stock of unplanned work

  • Priority: work for today. Defined the morning of the day during the stand-up.

  • Work in progress

  • Test: cards under test

  • Done: work has been done & respect the Definition of Done

Unplanned work

Unplanned work does not mean there is no value to do it. That’s why the unplanned work is stocked on the board and will be prioritized by BA or Product manager a few minutes before the stand-ups.

What about technical practices?

For Allan Kelly teams that deliver software should really embrace XP practices. It enables to inject quality for free.

If we try to define what is a successful software it’s the one that needs rework because we will want to: add new features, change existing features, extend it, …

Successful software lives and needs to change over time. If software is not changeable, then it cannot change as it needs to during its lifetime, and it will be hard to remove any defects that are found.

Rework is really part of the lifecycle of a successful software. The question is how easy is the rework?

Low quality makes rework harder, and therefore slower. High quality makes rework easier, and therefore faster.

How to define quality of a software product?

  • Measure defects: quality is inversely proportional to the number of defects seen in a system

  • Measure the maintainability: software needs to be easy to change so measure cost of changes and its evolution in time.

Practices

To inject quality in, Allan recommends those technical practices:

It is not an exhaustive list and every developers should complete it with all the practices that make sense in their own context.

Me I would add others like Domain Driven Design, Mob Programming, Property-based Testing, Event Storming.

Experiment

Xanpan is a hybrid method built from pieces of other Agile processes and elsewhere. Do the same and create your own “xanpan”.

“Create your own process, don’t follow someone else’s prescription.” — Allan Kelly

Just do it: action over words

  • 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 frame: check

  • Decide to keep or drop

Wrap up

Xanpan is not a prescription.

"Xanpan is the kind of stuff that should emerge from every agile teams when not constrained by some “agile” dogms." - Yoan Thirion

To go further

  • Discover slides of my talk about it here :

  • Here is the video of my talk about Xanpan @AgileEnLigne :

3 roles in the planning

You can use the to find inspiration for experiments.

Buy the book from Allan Kelly here :

Agnostic agile :

Heart of agile :

Agile Pick’mix
https://www.amazon.fr/Xanpan-Centric-Agile-Software-Development/dp/1291852735
https://agnosticagile.org/
https://heartofagile.com/
Xanpan — Team Centric Agile software development