Xanpan

For a little while now I’ve been quietly talking about my new Agile method. The clue is in the name: Xanpan - pronounced “Zanpan”. Most obviously Kanban and XP (Extreme Programming), its a fusion.

Its not so much than Xanpan has any new radical ideas in it, its more than it is a synthesis of ideas from several Agile methods plus my own. It contains a fair chunk of what I would call “product management ideas”.


Xanpan is a little more than that, in takes from Scrum as well as XP, and from Lean as well as Kanban, plus there are other ideas in too.



I’ll write more about Xanpan in future but for now here are the essential features, and where it steals them from. A little rough and ready but I wanted to share this and get some feedback.

From Extreme Programming: The technical practices

• Test Driven Development plus Automated Test Driven Development. If you want to adopt BDD then go right ahead
• Lightweight, near time code review, better still pair programming if developers are happy with it
• Continuous integration: with tests and static analysis tools as part of the build system
• Rough up front design: no up front design is wrong, but so too is design that takes weeks or months. If you need a design session it is probably part of the planning meeting with all the developers around the whiteboard for an hour or maybe two
• Refactoring to keep the code soft - its software, emphasis the soft
• Shared code ownership
• Minimise documentation, accept tacit knowledge as part of the development process.
• Velocity measurement and “yesterday’s weather” approach to deciding what to put in the next iteration

From Kanban: Process flow

• Have a visual board to track progress
• Divide the board into columns which represent you process - probably more than just: Todo, In Progress and Done. Columns are usually come in pairs: a queue then a action which draws from the queue. Work to improve the flow and change the columns as you go
• Work in progress limits - usually on action queues, occasionally queues may be limited too
• Improvement comes from improving flow
• Minimise the time spent estimating, if possible abolish estimates and use statistically derived approximations, i.e. averages
• Cumulative flow charts

From XP / Scrum: Process rhythm

• Use iterations to establish a regular rhythm to the team
• Iterations start with closing the previous one: review work done, update statistics, conduct a retrospective. This is followed by a planning meeting: work is presented, estimated (if need be) and scheduled
• Stand-up meetings where appropriate
• Burn-down/up charts where appropriate
• User Stories are the default requirements capture tool although Use Cases, Planguage and more informal approaches are acceptable too. If using User Stories then do not use more than three levels of division

For task management Xanpan builds on Blue-White-Red, which is itself a XP/Scrum fusion.

From Lean: Culture of improvement, Kaizen and Learning

• Retrospectives are not enough: Leaders should undertake personal reflection
• Rehearsal: Teams should undertake formal and informal training together; deliberate practice as Kevlin Henney and Jon Jagger like to say
• Team Coach: Each team should have a coach, different coaches may focus on different things so there may be more than one coach. Except in large teams (over 12 people) and in the early days of adoption the coach is usually not full time on a team. The team is there to help the team adopt practices, learn and reflect.
• Individuals have multiple skills and should all muck in, but there are specialists in some areas.

Somethings Xanpan doesn’t take:

• Kanban’s stop the line quality control: sometimes it is appropriate, sometimes it isn’t. Keep regular retrospectives, part of your rhythm
• Scrum Master: teams will have a Manager or Project Managers, or may be lead by an non-commissioned manager, e.g. Team Leader, Technical Lead, or similar
• Anti-manager ethos: Management is part of the solution, not the problem. Unfortunately the quality of IT and development managers is general is poor; good management can be really powerful

Something Xanpan doesn’t like but doesn’t outlaw (because it can’t):

• Matrix management
• Distributed teams, particularly teams in different timezones

Something I find missing in all Agile methods to date is the right balance between engineering and requirements. Therefore....

Xanpan broadly follows the 10 Step Requirements Model but recognises this model is not broad enough to cope with all scenarios. No model ever will be.

On requirements Xanpan believes:

• There should be a dedicated requirements role staffed by a trained/experienced Product Manager or Business Analyst; both is probably overkill
• There should be a clear business case setting out why a team or project exists. The business case is not a shopping list of features, nor is it a large document but it should allow someone to decide the work is finished
• Customers are not the only stakeholders. Each stakeholder will make their own judgement about the success or failure of work therefore each stakeholder needs to be considered
• Evaluating the benefits of completed work is as important as deciding what work should be undertaken next. There is no point to developing more software if the software that has been delivered so far is not valuable.

And some more:

• If the team has an architect they should also code; the architects role is to help create a shared understanding of the architecture and educate less experienced team members.
• Teams should be kept together and not broken up when work finishes or changes; bring the work to the team, not the team to the work
• Block and impediments should be tracked to see which ones occur repeatedly. If a team cannot resolve an impediment themselves then the leader or manager steps in, in effect it is the start of an escalation
• There are three version of Xanpan: Evolutionary, Incremental and Iterative - these build on the ideas in my Agile Spectrum article. Iterative is the most compatible with existing corporate culture and project management methods - salami slice requirements; Evolutionary is the extreme - goal directed working
• Xanpan adopts the three planning layers described in my Three Plans for Agile article and encourages Goal Driven Projects.
• Xanpan believe management has an important role to play in the development process (but a lot of development managers are not up to the job)
• Whenever possible put bug-fixing in a separate stream of work; but staff it with the same people, rotate people
• Keep teams together: bring the work to the team, rather than the team to the work

Underlying it the Xanpan philosophy is about:

• Quality is free: automate as much testing as you can, although you probably can’t automate 100%


• Prioritisation is vital and omnipresent: there is no such thing as too little time, just mis-understood priorities


• People are key to good software development but there aren’t enough good people to go around, so we need to improve the people we have and help them work more effectively. And we need to grow more good people


• Agile is not about what you do but what you achieve; measure outputs not inputs


• You can always improve


• Customer/End user involvement is key to building a successful system.


• Xanpan is a pick-n-mix of bits of various development methods and adopters are encouraged to continue the approach


• No process or Methodology can cope with all situations, and if it could it would be too big to write down or learn, there adaptation is always required and people need to think


• The process should be changing, if you are doing Xanpan the same in six months as you do today you aren’t doing Xanpan