The Myth of 100% Utilization with Pawel Brodzinski

Clayton Lengel‑Zigich: Welcome to another episode of the Agile Weekly Podcast. I’m Clayton Lengel‑Zigich…

Derek Neighbors: I am Derek Neighbors…

Pavel Brodzinski: And I am Pavel Brodzinski.

Myth of 100% Utilization

Clayton: Welcome, Pavel. We’ve found an article that you wrote, it’s entitled “The Myth of 100 Percent Utilization”. I was curious if you could explain a little bit about the motivations for writing this one and kind of what you mean in terms of what is the myth of 100 percent utilization. If you could just introduce the topic a little bit, that would be great.

Pavel: The motivation to write the piece was that what I see over and over again in different organizations is that the organizations or managers are trying to optimize the way people work, the way companies work in a way that everyone has something to do all the time. We basically are trying to utilize people for the whole time. We aim for 100 percent utilization.

If you learn a bit more about the subject, you start thinking it is not the best way of organizing work. By implementing Kanban, we implement WIP limits, work in progress limits. If WIP limits are set correct, it usually means that people will have some idol time, which is called slack time. It actually is a mechanism that the team makes the organization improved.

My main motivation was sharing the idea and spreading the word. What I tried to do was to explain why thinking of utilization in the first place is the wrong idea to have.

Appropriate Amount of Slack Time

Clayton: Is there a good level of slack time or amount of slack time, that you think on average a team should spend with no assigned task, so to speak? Is that going to vary from team to team and situation to situation?

Pavel: When I think about utilization in terms of different contexts, for example, traffic on a highway. There is, I don’t remember the numbers, but something around, I believe, 70 percent, which is the optimum, the point where most cars are going through the highway.

However, I would say that in terms of teams, it’s not that simple. You can say that teams should have around 20 or 30 percent of slack time. What I believe in is experimenting. You should try to tweak WIP limits, tweak the way you organize work in your team, and measure what the optimal way of working is, in your case.

In terms of knowledge work, we deal with high variability of tasks we work on. It’s not that one car passes through the highway in pretty much the same time as another, as our tasks differ. It can be said that there is some kind of ideal number. I believe every team needs to find their own sweet spot. It will be floating, by the way, it’s not something that is set for a longer time.

Clayton: In terms of the time that…let’s say that a team has some slack time. What do they do with that time? Is that time that they burn down technical debt, fix defects, or experiment with new things…If I’m a manager and I’m willing to accept that the team should have some slack time to do other things, this will not be a hundred percent utilized. What are they doing with that time? Are they doing nothing, what exactly would that look like?

Pavel: It would depend on policies you have in your team. Because you can have some guidelines, what kind of tasks people should choose first, during slack time, but…most teams I know have freedom, in terms of they use their slack time.

In an ideal world, by the way this is something I teach in Kanban, the first task to be taken, would be either swarming on tasks that are already now a bottleneck. Let’s consider the situation that we have, say, too many developers and too few testers or quality engineers. We have this bottleneck in testing. Basically, after some time one of our developers would have this slack time. In an ideal world, he would either take one task and test it or maybe swarm with one of the quality engineers, to deal with the other task faster.

However, we don’t live in an ideal world. Most of the time, when a developer faces the opportunity to test [sarcastically] , he will do anything to avoid using this opportunity.

[crosstalk, laughter]

Clayton: Yes. Right.

Optimizing For The Whole

Pavel: In the long run, that’s even better, because usually they would spend time working on things that optimize the whole process, for example, automating some testing. Because this is fun, this is still development, and yet it helps quality engineers to shorten the time they spend on their regular tasks.

This is the story of one of my teams that are actually working on this kind of tasks, automating tests, improving code quality, simplifying configuration. We were able to remove this bottleneck in testing because we improved the way we build the code, the way we build up. Developers had fun, working during their slack time, and still we improved the whole process, the whole end to end process. I would say that it’s pretty safe to leave much freedom to team members to choose what they’re doing during slack time.

A Contradiction In Terms

Derek: I follow that you’ve been bantering back and forth on this a few months back where, maybe it’s optional task stuff, maybe it’s important task, maybe it’s my inability, from the English language perspective, but I’m feeling a very strong disconnect to the logic. What I’m hearing is that people should not be a hundred percent utilized, yet they should have slack time. In the slack time they should be doing things that propel the company, the sprint, or the team forward. To me, that’s a total disconnect.

If we say, “You should be doing something for the company a hundred percent of the time that you’re at work,” and then we go, “Oh, no. We don’t really believe that, what we really believe is that you should only plan 80 percent of your work, but the other 20 percent that’s not planned, you should still be doing something that moves the team forward.” I’m having a disconnect there, in the sense of…I guess I’m more of a believer that in creative work you need to allow your brain time to process things.

If you’re doing, I don’t want to say slack time because I just think it’s a horrible terminology, a horrible expression, because it has so many meanings within the English language that are bad, [?] got baggage with it. May be the Pomodoro method’s an easier way to articulate it. You’re doing some volume of work, whether it be 60, 80, 90 percent, some planned form of work, and then the remainder is really more of a state of play, where you allow your mind to process…whether it be play video game, table tennis, or take a walk around the campus, whatever.

I was thinking that the concept of not being a hundred percent utilized is that we’re not being fully utilized, that there’re some cycles outside…so maybe, if you could help clarify some of that…it would help me.

Pavel: The first perspective is that we look at a hundred percent utilization from the perspective of building new theories of doing our regular work. When we introduce WIP limits, we try to avoid starting too many things at once before finishing some of them. This is the first thing.

However, you aren’t actually forced to do this improvement work during slack time. You can perfectly do nothing. You can take a walk. You can take a break and do nothing in terms of building any value, and it would still result in better effectiveness of the team as a whole.

However, what I find typical is that people actually do find time to think, do find time to have a break and play foosball or whatever. They don’t have problems like this. They still are starting too much, too many concurrent tasks. They still build those huge, huge queues in the process which make all the work of the whole team ineffective.

I don’t really see introducing WIP limits, introducing slack time as a way of building this spare time to think because from what I witness in many organizations is that people, whenever they need, they actually take this time to think, to take a break, to refresh themselves but still do have problems with effectiveness in this other area. This is my view on this subject.

Derek: I don’t think there’s any easy answer because I think that we can all agree that you end up with queuing problems if you have a hundred percent working on feature mentality and don’t have any slack to deal with the world around you.

I think we can probably all agree that creative people need some time to process things. It’s just a matter of what we call it and how it’s planned for and how it’s probably communicated to managers or people paying the bills in a way that that they can understand that they don’t feel like people not working on whatever, to them, feels like the most pressing thing, right?

Pavel: Yeah, exactly.

Commitment Driven Planning

Clayton: Let’s say for instance a scrum team, and they’re using a commitment‑driven approach or capacity planning where they say, “We have a hundred hours of available capacity for this sprint.” They pull in stories. They pull them in, and they task them out and everything, and they try and build up until they get to the hundred hours.

Let’s say they’ve been doing that for a while where they try to pull in as many tasks as they can, I think, that they can commit based on their capacity. Would you recommend that they lower their capacity a little bit so that they do have some of that slack time? Do you think that would be beneficial to that team?

Pavel: I would definitely try this kind of experiment because what you end up when you try to pull as much as possible, you end up doing features, doing tasks ‑‑ those regular tasks ‑‑ all the time. Basically, what you don’t have time for is this kind of improvement work.

When you’re thinking about a classic scrum team…In sprints, we limit our work in progress in pretty different way than we do in Kanban. We don’t try to limit the number of tasks which are on this stage or the other stage, but we just have time boxing which is just the other idea of how we can limit work in progress because we can only have that many features that’s queued into our sprints and not anything more.

I would definitely advise trying to introduce some time for improvement. Maybe to commit to one feature less or one story less and see what happens. If nothing changes, in scrum it’s not a problem to pull one more story out at a later time during sprint. We usually have this bunch of stories that might be in sprint, but we don’t commit to them, right?

Clayton: Right. I think we’re actually about out of time here, but if listeners want to find you maybe a blog or on Twitter or if there’s anything you’ve been interested lately and a community that you’d like to share with the audience, if you can just let them know where they could check you out and see some more of your articles.

Pavel: A basic, basic place where people can find me is the blog which is blog.brodzinski.com, B‑R‑O‑D‑Z‑I‑N‑S‑K‑I. My Twitter handle is @PavelBrodzinski, which is my first name and surname.

Clayton: We’ll put those in the show notes for you.

Pavel: Yeah, but basically if you Google my surname, all of the results somehow connects with me as that name isn’t that popular, I guess.

Clayton: [laughs] That’s a good one to have.

Pavel: Yeah, that’s true.

Derek: Well, thanks a lot for joining us today. We really appreciate it, and we look forward having you on again.

Pavel: Thanks for having me.