Agile Scrum: Delivering Broken Software Since 1991

Scrum is for those firms who do not want to hire a real product manager and empower one after they are hired.

Scrum is a great idea and I use elements of it to manage how I organise my work. If I've blocked out a month to work on one piece of software then I will sit down with the relevant team and we'll agree together a "prioritised product backlog" consisting of a combination of new functionality and bugfixes.

However, what Scrum doesn't seem to address is how to deal with the bureacracy in a large organisation, especially where you don't have all the resources you need to meet demand from different teams who want you to do work for them.

It's been a fairly exceptional month, but I've been forced to switch projects 3 times recently owing to differences in opinion (at board level) about which piece of work is more important. This has obviously been less than ideal from an engineering perspective and has left me with just a couple of weeks to develop a fairly important web application.

I'm currently thinking about how I could extend the Scrum model to account for multiple projects but I'd appreciate any insights people here on HN have to offer...

Work 100% on one thing at a time and decrease your cycle time (length of sprint) to allow for rapid shifts.

If you have to go to a 3-day cycle time -- as long as you are 100% dedicated -- do that.

This, of course, assumes you've understood the agile/scrum concepts enough that you can scale them down to a few minutes each. If you're still having 30-minute standups and 4-hour sprint planning sessions, my advice is not going to work.

Here's the thing: no matter how stressed out and context-switching the work environment is, you can only work on one thing. So can you predict what you are going to deliver and then deliver it? If you can't -- if you can't even predict day-to-day what you are going to do -- then you're well and truly hosed. Scrum or agile isn't going to fix that. (BTW, there's another answer if you are truly in an environment without any structure at all. In that case, I'd look seriously at some lightweight kanban)

I agree that this problem exists, but I also feel that there is a better solution than whats listed. Stories should be given points for their complexity and not for the time it takes. Additionally stories should only be business oriented, so things like automated testing don't get their own stories.

Since automated testing does take time your team velocity is what's affected, and no one has control over team velocity once a sprint has started. Quality issues that recur affect the calculated velocity and one off quality things (like setting up continuous integration) should add a buffer to the velocity. This should be discussed in sprint planning so transparency is maintained.

Well said.