My Photo

About Me

  • Hello you. I'm a 38-year old MSc student, studying Advanced Computer Science at Sussex University. I'm especially interested in Internet and mobile software, sensors and pervasive computing, user interfaces, and the process of developing great software.

    Before that I spent 11 years running Future Platforms, a software company I co-founded which makes lovely things for mobile phones, and which I sold in 2011.

    I read a lot, write here, and practice Aikido and airsoft. I live in Brighton, a seaside town on the south coast of the UK, with two cats and a clown.


Stalk Me

  • Email me:
    twhume at gmail dot com
Blog powered by Typepad

« Twitter and partial unreliability | Main | »

January 20, 2008


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!


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).

The comments to this entry are closed.