So we've just started our fifth two-week sprint since we adopted Scrum at Future Platforms; it seems like a good time to write about the things we've learned so far (and the stuff we still don't get).

At the end of each sprint we devote a day (which Joh ably facilitates) to reviewing the previous two weeks and planning out the next two; in the morning, we first review what was produced in the previous two weeks, then have a retrospective where we talk through what went well, what went badly, and what we still don't understand. The first review lets Devi, our product owner (a role which seems to map well with account manager) and the team themselves get a good view of what's been done, while the retrospective lets us all identify what's working and what needs to change. Typically we end the retrospective with 4 things which we aim to concentrate on in the following sprint; these have included items like "reducing interruptions", "try pair programming", "manage contacts with clients via correct routes", and so on.

Having spent the morning reviewing the previous two weeks, we spend the afternoon of the planning day looking at the next two weeks: taking stories which together make up a product, prioritising them, estimating them if necessary, and getting them up onto the task tracking board. In the early sprints we found the estimation of tasks to be an horrendous burden, and 3-4 hour sessions of estimating tasks were (understandably) unpopular. Nowadays this seems to take much less time, mainly because we're breaking down projects into stories and estimating them during our pre-sales process (i.e. in a fairly piecemeal way) rather than doing it all at the planning meeting. We've also found that planning poker speeds up the estimation process significantly, focusing debate where it's needed most - i.e. where there's most dispute over the scale of a task. Nevertheless these planning days are still quite gruelling for everyone involved.

At the end of each sprint, we tot up how many hours of planned work actually got done, and I calculate the ratio of total available hours to hours of planned work. This tells us how much time each hour of estimated work actually takes us, and I'm quite surprised at how consistent this number is; over the course of 4 sprints we have a *very* consistent picture of how long an hour of planned work takes us, and this picture is useful - both in showing that there's room for us to improve, and letting us make commitments to clients based on evidence, not prayer.

In the early sprints, we had a lot of work which "just had to happen" - like many companies of our size, I suspect - and we consciously planned in more than our initial figures showed us we could realistically handle. Overcommitting in this regard didn't actually get more work done, even when the team visibly felt the additional pressure. This sprint, we've taken care to not repeat this pattern and have planned in what we know to be an achievable quantity of work, based on what we achieved over the previous few sprints. To try and increase our efficiency, we've reduced the number of simultaneous projects we're running - as a service company it's unusual for us to focus the whole team on a single client, but reducing the number of projects for the team from 4-6 down to 2-3 per sprint might make a difference. We'll be able to see if it's made a difference in just under 10 days time, when we look at figures for work completed, of course. As the owner of the business, I like being able to measure this sort of thing empirically - though it does mean that we have to spend a bit more time on release planning, to ensure that if we have 5 active projects over a 3-month period, we're devoting an appropriate amount of time to a few of them in each sprint in order to meet milestones.

Release planning is something we started doing at the beginning of this year; some clients give us a predictable monthly workload, but for most we're working on a project basis. We know how much work we can get through in a single sprint and we know how large upcoming projects and regular commitments are. We use this information to plan out the next 3 months and see early on where we might need extra resource, where we have windows to fit in new work, and how busy we're likely to be.

Two things I have noticed, which we've yet to work out: how to fit design into this process more snugly than we currently do, and how to ensure that the daily stand-up meetings are relevant when you have a team that may spend the entire sprint doing different projects.

For the former, we're looking at incremental design instead of iterative (i.e. build the skeleton for the whole app, then fill in visual elements later) - but even so, there's an up-front task to get the skeleton together.

For the latter, I'm unsure: we certainly have some clients for whom we only carry out a single activity (e.g. handset customisation), which our developers have little to do with. We've started using a burndown chart which plots design and technical work separately (as well as a unified total), though we've not noticed significantly different patterns in the chart so far - so this may not be something which is helpful in the long term.

I've certainly not covered everything we've done in this post, but I'll follow it up in a couple of months time...

Comments

[Rod McLaren]

So Tom, just to confirm... the sprint contains activity across 1 or more projects? I guess that makes sense where a team necessarily has to switch between projects... though I'd always imagined a project being a larger entity: containing a sequence of sprints that were dedicated to the project only.

(And on the topic of these two views of time/project/team/sprint, are you getting a measurable sense of the project/task switching cost? I'd say we tend to assume that switching is expensive, though we don't measure it empirically as yet, so we generally try avoid it as much as is sensible/practical.)

[Tom Hume]

Rod - yep, that's right. We're running several projects at once. So right now we have 2 which are design-led, one which is fairly predictable maintenance/bug-fixing work and one which is new development. In the past we've run more projects that this simultaneously, but we're trying to minimise the number of simultaneous projects *within any sprint*. Most projects go beyond a single sprint.

My hope is that by measuring our velocity across a few sprints running many simultaneous projects (which we've done) and mesuring it across a few sprints running as few simultaneous projects as possible (which we're doing) we can get some data which will let us measure the switching cost. Our own experience, academic literature, and advice from others concurs when it comes to there being a cost to this - it'll be interesting to see what this cost is.

[Adam Cohen-Rose]

It's amazing how the same issues keep on coming up -- your description of how you work is almost exactly how we ran things at Kizoom when we were a little smaller. More projects and more people made the fortnightly planning sessions even more unpopular and we too gradually moved more and more planning out to other situations.

One thing we've ended up doing is splitting up our team into "streams" and doing some top-level planning to figure out which projects go into which streams for the coming iteration. This worked for us as we tend to have several projects from the same or similar clients, so each stream works on projects for one or two similar clients. The stand ups are then more focussed and the account managers can be more effective.

We've certainly found that reducing the number of projects worked on simultaneously makes us more productive, though reducing them too far often means that we ended up bringing in other projects anyway when the planned ones stalled. The cost of switching for us was not just in efficiency, but also in knowledge sharing (more pair switching with less project switching) and in morale (when a project is really getting going, the whole team feels better).

It looks like there are plenty of things we could learn from you too -- our iteration retrospectives (ours are weekly rather than fortnightly) could really benefit from some more visibility of the project progress. It's something we mean to do, but never get round to.

Looking forward to hearing more of your adventures!

Adam

[Tom Hume]

Adam: what is a stream to you - similar project work, or similar activities? What's the difference between streams and, say, having multiple scrum teams?

Knowledge sharing, efficiency, morale - all familiar topics for us from retrospectives :)

[Adam Cohen-Rose]

Tom: (sorry about the delayed reply -- can I get a notification when you reply to me?)

A stream for us is similar project work (or at least as similar as we can make it). We try to keep activities spread between streams -- account managers (scrum product owners) sit with the appropriate stream and sysadmin and database activities move from stream to stream as necessary.

I'm not sure how a stream would compare to multiple scrum teams. We share an overall monthly iteration planning between the streams, but within that month each stream plans their own weekly iterations (coordinating with the other as necessary).