When agile teams master collaboration, that first agile superpower, they often discover they deliver more features faster. That’s great.
However, once the team starts delivering features faster, people ask more of the team. Managers, the product owner—everyone wants more from the team.
Worse, those people want more now. Even with collaboration, the team can’t deliver enough to satisfy those people if other people ask the team to do more and more.
That’s when the team needs to manage its WIP (work in progress) at several levels. Collaboration can solve the too-much WIP problem for each person and the team.
But what about when other people ask the team to increase either the number of features or the number of projects the team is supposed to complete? That requires assessing the value of those requests from other people at the product and portfolio levels.
Here’s what Sandra, an agile project manager, saw on her first day with a new team.
Throughput Decreases With Too Many Requests
Sandra walked into the team planning meeting on Monday at 3 p.m. So far, she’d spent her first day on the job filling out forms, meeting a wide variety of people, and learning what her boss, Manny, wanted.
He was clear: The team needed to deliver more features because it sold the product as a subscription, and it had been months since the team had delivered anything.
Sandra said, “Nice to meet you. I’d like to see what you do for planning. I’ll make some notes so I also understand the features.” She sat down at the far end of the conference room and pulled out a tablet.
The product owner, Paul, was walking through a long list of requests in the team’s tool. He said, “We need to address these next 30 items for the next sprint.”
Sandra said, “Sorry to interrupt, Paul, but does the team generally finish 30 items in a sprint?”
“No,” he said and sighed. “They haven’t finished anything in the past three sprints.”
“Is that because everything is in progress?” Sandra asked.
The team members all turned to look at her. One of the men said, “I’m Tim, a tester. Yes, everything is in progress. Everything. We try to collaborate on just one or two items at a time, and then Paul says we have to stop working on the first item and move to the second.”
Chimed in another: “I’m Debby, a developer, and I started four things last week. Four! Paul keeps changing the priority. So even though I work as part of a triad, we don’t finish anything.”
Sandra nodded. “Okay. Paul, what one thing do you want the team to finish first?”
He shook his head. “You don’t understand. They can’t work on just one thing. We have three production support requests, two must-haves for Finance, and three must-haves from Corporate Security.”
“Does the security work belong in the product or for how people work?” Sandra asked.
“How people work.”
“Is it a regulatory problem?”
“No.”
“Okay, we’ll postpone all of them. Now, are the production support requests preventing customers from doing their work?”
Paul sputtered, “No. But, but…”
Assess the Value of Each Request
Sandra said, “Manny explained that our customers are waiting for features. So what’s the most valuable feature we can deliver?”
“I have a list of the shortest items,” Paul said.
Sandra shook her head. “Short items might be useful—if we really know how short they will be. But let’s focus on how we create value: we reduce risk, increase our knowledge (such as with a spike), or we generate useful feedback by delivering something to our customers.”
Paul said, “How are we going to decide what’s most valuable? All the people who talk to me claim their items are the most valuable.”
“Cost of delay,” Sandra said. “With cost of delay, all we might need is what it costs us to not do something now.” (See Explain Program Risks with Cost of Delay for a fuller explanation of how to calculate CoD.)
“But we already know that all our WIP is making everything take longer.” (See What’s Taking So Long? Little’s Law Holds the Answer for more explanation of why.) “We need to finish any given item to even see if it has value. If you want, we can calculate the cost of delay for each item, but I bet you know the first thing you’d like to see right now.”
Paul said, “Yes! This specific feature first. Then, this production support issue next. If we can get those two things this week, all the pressure to start more work will decrease. I hope.”
“I’ll help you with that pressure,” Sandra said. She turned to the team and asked, “What do you need to work on that first feature and then the production support issue? Tell me that and we’re done here.”
“But we haven’t planned the rest of the sprint,” Paul said.
“We don’t need to,” Sandra said. “Not until the team finishes those two items in that order: the feature and the production support issue. You and I can collaborate and calculate the CoD on all the other in-progress work.”
Debby stood and said, “Ready to swarm on that first feature?”
Everyone nodded and the team left the room.
“Now, let’s discuss how to manage all those demands in the future, so we don’t have a ton of WIP and old items hanging around,” Sandra said.
High WIP Slows Throughput
Too many agile teams find themselves in this position. They start delivering, and then—wham—many people ask the team to deliver more features.
Always make the decision of what to do next based on the value of the work. And you don’t have to “fill up” a sprint. Instead, choose the one or two most valuable items and finish those. Then, if you have more time, choose the next one or two most valuable items.
Choose the most valuable work with cost of delay. That will reduce the demands on the team—and help it deliver more, and faster.
This article was originally published by ProjectManagement.com at https://www.projectmanagement.com/articles/945866/agile-superpower–2–reduce-wip-to-the-most-important-work. Reproduced with permission of ProjectManagement.com. Copyright © 2023 ProjectManagement.com. Unauthorized distribution of this content is strictly prohibited.