Xanpan — a team centric agile method story

Xanpan is an agile method created by Allan Kelly.

Allan has really done a great job by explaining it in his book “Xanpan — Team Centric Agile software development”.

Image for post
Image for post

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.

Image for post
Image for post

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.

Image for post
Image for post

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.

Image for post
Image for post

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.


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.
Image for post
Image for post
3 roles in the planning

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:

Image for post
Image for post


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:

Image for post
Image for post

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?

Image for post
Image for post

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

Image for post
Image for post

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


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.

Image for post
Image for post
  • 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.


To inject quality in, Allan recommends those technical practices:

Image for post
Image for post

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.


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

You can use the Agile Pick’mix to find inspiration for experiments.

Image for post
Image for post

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.

Discover slides of my talk about it here:


Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store