3 ms·

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 do

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

DanielBMarkham 15y ago
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)

DanielBMarkham 15y ago

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)