Most projects encounter problems at some point, regardless of the size of the team and the people's capabilities. For example, in a six-person team, TeamA,
- Tom resigned to follow his wife to her new job.
- Dick became quite ill and went out on short-term disability for the next three months.
- And Harry needed significant time off in the next two months to help his parents sell their home and move into assisted living.
In the space of one week, TeamA was in trouble. Their trouble was all team-based.
But don't think they were in trouble because they were a small team. Large teams can encounter plenty of problems, too, just as the fifteen-person TeamB did.
Three months ago, TeamB created its working agreements. They knew how to work together and were in the process of jelling as a team. But then the company encountered trouble. The senior managers felt under tremendous pressure to deliver “more” with “less.” That pressure rolled down to the managers who served each of the people on the team: Abel, Brad, and Charlie. (Yes, I'm anonymizing everyone in this newsletter.)
Able asked everyone who reported to him to start working on two more projects. So did Brad—but two different projects. Charlie followed suit with yet two more projects.
TeamB had fifteen people, but now, nine different projects. If the team members worked on what their managers wanted, they were unable to work on the team's project. The company's portfolio problems created team-based problems.
How could the teams see their product quality and progress? That was the big question.
Instead of asking about deadlines and personal progress, each team answered these questions—as a team:
- How old is each open item?
- When do we, as a team, think we can finish each item?
- How do we feel about product quality to keep our defect escapes and Fault Feedback ratio measures low?
Let's start with item age.
Tip 1: Assess Each Item's Age
Both teams felt tremendous pressure to start more work. But everything we know, from Little's Law to portfolio management, tells us this:
It doesn't matter when or how much we start. It matters when we finish.
When we ask, “How old is each open item?,” we can ask the zeroth question: Is this item still valuable? Should we do this work at all?
To see how fast we can finish anything, we need to know what is open, and for how long. I would then use Cost of Delay to assess which item to finish first, but that's me. You might choose the shortest work first (if you can tell). (See How Cycle Time and Cost of Delay Makes Product Development Decisions Easier (Day 2) for details.)
When TeamA asked this question, they realized they needed to collaborate as a triad to finish each open item, to manage what they could deliver and when.
But TeamB didn't just need to collaborate. They needed their managers to collaborate to reduce the number of projects. TeamB needed one and only one overarching goal.
Tip 2: Assess Completion Time
Once each team assessed all the aging, they could ask the next question from Manage It!:
“When do we think we'll be done?”
Because the team asks itself this question, the team can surface and discuss risks.
When TeamA answered this question, they realized just how much more work they were “supposed” to do before releasing. That allowed them to have a frank conversation with their management. Together with management, they chose to release more often, but with fewer features in each release. As a result, they realized the customers were happy with fewer features, which relieved a little of the pressure everyone felt.
TeamB had no answer to this question because they needed to know which project was most important. That's when they invited their managers for a frank discussion about what to do first, second, and third. And because everyone was there, the team members could answer their managers' questions in real time. No one had to worry about Management Decision Time.
Product quality is just as important as time to release. That's because product quality will set the stage—or not—for customer satisfaction and, therefore, revenue.
Tip 3: Assess Product Quality
If the team measures its defect escape rates and Fault Feedback Ratio, you might have objective measures for product quality. (See Create Your Successful Agile Project for more details.) But I also like to ask this question on a five-point scale:
“How satisfied are we with our product quality?”
The scale goes from “Horrible” on the left, with “Okay” in the middle, and “Great” on the right. When I facilitate, I post the scale on the board (virtual or real) and ask people to post stickies. That creates a histogram. We then discuss the histogram as a team and decide what to do next.
When TeamA assessed their product quality, all their scores fell in “Good” and “Great,” on the right side of the scale. They decided to continue monitoring their defect escapes and test automation, to make sure they maintained their quality.
But TeamB's histogram was scattered on the left, with several stickies in the “Horrible” column. They had taken shortcuts and created cruft, not conscious decisions that created technical debt. TeamB showed their results to management and explained that they would redo some of the already “completed” work. Although the team had marked the work “complete,” it wasn't.
Dates and Quality Both Matter
Customers need products within a reasonable time with a certain level of quality. (See Predicting the Unpredictable for much more on this.) And since you need both, make sure the team:
- Works on one product at a time, with one overarching goal.
- Collaborates, managing their WIP (Work in Progress), watching their cycle time and item aging.
- Assess their product quality, both with qualitative and quantitative measures.
Use these tips to assess product quality and progress every day. They're unusual and revealing questions.
Aside from the books I already linked to, this newsletter touches on all three of the Modern Management Made Easy books.
Learn with Johanna
Successful Independent Consulting is out everywhere.
I just published a self-study workshop for Write a Conference Proposal the Conference Wants and Accepts. Enroll and take it any time you want. If you want my feedback, you can add that at the end of the workshop.
New to the Pragmatic Manager?
Are you new to the Pragmatic Manager newsletter? See previous issues.
This year, I started recording these newsletters on my YouTube channel. I post the videos a few days after I send these emails.
Here are links you might find helpful:
- My Books. (BTW, if you enjoyed one of my books and still need to leave a review, please do. Thanks.)
- All my Workshops (public, private, and self-study).
- My various consulting offerings
- Managing Product Development Blog.
- Create an Adaptable Life
- Johanna's Fiction
Johanna
© 2023 Johanna Rothman
Pragmatic Manager: Vol 20, #7, ISSN: 2164-1196