Not angst, but reflection prompted by a 2 day SCRUM master training course run by Michael James of Danube.com.
We’ve been running as a SCRUM team since 1st April when most of us were transferred to the Symbian Foundation from Nokia – “Agile is the new Black”, so we never really considered any other way of organising the development work. I’ve been the Product Owner for the team for all 5 months, but this is the first actual training I’ve had for SCRUM, though some of the team had SCRUM training at Nokia.
I thought it would be useful to reflect on what we’ve been doing, and compare it to what was in the course, which included both the basic SCRUM methodology and a lot of examples of how people have applied it.
SCRUM, or “SCRUM, but…”?
Strictly, the SCRUM methodology is 3 roles, 5 meetings and some artifacts. Roles first…
I’m the Product Owner, managing and prioritising the product backlog. Andrew Simpson is the SCRUM master, and we have currently 9 other team members. The team has grown a bit too large again – when this happened before there was a “sub team” of 4 people focussed on one particular area, so we split into separate teams, and Mike Kinghan took charge of the new team. I continued as Product Owner for both teams, but I found I was just re-writing Mike’s stories before accepting them into my backlog, so over the last few sprints we’ve effectively separated the backlogs and Mike is now the Product Owner for his team.
Now the meetings…
Team area - there are a few more desks out of shot
We have a daily standup meeting around a board with index cards for tasks – tasks start at the left side, move to the middle when in progress and end up at the right when completed, next to the backlog items (in white) that they relate to.
Task board part way through a sprint - cards swim towards the backlog item
The standup meeting is at ~10:30am each day and lasts for about 20 minutes. I normally go to the standup, and I sometimes volunteer for a task if I can commit to complete it and it helps towards one of the important stories.
Our sprints run Thursday to Thursday because we have long build times, and it’s important to get good use out of the weekend – if we spent Friday afternoon planning we could have machines sitting idle for 72 hours.
The Sprint Planning meeting starts at 3:30pm on Thursday with my presentation of the stories at the top of the backlog, then the team works through them identifying the tasks. This is much like the Sprint Planning meetings in the training course, but there isn’t any sense of the team committing to complete the stories and saying “enough, we can’t do that one as well”.
At the end of the sprint, we have a Sprint Demo meeting at 11am on Thursday, where I go through the backlog asking for demonstrations, and make a judgement about whether or not I accept that each story has been completed. We usually don’t complete all the stories, and sometimes complete lower priority stories instead of the top priority ones.
We don’t have an explicit Sprint Retrospective meeting, but we have occasional stories which explictly ask for a review of some major activity with recommendations for improvement, and the team aren’t shy about including improvement tasks or requesting improvement stories when they see a need. Agreeing to put more effort into the top priority story is one example of a retrospection outcome which happened without the formal meeting.
We don’t have the un-named meeting for grooming the stories in the Backlog, but that’s generally what I’m doing in the hour or so before the Sprint Planning meeting. When stories haven’t been completed, I may modify them to reduce the scope, or sometimes to add a bit more before putting them back into the backlog.
And the artifacts:
I maintain the Product Backlog as a spreadsheet on Google Docs which contains a prioritised list of “user stories” in the “As a (role) I want (something) so that (benefit)” format.
The top 4 stories in the current backlog
For the Sprint planning meeting I put the stories for the sprint into a Powerpoint presentation, print it out in the “handout” format, and cut the printout up into reasonable sized Backlog Item cards. At the Sprint Planning meeting the team does “planning poker” to establish a common understanding of the work, and produces a set of tasks for each story. The tasks are written on cards, and they go with the Backlog Item cards onto the Sprint Backlog board (pictured above).
We don’t have a Sprint Burndown Chart because we don’t estimate the size of individual tasks, but we argued that this is one-off work which wouldn’t be representative of later team activity anyway. We do put T-shirt sizes on the stories (as a side-effect of planning poker), but we don’t have a Product Burndown Chart – that’s something new I learned about in the course.
Hmmm, I counted five instances of the B-word in there, so things to think about already…
Agile or aimless?
We started with a big pile of raw source code and needed to develop the ability to build and ship it as soon as possible (see my first blog posting for more details). We decided to use 1 week sprints to allow for frequent “corrections”, and I only wrote stories for the very near term.
The course guidance on when SCRUM is appropriate talks about a “chaotic” region where defined processes won’t work and am empirical approach is needed. That was certainly our situation: we had unknown amount of technical risk, and a belief that in Open Source the requirements are always malleable and subject to “do what you can” pragmatic adjustment. Writing just the near term stories was a way of navigating through unknown territory – pick a direction which contributes something to the vision, make some quick progress, see where you get to, and repeat.
Even if we had known about Product Burndown Charts, we would not be able to use them with this approach to the backlog: there is no set of stories to burn through, and no articulated vision of the “release”.
Having said all that, we do seem to have got the show on the road, and we’ve moved to 2 week sprints as a recognition that the first phase is over. The whole department is now taking time to set objectives for the next 6-12 months, and this would be a chance to have a more substantial Product Backlog with is leading towards a more clearly-stated goal.
What to change, if anything?
I think the team is too big again, so time for another split. “SCRUM at scale” was another subject discussed in the course, though our situation is slightly different from introducing SCRUM into a large organisation.
I want to try having a substantial backlog which gets all the way to our goals for the end of 2009, and try using the velocity and burndown analysis to see if we are likely to make it. This might also involve asking for a more distinct commitment to the Sprint Backlog, but I still don’t want to estimate individual tasks.