4 ms·
The first thing that comes to mind is to allow different stations to do each others' jobs when needed. Sure, productivity will be lower when doing something you
by ikeboy 11y ago
The first thing that comes to mind is to allow different stations to do each others' jobs when needed. Sure, productivity will be lower when doing something you aren't used to, but isn't it strictly better than being idle because there's no work on your level? (Barring problems because you didn't do the work well, but this is a simplistic model anyway.)
I wonder how the game would end up if stations could work on other levels for a slight penalty to production for both stations, only kicking in when one is idle over some threshold.
- erikb 11y agoI think that's what SCRUM tries to achieve. A lot of tasks in TODO? People start working on these. A lot of tasks in QA? People work on that. Tasks get done but not deployed? People will start to cooperate on deployment. Each one is less productive but the whole team overcomes more of these big scale threshholds.
- marcosdumay 11y agoWell, adding that to the model would make it not apply to software development. You can't just add developers to a task.
- ikeboy 11y agoWhy not? Or rather, what hit do you expect productivity to take, and for what level of idleness would that still make sense? If the problem is that some developers are literally idle because their task is done, they should do something else.
- marcosdumay 11y agoYou can't just break development tasks into subtasks at will, they always have a natural structure. Also, you can't go reassigning developers all the time, they should always do their tasks from start to completion or their productivity suffers badly. Neither can you assign several developers to the same task and get a productivity improvement.
- sanderjd 11y ago> what hit do you expect productivity to take As always: communication overhead. This developer coming in to a new thing after finishing their last thing has to spin up on all sorts of stuff, maybe they don't even know much about what we're working on, but even if they do, they don't know what the current status is. All that spin-up has cost both for the developer and the new team. It is often more efficient to spend that idle time working on lower-priority tasks in their current area.
- frandroid 11y agoThe different stations don't represent developers, they represent discrete tasks. So that could be designer > coder > qa, or dev stack 1 > dev stack 2 > dev stack 3. A coder waiting for a design won't just go and design. A developer with Stack 3 might be familiar with Stack 2 but might not know the best practices from that stack, introducing bugs or funky code that will create more work later on. If all your developers can do all the tasks, the graphics in this story don't apply.