3 ms·

It seems to me that actually, productive and predictable teams finish what they start. Going through the whole explanation, the base assumption is that tasks a

It seems to me that actually, productive and predictable teams finish what they start. Going through the whole explanation, the base assumption is that tasks are clearly defined, there is few surprises, task pipelines seldom break in the middle because of external factors. Which is the hallmark of a predictable dev environment and by proxy, a productive team. All the team has to do to increase it output is stop doing the tasks in parallel. Conveniently, there is no real explanation of the status quo, teams must have been really lazy and couldn't think by themselves why they were doing so. This really feels like one more motivational preacher trying to sell that one weird trick to solve all your problem.

jillesvangurp 4y ago
Don Reinertsen has some interesting arguments for all this based on keeping inventory of work in progress low, maintaining short work queues (amount of time things sit in an issue tracker), minimizing the number of things being worked on at the same time, and minimizing time to delivery (cost of delay). Basically his reasoning is that overloading teams with more work than can be handled actually leads to delays and inefficiency. You get teams and developers waiting for each other and being blocked on each other. So, they start switching tasks and increase the amount of work in progress, which leads to even more blockage. It looks like everybody is super busy but it's actually very inefficient. Before you know it, you have lots of half finished things blocked on something and an issue tracker full of work that was specified months ago and probably is not even valid anymore. People get stressed and deadlines start slipping. All this increases cycle times of individual work items. Reducing the amount of work in progress means things move faster through the system overall and less things get blocked. And when they get blocked, it gets resolved faster. Also people feel better about things because they get things done. And, they get feedback faster, which is also a good thing. The counter intuitive thing with this is that reducing the amount of work increases overall throughput and increases predictability. I rewatch this once in a while because it is just such a great presentation: https://www.youtube.com/watch?v=L6v6W7jkwok&t=3601s https://www.youtube.com/watch?v=L6v6W7jkwok&t=3601s I try to manage my teams and products accordingly by creating clarity on what it exactly is that we are building from week to week and what the priorities are. I like having small teams or groups of people rather than having big teams. Because that allows me to have more than one thing being worked on. When it comes to product management, I don't like specifying too much ahead of time. There's no point in having months worth of inventory of feature work that won't get worked on until months later. By the time work starts, half of it is probably invalid anyway because requirements and priorities always change.
- makeitdouble 4y ago
  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

Don Reinertsen has some interesting arguments for all this based on keeping inventory of work in progress low, maintaining short work queues (amount of time things sit in an issue tracker), minimizing the number of things being worked on at the same time, and minimizing time to delivery (cost of delay). Basically his reasoning is that overloading teams with more work than can be handled actually leads to delays and inefficiency. You get teams and developers waiting for each other and being blocked on each other. So, they start switching tasks and increase the amount of work in progress, which leads to even more blockage. It looks like everybody is super busy but it's actually very inefficient. Before you know it, you have lots of half finished things blocked on something and an issue tracker full of work that was specified months ago and probably is not even valid anymore. People get stressed and deadlines start slipping. All this increases cycle times of individual work items. Reducing the amount of work in progress means things move faster through the system overall and less things get blocked. And when they get blocked, it gets resolved faster. Also people feel better about things because they get things done. And, they get feedback faster, which is also a good thing. The counter intuitive thing with this is that reducing the amount of work increases overall throughput and increases predictability. I rewatch this once in a while because it is just such a great presentation: https://www.youtube.com/watch?v=L6v6W7jkwok&t=3601s https://www.youtube.com/watch?v=L6v6W7jkwok&t=3601s I try to manage my teams and products accordingly by creating clarity on what it exactly is that we are building from week to week and what the priorities are. I like having small teams or groups of people rather than having big teams. Because that allows me to have more than one thing being worked on. When it comes to product management, I don't like specifying too much ahead of time. There's no point in having months worth of inventory of feature work that won't get worked on until months later. By the time work starts, half of it is probably invalid anyway because requirements and priorities always change.

makeitdouble 4y ago
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.