Ones and Threes

We’re a small scrum team. Very small. Temporarily down to 2 developers, one of whom is part-time scrummaster, plus one product owner. The developers are responsible for not only new development, but also function as 2nd-level production support and helping stakeholders develop their user stories into a do-able form (acceptance criteria, etc).

This leads to conflicts of priorities. 2nd-level support can be hugely disruptive, taking out one developer from a half-day to 2 full days for some issues, which has the effect of stopping the sprint if one developer is on holiday. Partially complete sprints are a too-regular ocurrence therefore.

We’ve attempted to ring-fence the two non-sprint activities. Support work goes to the ‘duty developer’ (a role that rotates between the two developers) and should be time-boxed to no more than 2/3 of a working day in total. And story development should take place only in ‘jog week‘ (a week between two week sprints).

In practice, both non-sprint activities break out of their respective constraints. E.g. when the business decides an unhappy customer needs placating NOW, the team has to do it, and the scheduled sprint work suffers, and of course some user stories are therefore delayed by a full sprint cycle.

Essentially, it’s a combination of

• a team with a responsibility for both development and an unpredictable support workload
• a team too small to absorb workload fluctuations easily

that means that scrum is not working well for us.

So Kanban looks like a solution for two reasons.

Firstly, no timeboxed iterations should mean that if there’s a change in priorities (insertion of an urgent workitem), then less urgent items move back one place in the queue, not a full 3 weeks.

Secondly, the business will need to weigh priorities between regular development and must-do items arriving via production support. I think the whole process will become much more transparent, in contrast to the current situation.

The details of our implementation need still need sorting out, but the idea is building momentum and it seems likely we’ll go for it.

Looking forward to it.

Technorati Tags: agile, kanban, lean, scrum

I like the thinking that’s gone into this white paper and the associated presentation from Dean Leffingwell. It pulls together all the artifacts we deal with in the agile world, from stories and tasks right through to epics and themes, and pulls it all together into a consistent model.

Some intial thoughts: Some of the deep detail may go too far. For example my reading of the model is that stories are always subordinate to a higher level feature, and similarly features are always part of a release. For the perspective of a team working on a product that has matured somewhat, we find ourselves working on a mix of both large features and small enhancements to existing functionality. Should we consider those small enhancements as features in their own right in this model, or create artificial features to encapsulate them ? Neither I think, the small enhancements exist as stories in their own right, without an encapsulating feature.

I find it interesting to compare this model with that advocated in the Open Agile process. This also extends the concept of a backlog item beyond a mere story, but the extension there encompasses Quality Items (bugs), Obstacles (impediments) and Calendar Items. Again I find this relevant to my own situation where working with a relatively mature product entails more than just dealing with new functionality neatly boxed as user stories.

I look forward to further developments towards a ubiquitous language (if not a ubiquitous model) suitable for all flavours of Agile.

Technorati Tags: agile, model, openagile, scrum