The Real Problem Isn't Your Standups
Are you working on the organization or in it? This fundamental question drives to the heart of a critical misunderstanding in agile transformation. Hi, my name is Lance Dacy, otherwise known as Big Agile, and my goal is to help you and your teams and your organizations perform better with next-generation agility tactics.
Here's the truth: your standups are fine, your handoffs are killing you. That's what we need to address today.
The Misinterpretation of Systems Coaching
Our topic today about coaching the system, not the team, is often misinterpreted as "well, I'll just leave my team alone and forget about it." No, no, no, no. You want your teams to perform well? Absolutely start there. Get your teams fully functional and productive. But I promise you that most of the problems are not within the team, or if they are, they're related to the handoffs within the teams or what we call the seams between the teams.
Beyond Team-Level Metrics
So many of us focus on our standups and how our review is going. All that should be pretty well set—those are easy events to tackle. But the handoffs that we have or the decision latency we have in the organization is often overlooked or masked, either because we're only focusing on the team and haven't been getting permission.
You don't need permission, by the way, to work on the larger organization. That's what I'd like to talk about today because it's not easy work, and it's like grasping at straws. How do we do this work?
Value Stream Mapping: Your First Tool
What I want to talk about today are value stream maps. There's plenty of tools online and plenty of blogs to research how to conduct these physically. We've actually written a lot of blogs in the last month or so about DORA metrics and flow metrics, including a comprehensive guide on Flow Joy: DevEx, DORA, and Value Stream Management, and actually how to write Python scripts to make these metrics observable. Catch that on our blog—many posts about that.
Starting Simple
The first thing I want to talk about is value stream mapping and just sitting down with your team and saying, "Okay, if we have one small backlog item or a fix or something that flows through our systems, what are the steps and the handoffs and the people involved that take place?"
I found a really simple graphic on the internet that shows a good way to start value stream mapping without having to get into Visio and all these other design tools. Just build out a chart and say, "Okay, what is the process that kicks off a lot of these handoffs that happen either within the team or outside the team?"
Mapping the Real Process
We can map out those processes and talk about what happens when we're a software team and we commit code to the repo. We have a pull request, a code review, we got to build it out. I love how so many people focus on code changes—the hardest part is really understanding how we're going to approach a problem and what the automation of the business process needs to be. But there is a lot of logistics that go on once you've made a code change. It's not just shipping it off to production and letting it go.
So it's totally okay to have these steps and these handoffs as long as we all find them valuable. For this team, they're going to say that we need a pull request, we need a code review, you're going to have continuous integration/continuous delivery build of some sort, and we'll do some functional testing.
The Hidden Complexity
A lot of times what'll happen is our developers will write some integration tests. Even before that, they'll write some unit tests. So there are a lot of different ways for teams to decide to do internal automation within the tools that they're writing the code against. But at some point, some human has to look at it and say, "Yes, that is working according to our standards," or run the integration test to try to figure out if the workflow is working.
So there's a lot of stuff that might go in there that's valuable, but it may be slowing us down. And oftentimes our stakeholders are like, "What's taking so long?" These are the things that we can actually show them and relate back to something that they're familiar with.
From Mapping to Metrics
At any rate, we're going to map that out. Just do it. Don't get too fancy with it. But once we map that out, I found a value stream map from Amazon—I think this was from an AWS playbook. What they did was start to turn that value stream map that they had into actionable insight and flow metrics that they can actually start seeing what percent of the swim lane these items are taking up. That's where the real secret sauce happens.
The Three-Step Process
The first step is we want to map it out, maybe more with a hand-drawn map, and then put that into some tool and decide what measurements do we want to start tracking based on that value stream map. Then if we see some bottlenecks or we see some sluggish slowdowns, what are some experiments that we can run?
We actually just blogged on this recently about value stream mapping, talking about seams, not teams. We've produced a diagram for that, so go check it out on our blog.
Decision Latency Index: Making the Invisible Visible
Here we have our value stream map that we can show everybody involved: How does work actually flow through the system? Then we can start figuring out on the handoffs—are they internal or external to the team? We can start forming a decision latency index, a very popular diagram that's been around in management science for a long time. But we can repurpose this for our agile teams and say, "Okay, what was the event and how much value did we lose from the event?"
Again, not judging—it may be a valid step. If you're producing a pacemaker for a heart, you're going to have a lot of steps that have to go through testing and controls and things like that. We celebrate that, but at the end of the day, they are impacting the ability to deliver.
Taking Pressure Off Your Team
Having everybody involved in seeing these indices really helps take pressure off your team because I feel like what happens a lot of times is if something is moving slow, everybody kind of points the finger at the developers. "The developers are going slow." More often than not, the developers are working in a system that's either poorly designed for flow and they don't know how to articulate that. That's where we come in.
This is exactly why focusing on the human element is so critical—as we explored in Flow Joy: Why People Service Profit Still Wins in Software, the people in your system are often dealing with systemic issues that no amount of individual coaching can fix.
Working On the Organization, Not In It
Work on the organization, not in it. Get the team fully functional and productive—they're going to have handoffs within their own teams. But what we're really talking about is a system that they're operating in. Doing scrum in one team is fairly hard. Doing scrum in 20 teams? Well, if you can't do it in one team, you can't do it in 20, and you start getting a lot more affected by the system when you start scaling. Keep that in mind.
Turning Insights into Action
This decision latency diagram is really what we can use to help us figure out those context switching points. You can see the latency and the amount of value that was lost during those steps. Finally, you can start producing and turning those into better metrics that you can produce on a leader's dashboard that we talked about in our blog post.
We'll talk about the amount of time it took for discovery—discovery's not a bad thing in Agile, by the way. You still have to discover. So there's going to be time our team spends doing that. Then we have development, that's writing the code, testing the code, all that kind of stuff. Then doing some functional review: Does it work as we intended? Deploying it and getting feedback—those are all great steps.
Creating Meaningful Metrics
This is a good example of metrics that you can show your teams. You can actually turn that into a better chart that looks at, "Okay, here's the amount of hours that this one item took and here's the percent of the value stream that we had in there."
What we're talking about here is well beyond the team themselves. We're talking about coaching the system, not the team. Obviously, we're going to spend time coaching the team, but if they're working in a bad system, there's no amount of coaching for that team that you can do to help them perform better.
Ready to Transform Your Organization?
The concepts we've covered today—value stream mapping, decision latency indices, and systems thinking—are just the beginning of what's possible when you shift from coaching teams to coaching systems. If you're ready to dive deeper into these next-generation agility tactics and learn how to implement them in your organization, explore the comprehensive classes that Big Agile offers. Our courses will give you the practical tools and frameworks you need to identify bottlenecks, eliminate handoff delays, and create truly high-performing systems that support your teams' success.