How to Use Value Stream Maps to Reinforce Agility & Effectiveness, Part 3 (Collaborative Teams)

In Part 1, I wrote about what the value stream map looked like for expert-focused “cross-functional” teams. In Part 2, I discussed cooperative teams that have working agreements on when to do code review or make other decisions as a team. While those teams exhibit somewhat more agility, cooperative teams are still not collaborative.

So in this post, let me discuss a collaborative, cross-functional team.

What I Mean by Team Collaboration

When I talk about collaborative teams, I mean a team that works together on all aspects of product development. They design, implement, and test the product together. There are several ways to collaborate, and I will discuss those below. But here's the key idea:

No one person “owns” any part of the product development. The team owns all the product development.

This team-based collaborative approach offers several benefits.

The team can limit their WIP, their Work in Progress.
No one ever needs a standup, because the team knows what they have done, what they need to do, and where their impediments are. While the team might need to explain their concerns, issues, or impediments to a facilitative leader or a manager, the team never needs a standup. (I hate standups, so this works for me.)
No one on the team multitasks on the team's work or backlog. (They might have deliverables outside the team. The people on the team might multitask on those. While that's bad, the collaboration is a forcing function to expose that multitasking.)

Both expert-focused “teams” and cooperative teams have trouble managing their WIP. That's because no one wants to be idle during their wait times. So these people pick up something new to do. When each person returns to the first piece of work, they delay that second piece.

This image, from Manage It!, shows the effects of the delays between the tasks. Worse, the longer the wait time for the first piece of work, the less predictable the cycle time for the second piece of work.

That's why team-based collaboration is so essential for any agility. (Any team's specific agile approach is irrelevant if the team does not collaborate.)

It's time for an example.

A Three-Person Collaborative Team Value Stream Map Example

Here's a value stream map for our three-person collaborative team:
On Monday morning, Alice, Ben, and Cody start working on the next story in the ready column. They discuss the design, often prototyping as they do. In their two hours on Monday morning, they write code, write tests, and collaborate in several ways to make progress. Then, they have lunch and meetings. But they still have a little time at the end of the day, so they spend that time collaborating on this same story, for a total of 4 hours of work time. Then, it's time to leave for the day. That's the 16 hours of wait time until they pick the story up again on Tuesday morning.

On Tuesday morning, they collaborate for another two hours, finishing everything: all the code and tests. Peter, their product leader, has a few meetings, so he's not immediately available. But, two hours later, he accepts the story.

They can call this story done. And it's time to look at their data.

Mine the Collaborative Value Stream Map for the Data

First, look at the various times:

The total cycle time was 26.5 hours, just over a day. I'm going to call it two days.
The work time was 6.5 hours. Yes, they had a ton of wait time, mostly due to their other meetings. However, if we step back, we can see a day of work inside of two days of cycle time. That's much better than the other teams.
While they still had a wait time of 21 hours, the overall time was compressed to two days.

In this case, the team collaborated with all of pairing, swarming, and mobbing. When they discussed the overall design, they mobbed around the whiteboard. When it was time to code and test, they swarmed, each doing their own thing until they checked in with each other at the 20-minute mark. (See Pairing, Swarming, or Mobbing for the various definitions.) But they never started another story or otherwise interrupted themselves.

(While I used in-person terms, such as whiteboard here, the same principles apply to distributed teams. See Hours of Overlap, the First Principle of Successful Distributed Teams for the details.)

That's why collaboration changes outcomes.

How Collaboration Can Change Multiple Outcomes

Because this team collaborated, they did not multitask on other stories. That allowed them to keep their WIP low. (See Flow Metrics and Why They Matter to Teams and Managers.) They were also able to achieve some team-based flow because they collaborated. (If you have not yet read Flow: The Psychology of Optimal Experience by Mihaly Csikszentmihalyi (my Amazon affiliate link), read it. Anyone and any team can achieve flow.)

All of this allowed this team to finish as fast as possible, maintaining a sustainable pace.

In addition, the team learns as they develop. The team understands the entire story. That allows the team to learn fast, keeping their feedback loops short.

The shorter the feedback loop, the faster the team learns and finishes their work. That finishing allows both the product and the portfolio teams to change the product roadmap and the project portfolio. (See Multiple Short Feedback Loops Support Innovation.) Then, the product team can choose a new product direction (if necessary). And the portfolio team can decide how much more to invest in this product.

The more collaboration the team has, the more agility the team can have.

Collaborative Teams Exhibit the Most Agility

Because the wait times are shortest for collaborative teams, these collaborative teams exhibit the most agility. I mean agility in the sense of “start and finish some work so the team can respond to change.”

Will collaborative teams always have short cycle times? Not if the team works on giant stories without splitting those stories into the various product minimums. The larger the “story,” the longer the cycle time because the team needs time to experiment and learn.

However, collaborative teams will always finish those large stories faster than an expert-focused team or a cooperative team. Those non-collaborative teams have built-in wait times that dwarf the actual work time. Collaborative teams tend to have work times that are within an order of magnitude of the wait times. That's a huge improvement.

Even better, value stream maps help us ask more questions. That's the next part.

The Series:

P.S. I'll be doing a webinar on April 8 about this topic. Register here.