[kforge-dev] Proposal: online KForge planning game

[John Bywater]

Rufus and I have talked about making the KForge project more open, and 
to this end we wanted to attempt to do the planning game online. For the 
last 15 iterations, it's always been face-to-face.

The general concerns of distributed agile software development are 
described in a few places, for example in [1], but the solutions are 
experimental.

In short, we can start to make "distributed agile" work by tailoring the 
agile approach to our distributed context.

Particularly I suggest we:

1. Invest in bi-lateral remote communication - all the usual suspects 
(IRC, IM, VoIP, etc.) can be used to increase communication capabilities 
between individuals, and thereby to avoid "death by distance". Attempt 
to get good at distributed pair programming....

2. Generate and publish the dates and serial numbers of iterations well 
into the future, with a notice that a planning game will be held at the 
start of each iteration, and publish a description of the planning game.

3. Split iteration planning game into four distinct parts:

(i) at any time during the project, the customer writes and publishes 
user stories to an issue tracker, the customer estimates and publishes 
an estimate of the benefit of each story to the issue tracker, the 
customer makes sure there is always a good "head" of unimplemented stories;

(ii) at the start of each iteration, the customer chooses as many user 
stories as completed on average during the last few iterations, marks 
these within the issue tracker (e.g. against a Trac milestone), when 
done the customer notifies the mailing list that this descision has been 
made;

AND THEN, EITHER

(iii) when the selected story list notification arrives at the 
developers inbox, the developers continue with the iteration by 
implementing the user stories until available working time expires.

OR (if more analysis and planning accuracy is desired for the price of 
less implementation time, or if there are more than a very small number 
of developers)

(iii) when the selected story list notification arrives at the 
developers inbox, the developers self-select stories (somehow), and then 
break the stories roughly down into tasks, estimate each task, add task 
estimates up to create story estimates, and create a total estimate for 
the selected story list;

(iv) if the total task-based estimate differs greatly from the available 
time, the customer bumps or pulls stories, perhaps pulling some extra 
task-breakdown and task-estimation work, until the plan is thought to 
fit the resource;

(v) when the iteration plan is agreed by everybody, the developers 
publish their task breakdown on the issue tracker against the milestone, 
notify the mailing list that their planned tasks are pubished, and 
continue with the iteration by implementing the user stories task by 
task until available working time expires.

4. As the iteration continues, the developers track the completion of 
their own tasks, and notify the mailing list and the customer when user 
stories are completed, then the customer either provides feedback or 
accepts the user story implementation, but the customer tracks 
completion of the user stories. Developers and customers communicate as 
much as they can, and sometimes pay each other visits.

5. Regular method retrospectives to provide a place for discussion of 
the process. Perhaps we could post a standard invitation at the end of 
each iteration to provide feedback on the development process as it was 
during the last iteration?

6. (Optional extra) We could maintain a release plan by saying that 
three iterations make a release, using the latest average 
stories-per-iteration count to estimate how many user stories will be 
implemented in each release, and then listing out (in order of estimated 
value) the unimplemented user stories against each release. The customer 
could update the release plan each release, or every three iterations.

Perhaps we could try the above routine for this iteration?

With my best wishes,

John.

[1] http://www.agilealliance.com/articles/steindlchristophdistr