The resource utilization trap
Why Project Management Stack Exchange recommends it
Project Management Stack Exchange answerers point people to it when explaining why maximizing team busyness or minimizing downtime hurts throughput and flow.
Recommended by 2 people across 7 different months, 2017 to 2020.
What it is
A 5-minute explainer by Henrik Kniberg of Crisp showing the resource utilization trap, where keeping everyone busy slows down delivery. It uses a simple demo to show how high utilization creates queues and longer lead times, and what to do about it.
What people said
Recommends Daniel · 2017-09 · Project Management Stack Exchange · on “Small development team with big amount of tasks for different projects - how to?”
I'm not sure that a software option will solve your problem. I would definitely look at Kanban as a way to improve the flow of work through your teams. You can leverage it alongside Scrum or on its own if you want. It's important to use all of the practices of Kanban, not just the board. Make sure you are limiting work in progress, measuring flow, and making small incremental improvements. This is what will really help you improve your ability to handle all that work. Also, be careful of overburden on the team. Many teams who are overwhelmed are actually working slower because of it. Henrik Kneiberg explains the problem well in this video: [this video] Again, this is where those strict WIP limits
Recommends Daniel · 2018-07 · Project Management Stack Exchange · on “How to choose responsible for implementing decision in self-organizing team?”
The short version is that you don't. Work that must get done is picked up by someone - or it wasn't important to get done. You mention teal organizations. If you look at the example organizations in the book Reinventing Organizations, people decide the work they want to take on. This is different than volunteering to be assigned. No assignment ever happens, the work is just taken. This may sound like a fantasy, but those organizations succeed in doing it and are more successful for it. One important trait of those organizations though is that the team members have true ownership. They own the successes or failures. If their product doesn't succeed, then they're done. That's very different th
Recommends Bart van Ingen Schenau · 2019-07 · Project Management Stack Exchange · on “Should single user story contain estimations for each involved guild in full-stack development team”
Imagine you want to maximize the team effectivity by minimizing down-times of each guild. Trying to get more work out of a team by minimizing down-time is called the resource utilization trap. Here [this video] is a nice video showing how minimizing down time does not actually increase the output of the team. The target of a sprint should not be that everybody was busy the whole time, but rather the amount of work that gets delivered with good quality. Optimizing the amount of work that can be delivered starts with knowing how much work the team as a whole can bring to completion within the timebox of a sprint. And as we are looking at the team as a whole, the most value is in a single, whole-tea
Recommends Daniel · 2019-08 · Project Management Stack Exchange · on “What is swarming?”
Bart is right in line with my experience. If you have columns 1 through 6 where 6 is done, items in column 5 are worked on first, then column 4 and so on. This optimizes your system for turn-around time and throughput. This is a good video on the topic (though it doesn't specifically talk about the kanban board): [this video]
Recommends Daniel · 2019-12 · Project Management Stack Exchange · on “100% Utilization of Resource and Wait Times”
There are a lot of theories that go into The Phoenix Project. Queuing theory [LINK] is the underpinning of most everything else. It is very old (origins in 1909) and is used to great success in almost every industry from factories to computer science to retail. I don't know if there is any type of systems theory out there anymore that doesn't include some aspect of queuing theory. Speaking of which, Systems Thinking is another topic worth looking into. Again, it has a lot of history and tons of industry clout. As Andrii mentions in their answer, Goldratt's Theory of Constraints is also worth looking into and is well-vetted. Lean was also built on this and those the foundations and Lean Manag
Recommends Daniel · 2020-04 · Project Management Stack Exchange · on “Will my team be more productive if they are split?”
There are a few pieces to this answer: 1) Define Productive: Unless you are in a factory getting parts out the door, productive is a fairly vague term. Be careful that people aren't looking at busy-ness as a stand-in for effective or productive teams. Henrik Kneiberg's "Utilization Trap" video [this video] illustrates this beautifully. 2) Cross-functional teams: Are you able to make two independent cross-functional teams. A good way to measure this is to first write down all of the skills needed to deliver a feature (or whatever your team is delivering). Then have each person rank themselves in each of those skills on a scale something like this: 0-no skill; 1- beginner; 2-check my work; 3-profes
Recommends Daniel · 2020-07 · Project Management Stack Exchange · on “What can the team do to prevent stories from completing until the last day of the sprint?”
You need to look at that is happening inside of your sprint. A few things that might provide insight include: How quickly are items moving into your sprint? If everything is moving into progress on day 1 and 2, this may indicate that your team is trying to divide and conquer. In this approach, everything starts on day 1 and ends on the last day by design (more or less). This can happen for a few reasons. The two most common are either that is is conscious or that work is split up by skills during or before sprint planning. The first - that it is conscious - is an education problem. Our intuition fails us here because it feels right that divide and conquer is more efficient, but in anything b
Cites Erik · 2018-09 · Project Management Stack Exchange · on “How to utilize resources effectively in cross-functional scrum teams?”
They will do other work that needs doing. Keep in mind that "being in the sprint" means that the story is important . Not being in the sprint means the story is not that important. Looking for something that falls in line with a person's specialty is nice, and making sure that over the long term your team's capabilities align with the kind of work requires is a good practice. However, in the short term, if in this sprint there happens to be no work that relates to someone's specialty, it means you need to make a choice. You've basically got two options: A) let them work on something that is important but they cannot do as fast as their specialty B) let them work on something that is not impo