3 ms·

I went through the video. For the HP example, their core issue was a quasi infinite backlog because they would add to the pile regardless of their velocity. T

I went through the video. For the HP example, their core issue was a quasi infinite backlog because they would add to the pile regardless of their velocity. This looks to me to be a problem that is orthogonal to doing tasks in parallel or not: in the single task a time model, the extreme case would be an employee stuck on a single task without any lever to unlock it. Both scenarii are a failure of task management, and I'm not sure one is obviously better or less likely than the other. However you organize your tasks, you still have to manage your flow in one way or another. My argument is, the amount of work in progress depends on the quality of your tickets, and not much about wether you allow "pipelines" or not. > they start switching tasks and increase the amount of work in progress, which leads to even more blockage Isn't your issue that none of the things in your backlog are effectively doable without blockage, and deciding to stick to a single task forever, or switching to many other ones might not actually have any effect on the output ? I saw an egregious example of that in a contracting team, where one of the dev's job for a week was to go division B and request they unlock him. The rest of the time he was working on his personal project and reported "preparing the requirements for the next tasks of the sprint". On switching tasks, I think it gets a bad rap because the worst cases are very simple to visualize: it's a pile. The reverse being nothing, and "nothing" isn't as exciting. The line doesn't go up.

jillesvangurp 4y ago
It's a very common thing that I've seen in many projects. Bad inventory management basically. PMs just build a huge backlog of stuff. By the time people get around to that stuff it's months out of date and probably half wrong anyway. That's why waterfall is not a thing. Developers are not great at multi tasking. And switching tasks has a cost of making a context switch. If you spread things out over time, you basically get a lot of cost related to that and you stretch the time to initial feedback on whatever it is you are doing. The smarter way to manage projects is to deliver stories, design, etc. just in time to have them ready for immediate implementation and thus shorten the cycle time from coming up with a thing to do all the way to having the thing in production. That minimizes context switches and ensures everybody still has everything that was agreed in their heads. I've been on projects where PMs had 10 sprints completely planned out and they'd be shitting their pants by sprint 2 because it wasn't working out as they wanted it. That's not agile, that's waterfall and it cannot possibly work. But it's what a lot of people revert to. Reinertsen's points are that there are good reasons that you can reason about from an economical point of view to do things differently that neatly align with a lot of intuitions developers have anyway. Queue theory applies to all sorts of queues, including issue trackers and backlogs.

jillesvangurp 4y ago

It's a very common thing that I've seen in many projects. Bad inventory management basically. PMs just build a huge backlog of stuff. By the time people get around to that stuff it's months out of date and probably half wrong anyway. That's why waterfall is not a thing. Developers are not great at multi tasking. And switching tasks has a cost of making a context switch. If you spread things out over time, you basically get a lot of cost related to that and you stretch the time to initial feedback on whatever it is you are doing. The smarter way to manage projects is to deliver stories, design, etc. just in time to have them ready for immediate implementation and thus shorten the cycle time from coming up with a thing to do all the way to having the thing in production. That minimizes context switches and ensures everybody still has everything that was agreed in their heads. I've been on projects where PMs had 10 sprints completely planned out and they'd be shitting their pants by sprint 2 because it wasn't working out as they wanted it. That's not agile, that's waterfall and it cannot possibly work. But it's what a lot of people revert to. Reinertsen's points are that there are good reasons that you can reason about from an economical point of view to do things differently that neatly align with a lot of intuitions developers have anyway. Queue theory applies to all sorts of queues, including issue trackers and backlogs.