This post was inspired from a question that was asked on the scrumdevelopment yahoo user group. The question was regarding several things. First, how to handle a developer on multiple Scrum projects, second how to sync the sprints, and third what tools can be used to handle the multiple projects. I'm addressing the first and second aspects, and not the third about the tools.
Having developers on multiple projects is a very common thing. It is the wrong thing. If the project solutions have to integrate eventually, then it makes more sense...but in that case, the developers on multiple projects should be used in a different capacity. More leadership and guidance and less actual coding.
If developers are on multiple projects and the projects are unrelated, you'll have to stagger the sprints, i.e. they shouldn't start and end on the same day. Imagine developers having to attend 3 sprint planning sessions in one day, 3 retrospectives in one day, 3 standups in one day. I tried that once with 4 projects...yeah it sucked. Developers on the teams were doing nothing but attending meetings. Their first impression of Scrum was "meeting hell". Plus, you can only be in one place at once, so some of the projects suffered due to lack of attendance.
If the projects have to integrate, the sprints should sync up, as the goal is potentially shippable software...and you can't ship unless you integrate.
Either way, it is bad to have developers on more than one..."maybe" two projects. The cost of context switching is too high. I know it sounds impossible to have developers on only one project, but if you make it happen, you will not regret it. It's just scary because we've been trained that "multi-tasking is good". That is a big fat lie.
Friday, January 1, 2010
How Many Scrum Projects Can a Developer Be On?
Subscribe to:
Post Comments (Atom)
1 comment:
Good frank post. Thanks.
We always talk how the developers, Scrum Masters, or project managers are on several projects at the same time and how bad and hectic that is and how quality suffers..etc. and I agree with that.
For the rare times I find myself on a few assignments, I do notice a better performance on my part. That said, I would like to propose that the company's leadership really prioritize their projects and needs and then make sure they staff them right (and use Scrum where possible)
I always advocated for the idea of dedicated teams to be a mind set. Once the company makes sure its main projects are truly fully staffed and use a process like Scrum, then their ROI is quick and easy to figure out. Their major projects are done in clear view and would stand a better chance of being completed on time and with better quality. I think the benefit of not being spread thin will not only benefit the dev teams, I do believe it will benefit the higher ups.
How many times we see the leadership of a company sits down and decide which are the top 25 projects and then say everything else is less important. What happens is that the in reality these projects will be juggled and juggled and juggled till some projects get done or canceled.
Why isn't it clearly obvious that a company would make money (or improve service, or cut cost..etc) much faster if it takes on 4 fully staffed projects at the same time than wait 12 or 16 month to see how many of the 25 projects are done and then make money ..etc.
Post a Comment