4 ms·

Where did this 85% figure come from? Is 85% the new 80%?

sjwod 3y ago
The summary at the top of the article clearly mentions that the precise number 85% is just a rule of thumb...
jillesvangurp 3y ago
There's a little bit of insight from lean manufacturing related to this. Manufacturer plant managers tend to shoot for production loads around 85-90%. Anything higher just means stuff starts piling up, which causes delays and is actually bad for business. Anything over 100% means work isn't getting done. Sounds familiar? That explains every software project that went over time and budget ever. You can apply the same logic to product management. If you are planning for more work to be done than can be done, you are wasting time and money. Ask for less; you'll get more better and sooner. Applying Brooke's law to this means that adding people to the team won't address this even. I regularly see companies make both mistakes and then they fail to deliver, everybody is stressed out, and the team under performs. It doesn't work. Prioritize work correctly and make sure everybody focuses on only the top priorities. It doesn't matter if you are using scrum, kanban, or waterfall. Just make sure your team is working on the smallest number of things at any time possible without any of them having to idle or wait. I'm a big fan of Don Reinertsen's work on lean 2.0 where he talks about this and more and uses some sound economical reasoning to back all this up.
- magicalhippo 3y ago
  Reminds me of the study I read about how placing a barrier in the form of a pole in front of an emergency exit drastically improved how many managed to get out during an emergency (simulated in the study). By introducing a barrier people are forced to reduce congestion, which avoids people trying to exit the door at the same time clogging it up.
- carlmr 3y ago
  >Prioritize work correctly and make sure everybody focuses on only the top priorities. It doesn't matter if you are using scrum, kanban, or waterfall. IME it does matter. Kanban is really about focusing on priority and throughput with no frills. Kanban is effective, can be explained in ten minutes, and just works. Most of Kanban really ties in well with Demings ideas, which I think is why it works. Scrum leads to a lot of meetings, ceremony and more "managers" - scrum masters as well as POs, and any other middle management your company had before picking scrum. And when Scrum inevitably fails, the cultists yell that it was implemented wrong, that we never did real Scrum, that if Scrum was done correctly we would succeed. Kind of like "communism was never tried". But it was tried, many times, by many teams, and sometimes despite the system some project somewhere might have thrived. It's a system that only works in an idealized world, with idealized people, that I surmise at this point never existed.
  - jillesvangurp 3y ago
    I'm not disagreeing too much here but people get to hung up, dogmatic, and emotional on processes to have meaningful discussions about this at this point. You can do both Scrum and Kanban and apply the same principals. The underlying principles are actually more important than the process. Kanban is not an excuse to skip planning and having a TODO list full of high priority items is a classic mistake with it. When everything is important, nothing really is. With Scrum the classic mistake is over committing your team based on a notion that managers wants to overload the team because they think that produces results. I treat both processes exactly the same when I put my product manager hat on (I'm also CTO, and a developer): regular planning activity to cherry pick the backlog and populate the TODO column. Pruning unimportant work from the TODO list. Making sure work is prioritized correctly. Scrum light, Kanban, Vaguely Agile, whatever labels you want to put on it works for me. I can scale up or down the scrum ceremonial stuff as needed/demanded.

The summary at the top of the article clearly mentions that the precise number 85% is just a rule of thumb...

There's a little bit of insight from lean manufacturing related to this. Manufacturer plant managers tend to shoot for production loads around 85-90%. Anything higher just means stuff starts piling up, which causes delays and is actually bad for business. Anything over 100% means work isn't getting done. Sounds familiar? That explains every software project that went over time and budget ever. You can apply the same logic to product management. If you are planning for more work to be done than can be done, you are wasting time and money. Ask for less; you'll get more better and sooner. Applying Brooke's law to this means that adding people to the team won't address this even. I regularly see companies make both mistakes and then they fail to deliver, everybody is stressed out, and the team under performs. It doesn't work. Prioritize work correctly and make sure everybody focuses on only the top priorities. It doesn't matter if you are using scrum, kanban, or waterfall. Just make sure your team is working on the smallest number of things at any time possible without any of them having to idle or wait. I'm a big fan of Don Reinertsen's work on lean 2.0 where he talks about this and more and uses some sound economical reasoning to back all this up.

magicalhippo 3y ago
Reminds me of the study I read about how placing a barrier in the form of a pole in front of an emergency exit drastically improved how many managed to get out during an emergency (simulated in the study). By introducing a barrier people are forced to reduce congestion, which avoids people trying to exit the door at the same time clogging it up.
carlmr 3y ago
>Prioritize work correctly and make sure everybody focuses on only the top priorities. It doesn't matter if you are using scrum, kanban, or waterfall. IME it does matter. Kanban is really about focusing on priority and throughput with no frills. Kanban is effective, can be explained in ten minutes, and just works. Most of Kanban really ties in well with Demings ideas, which I think is why it works. Scrum leads to a lot of meetings, ceremony and more "managers" - scrum masters as well as POs, and any other middle management your company had before picking scrum. And when Scrum inevitably fails, the cultists yell that it was implemented wrong, that we never did real Scrum, that if Scrum was done correctly we would succeed. Kind of like "communism was never tried". But it was tried, many times, by many teams, and sometimes despite the system some project somewhere might have thrived. It's a system that only works in an idealized world, with idealized people, that I surmise at this point never existed.
- jillesvangurp 3y ago
  I'm not disagreeing too much here but people get to hung up, dogmatic, and emotional on processes to have meaningful discussions about this at this point. You can do both Scrum and Kanban and apply the same principals. The underlying principles are actually more important than the process. Kanban is not an excuse to skip planning and having a TODO list full of high priority items is a classic mistake with it. When everything is important, nothing really is. With Scrum the classic mistake is over committing your team based on a notion that managers wants to overload the team because they think that produces results. I treat both processes exactly the same when I put my product manager hat on (I'm also CTO, and a developer): regular planning activity to cherry pick the backlog and populate the TODO column. Pruning unimportant work from the TODO list. Making sure work is prioritized correctly. Scrum light, Kanban, Vaguely Agile, whatever labels you want to put on it works for me. I can scale up or down the scrum ceremonial stuff as needed/demanded.