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

Cornwall nominated fror Agile awards

I’ve tweeted and blogged about the Cornwall Agile Programme before - something I like to call the ‘Cornish Software Mines’. So it is with great pride that I’m please to announce that the programme has been nominated for an award.

The Agile awards are presented as part of the Agile Business Conference and ‘Agile Cornwall’ has been nominated under the ‘Best use of Agile in the Public Sector’ - officially the programme is part of the ‘Convergence Programme for Cornwall & Isles of Scilly’ so the nomination is under this name.


This autumn I’ll be delivering a couple of case studies of the programme and the companies which have benefitted. The first of these will be, fittingly, at the Agile on the Beach conference in Falmouth. This isn’t a coincidence, the conference is a spin-off from the programme. This will be the most comprehensive case study as it will include presentations from several of the companies who have benefitted from the programme.

A few weeks later a cut down version of the case study will be appearing at the Agile Business Conference. If you miss it there I’m sure it will have another outing before long.

In the meantime, I’ve posted a case study of the work I’ve done with Sullivan Cuff Software on the Software Strategy website.

Retrospectives - common or not, a small survey

I’m still experimenting with Dialogue Sheets for Retrospectives (the download page, and my earlier blog entry) and so are other people. Of the feedback I’ve had so far it has been overwhelmingly positive. Perhaps people who aren’t positive don’t bother trying them.

The sheets are free to download but I do request people register. My objective here is to obtain more feedback. Periodically, like today, I get the e-mail addresses of those who have downloaded and I send a polite note saying “Any feedback?”.

In registering I ask a couple of other questions. One of these questions is: “How often do you hold a retrospective?”. I thought it would be interesting to share the results of this data so far:

How often do you do a retrospective?

38%	Every two weeks or more often
21%	Never
16%	At least once a month
15%	I am a retrospective facilitator and so hold many
6%	Rarely
3%	At least once a quarter
1%	About every six months

This is good to see, about 54% of people are holding retrospectives with the frequency you would expect from a Scrum, XP or other type of Agile team. But sadly the second biggest group is never holding retrospectives, 21% of people. And 10% are holding them rarely or very occasionally.

Now think again, this data is not representative. 15% of people are not retrospective facilitators (e.g. Scrum Masters, Agile Coach, etc.). The people who download these sheets have an interest in retrospectives, this group is self-selecting.

The implications of this are that an awful lot less than 54% of people are doing retrospectives with anything near the frequency one should expect from an Agile team. Given that retrospectives are the primary means of learning in an Agile team I suspect that means that an awful lot of teams are are not really practicing Agile as described in the books.

I have long suspected that retrospectives are actually one of the more advanced Agile techniques and are far from common. I think this data supports that argument, but at the same time I think they are more common than I tended to think, maybe thats the progress of 3 years.

Abandon Hope all ye who enter Agile

Earlier this week I had a conversation with Benjamin Mitchell about an entrepreneur he’d done some work with. Benjamin had been suggesting a lean start-up approach to the business in which the entrepreneur worked to validate his business idea early and gradually build the product one validated step at a time.

Things didn’t go well, the understanding I came to from Benjamin’s story - although his might be different - was that the entrepreneur was very attached his business idea. It was pretty well formed and he could imagine it working. In popular culture entrepreneurs are often seen as iconoclasts who battle doubters, naysayers and banks to bring their ideas to life against the odds. Benjamin was just another doubter.

Now I tend to agree with Benjamin’s approach because it is very difficult to tell if a new business idea, indeed any project, will work until you try to build it. But building it is expensive so I advocate a “Try, fail fast, fail cheap, move on to the next thing” approach - I don’t think this is that different to lean start-up thinking but as I’ve not read the lean start-up book I don’t really know.

I don’t just advocate this approach for new businesses, I advise it for established businesses embarking on a project. My logic is: you can’t be sure a product will work in the market till you try it, nor can you plan a project until you know how fast (velocity) the team will work. In fact, until the team trys to work together and build something you don’t have any data on which to project plans. Making estimates without data is little better than guessing.

Thus, I advise a Mao like approach to corporate projects, “let a thousand flowers bloom” - start multiple small projects, small teams and use portfolio review to remove those that don’t seem promising and reallocate resources to those which do seem promising - or launch more experiments.

Unfortunately, like the entrepreneur, people get very attached to the idea of a project so it gets momentum. Big corporations respond by only starting projects in which they have a high degree of confidence. That means they do a lot of pre-project work - planning, designing, etc., this in turn makes it difficult and expensive to start projects, which in turn means that any project that does get started already has momentum. And it means that once underway the project finds it difficult to cope with change.

It seems to me that successful projects in corporations are often the result of one person who wants the project to happen and does what is necessary, not unlike entrepreneurs. In both cases a strong willed, capable, person makes something happen. That person needs to be motivated, they need hope, they need ambition and hope. Such people are going to kind who ignore naysayers and doubters.

The Agile approach - try, gather data, evaluate, or my “fail fast, fail cheap, retry” approach are not going to go down well with the kind of pig-headed, obstinate, passionate, do-anything-it-takes, approach which has made many successful projects a success. Quite the opposite.

Interestingly Benjamin had another example of a company which does take the “fail fast, fail cheap, try again” approach and was staffed by passionate, hopeful, people. From what he told me these people were passionate about the process as much as they were passionate about the products they tried. They could accept regular failure of good ideas because they saw the process working, and perhaps more importantly, could transfer their hope to the next idea. There was always a next idea.

What I am saying is: Don’t rely on hope to get your projects done, use data - be empirical not emptional.

Finally, I should say, that while I talked much of this over with Benjamin he would be the first to point out unvalidated steps in my thinking, and ungrounded assumptions I’ve made. So maybe this entire entry is really a hypotheses. The hypothesis is:

“The trial and error approach of Agile is unlikely to please those who get passionate about an idea and want to move heaven and earth to make it happen.”

I’ll let you, dear reader, decide for yourself on that hypotheses. If you have any evidence - to support or disprove - my hypothesis please add a comment below.