SKUA process

The following describes and, we hope, justifies the agile process we intend to follow in the SKUA project. Of necessity, we are adjusting the process to suit our situation, rather experimentally, and we expect to modify the process further in the light of our continuing experience.

Background

SKUA development will use an agile development methodology, rather than a heavyweight process of specifying requirements, architecture, design, implementation, testing, and finally discovering that what works isn't what's wanted, and what was wanted doesn't work.

Agile methodologies in general aim for a very tight coupling between requirements, implementation and release, cycling round the three in iterations as short as a week. They are characterised by having very little up-front design, and having a functional and releasable system at all times, which is incrementally expanded in the light of direct 'customer' requirements.

Specifically, we plan to use a variant of the Extreme Programming (XP) methodology, building on Ross Gardler and Neil Chue Hong's first attempt at an XP variant for distributed teams, James Shore and Shane Warden's The Art of Agile Development, and Kent Beck's original Extreme Programming Explained.

The reason for using a variant is twofold. Firstly, XP methods are typically described as working for teams of between four and 20 programmers, while we have two or three times 50% FTE; and because a notable feature of XP is its emphasis on co-location, to the extent of suggesting that all actual code is written by pairs of programmers sharing a single keyboard.

One cannot simply delete XP practices at random, however. The set of XP practices form a principled and coherent whole, and if we remove one practice, we must aim to replace it with one which has the same purpose. An important group of the XP practices which presume co-location are actually concerned primarily with communication, both between the members of the team and communicating the status of the project in a very immediate way.

Our process

The following are XP practices which are both clearly useful to us, and adaptable to a distributed team. We expect that both the list, and the way we adapt them to our situation, will change over the course of the project.

Visions

To counteract the centrifugal force of XP's focus on short-term goals, such projects benefit from having an explicit statement of the project's overall goals. So yes, we have visions.

'Customers'

XP relies on the notion of a 'customer', who takes an active role in the development process. The 'customer' is a representative of the person or entity who is going to receive the value, or benefit, of the delivered product. Their role is to act as a walking, talking, requirements document, ready to generate or elaborate stories, decide on priorities, and inform the programmers about how they wish to use the final product. At present, we have not made any provision for identifying such customers explicitly, though we have two applications in mind, written by AstroGrid colleagues (Paperscope and VODesktop) which we hope will be users of the SKUA product, and whose developers we aim to involve in the project in some way. Until this happens, we are going to have to be 'customers' ourselves.

User stories

One of the core XP notions is the notion of user stories, which are brief accounts of discrete blocks of functionality, described from the point of view of a user of the system, and small enough that they can be implemented in one or two days work. We maintain a list of UserStories, from which we select a set to implement at the regular iteration meeting.

The planning game is a precursor to the iteration planning meeting. At base, programmers and customers work through the list of extant stories, with the customers prioritising unimplemented stories, and programmers estimating the effort required to implement.

Iterations

The other core XP notion is the iteration. At the beginning of an iteration, the group selects a set of user stories which they plan to implement in that iteration. At the end, they review what has been completed, comparing actual to expected progress, and release the improved software. That is, the software is re-releasable at the end of every iteration, and is released in fact on release dates decided well in advance.

XP suggests iterations of one or two weeks. Since the SKUA programmers are generally working only 50%, we felt that two-week iterations would be best.

We expect to use Skype to have iteration meetings, but will experiment to see how well this will work, or if other technologies can help.

The iteration planning meeting consists of:

1. Retrospective of previous iteration (demo, number of stories completed, etc)
2. Select stories to include in next iteration. Based on the programmers' estimates of required effort, the meeting selects a number of stories whose effort sums to the effort represented by the set of stories completed in the last iteration.

Informative workplace

As part of its group of communication practices, XP promotes the notion of the informative workplace. Here, the status of the project -- in terms of the stories pending and committed to for an iteration, planned release dates, the group's velocity (the number of stories usually completed per iteration), and perhaps outstanding bugs -- are made as immediately visible as possible. It seems likely that some combination of a wiki page and Google Docs would be able to do the same work.

As an initial attempt at this, our StatusWhiteboard shows where we believe we are at present.

Stand-up meetings

A common XP practice -- part of the group focused on communication -- is the stand-up meeting. This is a daily meeting in which each participant reports very briefly -- taking around 30 seconds -- on what they got done yesterday, what they plan to do today, and what problems are blocking them. Like the informative workplace practice, this is intended to let status information percolate through the group, making it possible for all members to contribute to solving problems.

Although physical proximity is, again, one of the key components of this practice in the XP methodology, we hope to get much of the relevant benefit from regularly scheduled brief Skype conversations.

This document is licensed under a Attribution-NoCommercial-ShareAlike Creative Commons licence: