1. Xanpan Principles

Boiling Xanpan down to a core results in a few principles that guide thinking, and lead to a number of specific practices. Most of these principles and practices will look familiar to anyone who has worked with Agile and studied Scrum, Kanban or XP. However, Xanpan’s formulation is subtly different from all of these: it mixes these principles and practices differently.

Deeper still, underlying all of these are even deeper principles and laws. Some of these are specific to the software industry - I will elaborate these later - and some are broader still. The key, deepest, principles I refer to as ‘Philosophy’. These make up the “I think therefore I am” bedrock.

1.1 Work in iterations

The iteration, or sprint, is a well-established Agile practice. Working in regular cycles provides a rhythm to work, and also imposes a deadline - actually, a recurring deadline. As I have discussed elsewhere, humans are actually quite good at working to deadlines. Xanpan seeks to harness this effect by having teams work in fixed length iterations.

I like to use the train metaphor. A traditional project is like a train leaving London King’s Cross for Edinburgh Waverley station. Trains are infrequent, about every two hours if memory serves. And to get the cheapest tickets, you need to book in advance. As a result we check the timetable in advance, we book our ticket, and if there is any doubt about who needs to go on the train, or what we need to take, we take it. The risk of leaving something behind is too high.

I arrive at the station in plenty of time. If while I’m waiting a colleague phones and says “Hey, we’re having a beer in the Euston Flyer - want to join us for a quick half?”, then I look at my watch and say “Sorry, my train leaves in 15 minutes”. The risk to my schedule is too high, so I avoid changes. In the extreme, if one of my colleagues is late arriving for the train, I try to hold it back, I argue with the guard, I beg, I hold the door open in the hope my colleague makes the train.

When the train does leave I immediately call Edinburgh to say “I’m on my way”; when the train becomes late, I deny it or hope it will fix itself. Then I think “Well the taxi at the other end will only take 5 minutes, not the 20 I allowed”. Eventually the whole train is late; with other passengers, I argue with the guard to throw some people and packages off the train to make it go faster.

Eventually the train calls at Edinburgh Haymarket, and everyone gets off saying “That’s close enough”.

In contrast, working in iterations is the equivalent of getting the London Underground. It isn’t perfect, it has problems, but generally trains run, and they run regularly. I enter the Underground when I am ready; except for the first and last trains of the day, nobody checks the timetable.

If a train pulls in and it is over-crowded, I can decide: squeeze onto a packed train, or wait two minutes for the next. If I am lucky there is a sign that tells me how many minutes the next one will be. And if while I’m waiting someone calls me and says “We are in the St Pancras Champagne Bar, fancy a drink?” I have an option. I can decide: “Get the next train and get home when I planned, or enjoy a drink and get home 30 or 40 minutes later.” I have options. There will always be another train.

1.2 Team-centric: flow the work to the team

Xanpan is team-centric: the team is the production unit, need goes in, working - even valuable - software comes out. This is the machine, the goose that lays the Golden Egg.

Teams everywhere differ: some are large, some are small, some have testers, some don’t, some have requirements people, some don’t; some are collocated, some are distributed. And some work on one stream of work - call it a ‘project’ if you will - and some work on multiple streams. In fact, most teams of my experience - both as a team member and an observer - have to deal with multiple streams of work.

Multiple streams might be two projects at once, project A and project B. Or it might be working on a new product while maintaining an old one. Or it might be the team working on project A but individuals being pulled some days to work on something old. These streams might come from different sources, different business units. Or they might come from the same source.

Consequently some work can be known about and planned in advance, and some work just appears, unplanned. There seems to be some unspoken law which mandates that the later work appears, the more urgent it is.

Xanpan aims for stable teams that accept both planned and unplanned work on multiple streams.

1.3 Work to improve Flow

Hand in hand with team-centricity is flow. Work arrives at the team from somewhere, somehow. This is inbound flow. Ideally work is flowing into the developer (see Coplien and Harrison 2004 for the Work Flows Inward pattern). Then it has to flow out - perhaps via testers, operations, deployment, and finally to the customer. The actual time needed to do the work may form a very small part of the end-to-end elapsed time.

As with Kanban, Xanpan aims to reduce the overall end-to-end time by improving the flow, making it smoother, more regular, more predictable. Improving flow can also mean levelling flow - reducing the peaks and troughs in work patterns - and constraining work to deliver an overall improvement.

The key to improving flow in Xanpan is allowing work to span more than one iteration. This is heresy in some circles and some texts.

1.4 Quality is free (provided you invest in it)

Philip Crosby wasn’t writing about the software industry, but he could have been (Crosby 1980).

There are those in the software industry who believe there is a dial on the wall marked ‘Quality’. If you turn the dial down, quality falls and work happens faster. Turn it the other way, dial up quality, and work slows down. They are wrong. This might be true in some industries, but not software.

In software development the dial is wired in reverse: if you want to go fast you dial quality up; when you dial it down, you go slow. Capers Jones has devoted most of his career to studying software development quality and metrics, and he is unambiguous:

‘Projects with low defect potentials and high defect remove efficiency also have the shortest schedules, lowest costs, and best customer satisfaction levels.’ (Jones 2008)

To be clear, when I use the word ‘quality’ here I am not talking about features, polish, leather upholstery or just about any other external attribute. Indeed I’m not specifically talking about software design or architecture characteristics - although they are implied.

When I say ‘quality’ I am specifically referring to defects, bugs - or to put it another way: low quality implies rework fixes. High quality work does not need rework.

This is not an excuse to gold-plate and over-engineer systems; work may well need to change as we learn things, but we should not be delivering work which quickly requires fixing. All software needs rework. That is the nature of 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.

In the same book Jones says:

‘IBM was also the first company to discover that software quality and software productivity were directly coupled and that the project with the lowest defect counts by customers were those with the shortest schedules and the highest development productivity rates. This phenomenon, discovered by IBM in the early 1970s and put in the public domain in May 1975, is still not understood by many other software-producing enterprises that tend to think that quality and productivity are separate issues.’ (Jones 2008)

Of course rework occurs not just for defects: requirements changes and unforeseen changes can result in reworking existing code. And ones man’s bug is often another’s change request. I am perfectly happy to have these debates, but only when a team is approaching zero defects. Until then the team needs to work to improve quality and reduce rework.

Quality is important, because when quality is low there needs to be rework, and when there is significant rework other parts of the Agile jigsaw just don’t fit together. High quality is essential to Agile working:

• Rework destroys flow: work must move backwards, work creates work because work creates rework.
• The need for rework means stories and tasks can’t truly be considered ‘done’.
• When stories aren’t truly ‘done’ iterations are an illusion, because hidden work is flowing between the iterations.
• Metrics are destroyed because work that looks ‘done’ isn’t.
• Developers, testers, managers and others spend inordinate amounts of time prioritising, reporting, managing and even doing rework rather than delivering value.
• Organisations spend inordinate amounts of money on testing resources and cycles: the need for test demonstrates that quality has been sacrificed.

As far as I am concerned anyone who thinks reducing quality is a good way to speed up software development shouldn’t be working in the industry.

The need for high quality is why Xanpan embraces all the XP technical practices explicitly. These practices, specifically test-driven development, raise quality, thereby reducing defects and rework. (The software craftsmanship movement continues to advance this cause of quality, and I encourage all to follow the latest thinking here.)

Quality

Any mention of quality, especially high quality, demands a proper discussion of what is quality. Quality will be discussed in more depth in an appendix.

For now when I speak of quality I am essentially speaking of two attributes - qualities if you prefer - of a software product:

• Defects: quality is inversely proportional to the number of defects seen in a system, i.e. lots of defects imply low quality; few (or no) observed defects do not by themselves imply high quality, but such a status is a precondition for high quality.

• Maintainability - changeability and extendibility: 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.

There are other attributes that customers, users and the development team might like to include when talking about quality for a given product. Indeed I would encourage all teams to think about what constitutes quality for their product. However I believe that these two attributes of quality apply universally for any software product.

That said, this definition of quality is not a reason to over-engineer, over-design and gold-plate software. The Xanpan approach is to achieve these attributes, not through ‘big up-front design’, but through repeated design sessions, ‘little and often’, constant attention to technical excellence and delivery of working products in the short term.

Such an approach leads to a form of rework, but this is rework because things have changed, knowledge has improved, requirements have changed, new demands have emerged. This is not rework because fault has been found with existing work.

1.5 Visualise

There is surely no team sport in which every player on the field is not accurately aware of the score at any and every moment of play. Yet in software development it is not uncommon to find team members who do not know the next deadline, or what their colleagues are doing. Nor is it uncommon to find managers who have no insight into the work coming their way, or indeed what happens to work when it leaves them.

There are multiple ways in which teams can visualise their work: whiteboards, flip-charts, burn-down charts, cumulative flow diagrams, stickies, posters and many many more.

Software development is an extremely abstract activity. We do things that cause sub-atomic particles to move about in a machine. We work in obscure languages that might look mathematical to some, but look decidedly like natural language to pure mathematicians.

Visualising work helps people learn, it helps people improve flow; visualisation makes it difficult for problems to hide; it creates shared understanding and shared learning. If we cannot see, we cannot learn. If we cannot learn, we are doomed to failure.

1.6 References

Coplien, J. O., and N. B. Harrison. 2004. Organizational Patterns of Agile Software Development. Upper Saddle River, NJ: Pearson Prentice Hall.

Crosby, P. B. 1980. Quality is free : the art of making quality certain. New American Library.

Jones, C. 2008. Applied Software Measurement. McGraw Hill.