Flow at All Levels to Enable Effective Self, Team, and Portfolio Management

I've been thinking about flow…​

In his first week, Tom, a new manager, realizes the four teams he leads and serves are frantically trying to finish their work. Each team feels too much pressure to have one-on-ones with him, in this, his first week.

He first checked the project portfolio. Here's what he discovered:

  • His peers have one overarching goal for the organization for the year, their corporate strategy. (Right now, that timing appears to be okay.)
  • As a portfolio team, they commit a single project to a team so they can see the team's progress monthly. Those deliveries will help the portfolio team consider experiments to support the strategy.
  • They keep their WIP (Work in Progress) to the number of teams available.

However, the teams' time to complete the work is longer than that monthly decision point. That's because each of Tom's four teams are multitasking, even though each team works on only one project. They're not able to work in flow and each team's reasons are different.

Visualize the Flow of Work

Instead of one-on-ones, Tom worked with each of the teams to see where the work got stuck. He discovered:

  • Team 1 constantly had to wait for lab time to verify their fixes. (They didn't create a value stream map, they used the technique in Unearthing Your Project’s Delays.) The lab was a constraint that did not require more people—but did require money and setup time.
  • Tom's predecessor didn't like large teams, so he broke apart Teams 2 and 3, each with their own product leader. As a result, neither Team 2 nor 3 had all the skills they needed to complete their work. In effect, each of the teams was a component team. Worse, the product leaders had different goals, so the teams did not collaborate even though they worked on the same product. When the teams and the product leaders created their value stream maps, the problems became apparent. Tom asked if the teams would join together as one large team of 16 people. When the teams said yes, Tom negotiated the problem of two product leaders with their manager.
  • At first, Team 4 didn't want to meet to discuss their problems. Team 4's product leader emailed, “We're too busy trying to get all the support issues fixed. You really want us to take time to work on the delays?” Wow.

Four different teams, four different problems. And all the problems interrupted their flow.

Flow Is Personal

How did things get this way? (One day at a time.)

Back when Team 1 first asked for their own lab, the necessary equipment had been quite expensive. Now, Tom can coach them in making a business case for what they need. (See How to Describe All the Value When You Want to Influence for all three kinds of value.) Remember, the Cost of Delay for product work often dwarfs the cost of capital equipment.

While I share Tom's predecessor's concern about large teams, Teams 2 and 3 as a large team seem to make things work. I've learned over the years—as Tom has—that when teams want to include more people, I should get out of the way and support the team's experimentation. Tom was able to resolve the issue of the “extra” product leader with that person's manager.

So Teams 1, 2, and 3 had problems that were fairly easy to solve. But not Team 4.

Tom suspected Team 4 felt nervous about exposing their problems to their new boss (Tom), and to the organization. He decided to put the team's psychological safety first, before any investigation. And that's what he told them.

But we all know that people don't listen to a manager's words as much as they listen to a manager's actions.

Tom explained to his portfolio cohort that he would need time to untangle the issues and he would respond to them about the portfolio the following month. While his peers were not happy, Tom refused to commit to anything faster. That bought everyone another month.

A Month of Team and Management Actions

Tom had learned early in his career that “not having time” to fix problems meant that the team needed to go meta about the problems. Instead of focusing on each problem, the team needed to see why they had these problems. Team 4 grudgingly agreed to a 90-minute retrospective. This is what they discovered:

  • Because they were new to the product, and the previous team hadn't created enough tests, Team 4 released a version with too many defect escapes.
  • Team 4's newness meant they didn't know all the ins and outs of the product, which meant everything took longer. The fastest way to make everything take less time was to create sufficient tests at every level—especially unit tests.
  • Their product leader felt under pressure from his manager, so the product leader pressured Team 4 to do “more” and “faster.” Team 4 interpreted that to mean that they should work as individuals, not as a team.

None of these were easy problems to solve. In effect, Tom needed to ask Team 4 to change their culture to be much more collaborative and focus on technical excellence first. And, Tom needed to talk to the product leader's manager to understand the pressure. All inside of about six weeks.

Team 4 started with collaboration.

Collaboration Increases Flow

Team 4 decided to experiment with their WIP. Since they were an eight-person team, they first decided to keep the total number of open items on the board to four, half of the number of the team. Then they realized that WIP was still too high, so they chose two total open items. That worked for a few days until one of the fixes caused a customer crash due to insufficient testing.

That's when they decided to mob/ensemble on the work. That allowed them to fix the customer crash. While they fixed the crash, they discovered more issues they then fixed as a collaborative team. Finally, they chose to return to just two open items on their board.

By the end of second month, all of Tom's teams were back in flow, delivering on a regular basis. While the teams didn't “make up” the deliveries they had “missed,” the management team was able to manage the project portfolio.

Flow Matters At All Levels

Even though the portfolio managed the organization's flow, that wasn't enough. Tom's teams also needed to manage their flow.

Sometimes, as with Team 1, the team can fix its flow challenges with a simple solution that costs money. Teams 2 & 3 had team- and individual flow problems because the product leaders were not synchronized on what the product needed, and interruptions caused everyone to multitask. They needed organizational change to fix their flow. And when teams feel that the work overwhelms them, as with Team 4, it's time to go meta and see which problems to solve when and with what forms of collaboration.

If you, as Tom, see these problems, visualize the situation, and then consider your options. The more people collaborate, the less work the team has. That leads to less work hanging around forever. And that will allow the teams to finish and release good work faster.

This newsletter touched on these books: Manage Your Project PortfolioCreate Your Successful Agile ProjectSuccessful Independent ConsultingPractical Ways to Lead and Serve Others, and Practical Ways to Manage Yourself.


Learn with Johanna

I'm almost ready to publish the first iteration of Project Lifecycles. I am clearing some errors, but hope to publish the initial version next week.

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:

Johanna

© 2023 Johanna Rothman

Pragmatic Manager: Vol 20, #8, ISSN: 2164-1196

Leave a Comment

Your email address will not be published. Required fields are marked *