This is the third installment in a series on Agile Superpowers. Read Agile Superpower #1: Focus on Collaborative Teamwork and Agile Superpower #2: Reduce WIP to the Most Important Work for more.
Does your agile team still use the same old three questions in your standup? If so, you’re not alone. Those questions focus on each individual, not to help the team finish the team’s work. And because the questions focus on the individual, teams can create too much work in progress (WIP).
Instead of focusing on each person as an individual, you can use questions that focus on the progress of the work. That changes the conversation and encourages more collaboration. Even better, it helps the team realize what causes its delays and decreased throughput.
Here’s how one team changed its conversation.
Standups as Serial Status Meetings
Peter, the product owner, stood at the board feeling as if he had a pear growing in his stomach. He hated this team’s standups. Too many items were “in progress,” rarely moving to the “done” column.
Elise, the agile project manager, joined him at the board. She said, “I don’t think much has moved since yesterday.”
Peter replied, “I’m sure nothing has moved. It’s Wednesday, and nothing’s moved since last Wednesday. Our daily standups have turned into serial status meetings. I have no idea what to do.”
She said, “Our questions always focus on the people. That’s because we ask each person what they worked on, what impediments they have, and what they will work on next. We’re not focusing on the work.”
“Focusing on the work? What do you mean?” Peter asked.
Elise said, “I just read this idea yesterday. Instead of the usual three questions, let’s take a card from the ‘in-progress’ column and ask this question, ‘What do we, as a team, need to do to finish this item?’ Think that will work?”
Peter looked at her and said, “That’s genius!”
“Maybe,” she grinned. “Let’s see what happens.”
Changing the Question Uncovered Problems
When the team arrived, Elise explained it was going to focus on the work and what it could finish. While she and Peter cared about the in-progress work, they cared more about finishing items.
Elise picked up one of seven cards in the in-progress column. She read the card out loud and asked, “What do we need to do to finish this item?”
Tom, a tester, said, “I reported two problems last week. I can’t even run the tests because the subscription implementation crashes the cart.”
That’s when two developers explained they couldn’t start fixing that because they were stuck doing search-related fixes.
And the search-related fixes were stuck behind measurements for Marketing. Those measurements were waiting for Tom.
“So, everything’s stuck behind everything else,” Elise said. “Peter, what’s the most valuable work for this team?”
“The cart. We promised subscriptions to our customers ages ago. We need to finish that.”
Elise said, “Good. And now we know what’s preventing us from finishing. Everyone, how do you want to organize so you can finish the cart?”
Four of the seven people agreed to swarm on the cart.
One of the three remaining developers said, “I have nothing to do. What do I do? I don’t want anyone to think I’m lazy.”
Elise said, “If the swarm agrees, you could do code review or test review for the four of them. Or, you could work with the other three people on what Peter says is next.”
Peter said, “I want the two search problems before Marketing’s measurements.”
The team discussed their options and decided it would use two of the other three people to do code and test reviews as the swarm developed the code and tests.
The final team member said she would organize what Marketing needed for measurements.
“But that’s not the next most important item,” Peter said. “Please start on this search item.”
“Okay.”
The team agreed to walk the board again the next day.
Results of Walking the Board
After several weeks, this team realized it had two big problems it had not uncovered in its retrospectives:
- It needed additional columns to show where its work waited: Waiting for Code Review and Waiting for Test. Of the seven team members, five were developers and two were testers. The testers could not keep up.
- The delays prompted the team to measure its cycle time with value stream maps. That’s when it realized it waited days for code review, testers, and test review.
- And it realized its work items were much larger than it expected.
With Elise’s support, the team changed the board. Many of the managers questioned the need for this team to change their board, but Elise persisted in removing that impediment.
Once the team had all its columns, it asked this question—again moving from the right-most column to the one just to the left: “What do we need to do to finish this item so we can move it one column to the right?”
Over the next few weeks, the team experimented with various WIP limits, starting with column-based WIP limits and total board-based limits.
It used a back-of-the-napkin approach for cycle time: On average, it finished three items every two weeks. So it stopped taking more than three items into the sprint.
Then, the team started to right-size the work.
Right-Size the Work
When teams collaborate on fewer items, they often get a feel for about how much time a given item will take. That’s one way to start to learn how to right-size. (Another way is to create one-day stories of value—not tasks, but value to someone.)
Here’s what happened at one board-walking session: Tom, the tester, picked up a card and said, “We thought this story would take just a few hours of testing. But I started it this morning, and I need help to finish it by the end of today. Who’s available to help me with it?”
One of the developers asked, “How did we mess that up?”
Tom explained several of the test cases.
The developer said, “Oh! I can help you. I can break that down into these three stories, and that will make the testing easier.”
Another developer said, “I can support both of you with code review and test case development and review.”
Neither Elise nor Peter had to intervene or make sure the team did its job.
Focus on the Work, Not the People
As you experiment with your agile approach, consider how you can focus on the work. Walking the board is a great way to start and continue. The question “What do we, as a team, need to move this item to done?” helps prompt the team and everyone else to focus on the work, not the people.
This article was originally published by ProjectManagement.com at https://www.projectmanagement.com/articles/949132/agile-superpower–3–watch-the-work–not-the-people. Reproduced with permission of ProjectManagement.com. Copyright © 2023 ProjectManagement.com. Unauthorized distribution of this content is strictly prohibited.