Posts Tagged ‘scrum’

Kanban for a small team ?

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: , , ,

Posted by Andy on May 12th, 2009 No Comments

Features, Epics and Themes

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: , , ,

Posted by Andy on May 6th, 2009 No Comments

Sprint, Jog, Sprint

Since starting with scrum, we’ve always done consecutive sprints. Two weeks of coding (Monday-Friday for the most part) near the end of which we do activities like estimating, planning, sprint review, retrospective.

We’ve reached a point where, for a variety of reasons, that doesn’t feel right anymore. Reasons include:

  • The product is released and fairly mature. Coding work includes a lot of tweaks, enhancements, bug-fixes in addition to new development.
  • Planning and estimation feel rushed. Applying arbitrary time-boxing to these activities doesn’t feel right when a little extra chat / research can prevent nasty surprises during the sprint.
  • We don’t seem to have any proper time or place to help stakeholders develop simple requests for functionality into reasonable user stories that can be estimated.

So we’ve adopted a new practice: A week between 2-week sprints that we’ve called (after going through some flippant alternatives) jog week.

So now the pattern is something like this:

  • Product owner meeting works on the backlog every Tuesday. (During sprint weeks this is mostly adding and reviewing new stories with stakeholders, during jog week it’s primarily prioritisation)
  • Developers do estimation on every Wednesday (jog or sprint) for an hour. We seem to get through maybe 8-12 stories in that time.
  • Planning (including tasking user stories) takes place on Thursday of jog week.
  • Sprint Review takes place on the last day of the sprint
  • Besides the above, the rest of jog week is taken up with bugfixes and ad-hoc technical requests, helping stakeholders develop user stories to the point where they can be estimated, refactoring, reading coding/agile blogs, etc.

We’ve still got to work on the details, but based on the two jog weeks so far, we’ve got more than enough to fill up that third week.

Technorati Tags: , , , , , ,

Posted by Andy on April 8th, 2009 No Comments

Mapping The Backlog

This post about creating the product backlog as a map deserves more attention than I’ve given it so far, but I really like the idea and I’m coming back to it. Wish we’d been able to use it when we were redeveloping our current application in rails.

Technorati Tags: , ,

Posted by Andy on October 18th, 2008 No Comments

Ken Schwaber talks Scrum at Google

Another enlightening video from Ken Schwaber.

Particular points I took away from this one.

  • In the sprint, aim to deliver everything. Done. Software written, UATed, documented, load tested, ready to roll.
  • In scrum, you get news early (good or bad). From sprint 2, you should be able to begin making projections about how long the rest of the project will take.

Technorati Tags: ,

Posted by Andy on September 16th, 2008 No Comments