In Part 1, I wrote about what the value stream map looked like for expert-focused “cross-functional” teams. While those teams are cross-functional, they are not collaborative. However, these expertise-focused “teams” are not the only type of non-collaborative agile teams. There are also cooperative teams.
Cooperative teams still tend to work sequentially, focused on each person's expertise. That is, each person works alone until there is a triggering event, such as a design review, code review, or a decision point. Reviews and decisions help the team decide on the next step in the product path. (Yes, that review might be a demo or a retrospective. See How Good is Your Backlog? How to Shape the Work for Product Success, Part 2, to see possible interim and exploratory steps to completing a product.)
Many of these teams create working agreements to decide in advance what to do about these triggering events or decision points. Those working agreements frame how these teams cooperate.
Let's see what a cooperative value stream map team might look like.
A Three-Person Cooperative Team Value Stream Map Example
I'm using three people again, so you can easily see how these teams work. In addition, this team has these working agreements to reinforce their cooperation:
- Everyone who asks for a review can get it within 24 hours. Yes, the team is willing to increase their overall WIP (Work in Progress) to help everyone move forward on all the work.
- Unless the person doing the work works on a “total redesign,” the team can expect a “small” amount to review. (This team has specified these terms. While they are larger than I would like, the team seems happy enough with their definitions.)
- Sometimes, that lone tester will wait for the developers to finish one feature before that tester starts any more work. (The tester is the only one managing WIP.)
Since that value stream map is a bit small unless you open it in a new tab, here's the explanation of this cooperative team's work.
The Detailed Explanation of the Cooperative Value Stream Map
Alice starts work on a story on Monday morning and asks for code review after 2 hours. No one works on that story until Ben picks it up for code review the next day. He also spends 2 hours, and offers Alice written feedback.
However, Alice is now busy with another story, so she does not return to this story for another 24 hours. She works on it for one hour and then passes the feature to Ben.
Ben's not available until much later in the day (5 hours later), and spends 3 hours finishing this work. (Did he stay late to finish? I don't know.) He asked for code review.
Alice is not available until late Thursday afternoon. As she reviews the code, she realizes she needs to fix something in her code and offer feedback to Ben. She's done late Thursday afternoon.
Late the next morning, Ben fixes the problems and hands off the work to Cody.
Cody, smart guy that he is, has deliberately not filled up his day. Instead, he did easily interruptible chores and cleanup, so he could start work on this story.
After 4 hours, he reports several problems. But it's Friday afternoon, and everything will have to wait until Monday.
Monday morning, Ben and Alice spend all morning fixing problems. 2 hours later, Cody retests for a couple of hours, and lets Peter know they are ready for him to accept the story.
Late Tuesday, Peter accepts the story. It is done.
It's time to examine the data.
Mine the Cooperative Value Stream Map for the Data
First, look at the various times:
- The total cycle time was 188.5 hours, almost 8 days.
- The work time was 21.5 hours. Since this team checks itself as they go (with reviews), I'm going to assume that they can use more of their day to do work. (I'll talk more about that later.) So, call it 4 days of work time, but spread out over all 8 days of elapsed time.
- But the wait time is still terrible: 167 hours, almost 7 days. That's close to twice their work time. Yes, they spent twice the time waiting for the next step that they did in all the steps.
Cooperative teams, assuming they do the hard work of offering useful feedback, can have shorter feedback loops than expert-focused teams. That leads to more agility, especially since Cody, the tester, seems to manage his WIP better than the entire team. Since we are only looking at one feature, the feedback loops in an incremental lifecycle might be the most relevant.
Cooperative teams can have better product outcomes. (I did not discuss that for the expert team in Part 1.) But that assumes the reviewers actually do the work for these triggering events or decisions. Especially since these reviewers do not discuss their reviews in real time with the author.
And I have not yet discussed the real issues of WIP and pressure. I will reserve a whole post for that later.
Cooperative Teams Have More Agility in the Sense of Responding to Change
The wait time between steps explains why things “take so long.” Even though this is a cooperative team, people still work primarily alone, focused on “their” work. That's a classic sign of resource efficiency thinking.
And because Cody manages his WIP, he focuses the team to stop starting so many items and start finishing items. (See that zero delay between the time Ben fixes the problems on Friday am and the time that Cody tests and reports more problems.)
A couple of points to remember:
- Your managers already think you are “agile” because you use Jira (sorry, Atlassian) and some bastardized version of Scrum.
- No one cares about any agile approach. Why? Because they already think you are “agile.”
- However, all management cares about agility, because agility allows us to respond to change faster.
The expert team value stream map hides a lot of information. The cooperative team map shows us more.
The Series:
- How to Use Value Stream Maps to Reinforce Agility & Effectiveness Part 1 (Expert Teams)
- How to Use Value Stream Maps to Reinforce Agility & Effectiveness Part 2 (Cooperative Teams)
- How to Use Value Stream Maps to Reinforce Agility & Effectiveness Part 3 (Collaborative Teams)
- How Value Stream Maps Prompt Us to Ask More Questions, Part 4
P.S. I'll be doing a webinar on April 8 about this topic. Register here.