How Scrum Masters Can Unleash Lean Flow by Being Control Freaks

Do this to become a master of value flow.

“We have our dependencies under control. Look, all our upstream and downstream needs are clearly mapped in Jira. And all involved teams have committed to doing their part on time. We’ve got this.”

But…wait…why…how…huh?

I had just met the Scrum Master spinning this web. And he was describing with pride how his team had wrangled dependencies. But I know how intricate plans look impressive, yet provide only perceived control.

I left the encounter in shock. But why? It’s not the first time I’ve seen this.

This type of orchestration thinking and blind faith in tools pre-dates Scrum. I’m sure you’ve heard of:

• Gantt charts
• PERT diagrams
• Critical Path Mapping
• Task Dependency Network Diagrams

The Tetris game of dependency management has been a pipe dream for decades.

This brings us to the present day. Frameworks like SAFe try to master this dark art with PI planning. Here you use yarn or something like it to connect all team dependencies on a large program board. To an outsider, this looks impressive, as if real transparency is taking place. Lines crisscross, zig, and zag, shining a light on who’s responsible for what.

To me, it looks like delays in waiting.

The inevitable future chaos blindsides you because you thought you were in control, but you weren’t.

All of this dependency coordination theater creates a false sense of comfort.

While the illusion of control persists, the reality is far different.

We assume we can control the situation by having a plan and commitments up and down the line.

Let me let you in on a secret: you can’t control what’s not within your team.

Any perceived control is an illusion.

As soon as you leave the planning activity, your masterpiece of a plan starts to crumble, to decay.

• You forgot a key dependency. Whoops.
• The teams you depend on take longer. What’s their deal?
• You don’t do your part on time because of a hidden issue. Grrr.
• Downstream teams aren’t ready when you finish. What amateurs.

And getting everyone back together rarely happens. Your beautiful plan falls apart faster than you created it. It’s like sand slipping between your fingers.

This has nothing to do with anyone’s planning prowess or lack thereof.

The crooked path is the natural course of software product development. And when you have dependencies, you are even less in control.

The fault lies with the hand-off-laden system in which you work.

Given the pain they inflict, we need a fix to systematically break down our dependencies, so they go away.

A Quick Guide for Scrum Masters to Become Control Freaks Who Don’t Tolerate Dependencies

I recently wrote an article on how Scrum Masters need to get back to form. It covered behavior modeling, obstacle removal, proactiveness, and transparency. And I got a ton of questions about removing obstacles and how to get ahead of them.

One thing is clear from the curious minds that reached out. Today’s Scrum Masters care about improving their craft. But they need some guidance. Lean flow is not part of any Scrum Master certification and rarely surfaces in the day-to-day.

We leave Scrum Masters to their own initiative to try to keep their heads above water. They aren’t equipped with a “waste radar” nor the countermeasures to battle what sucks the life out of teams.

Scrum Masters today need better knowledge of what kills flow.

And dependencies are a flow killer.

So, I’m going to outline what I’ve learned about solving this growing problem. Most organizations face rampant and increasing acceptance of dependencies between teams. I aim to give Scrum Masters a boost to inoculate this epidemic. To give them the same “eyes for waste” I have.

And I will teach Scrum Masters how to be control freaks.

No, not micromanaging maniacs. I aim to show them how to be flow-enabling dependency breakers. To bring as much control into the team as possible.

Otherwise, I fear, if we do nothing, Scrum Teams will continue to work too hard for rare results. They will keep chasing coordination nirvana with reckless abandon and tripping over missed commitments and hidden snares.

Let’s dive in and explore two key steps you can take as a Scrum Master to create better value flow for your team.

Step 1 – Make the case for change by showing the waste generated by hand-offs.

Dependency removal makes for an easy sell because hand-offs spawn every other lean waste.

1. Waiting up and down the dependency chain when things don’t go as planned.
2. Work-in-progress increases because you start something else while you wait on dependencies.
3. Context switching goes up because dependent teams work alone, never on the same thing at the same time. Then, they interrupt each other to get help or to fix hand-off-related problems.
4. Over-processing ramps up to coordinate and replan when things don’t go as expected.
5. Over-production of scope not needed due to misunderstandings that happen after hand-offs.
6. Defects proliferate because of hand-off missteps and late integration and testing.
7. Knowledge scatter spreads because no one team understands the end-to-end feature.
8. Under-realizing people’s potential becomes the norm. All the minds needed to do the work are not in the same place at the same time, focused on the same thing.
9. Relearning abounds because those downstream relearn what those prior have already learned.
10. Wishful thinking takes over because we hold out hope the delays will get resolved. We cross our fingers that we will pull a rabbit out of a hat to deliver on time.

You will often recognize the waste of hand-offs because of all the waiting and blaming. It’s never your fault the work gets delayed. It’s “their” fault.

If your team can’t own its work end-to-end, you have the waste of hand-offs. Here are examples I often encounter:

• Approval boards and gates.
• Pull requests for code reviews.
• Support performed by another team.
• Team leads assigning work to workers.
• Experience designs crafted by a UX team.
• Testing performed by a separate quality team.
• Decisions made by managers or those in authority.
• A separate layer team (e.g., front-end, database, or services).
• Writing stories in a backlog and handing them off to the team.
• Discovery with users and stakeholders done without the team.
• Specifications crafted by architects or designers not on the team.

When a team has to depend on others, on outsiders, it’s an incomplete team. In reality, it’s crippled. And it has to hobble its way through the resulting waste.

To make a case for getting rid of a dependency, all you have to do is add up all the ways the waste is crippling your team.

But its influence on delivering sooner is most compelling.

Every dependency you break doubles your chances of delivering on time. Why? Because…math and probability say so. Conversely, every dependency you add takes you down an exponential path of delays. Go deeper into the math by checking out the great work of Troy Magennis.¹

Less waste and better odds of delivering sooner. Sounds to me like a great case for change.

Now, let’s understand how to make it happen.

Step 2 – Master the lost craft of breaking dependencies.

Recognizing and acknowledging the waste is just the first step. The real benefit lies in systematically breaking these dependencies.

So, you may be wondering, “How do I break the hand-off chain?”

It’s more simple than you might expect. The key is to avoid trying to solve all dependencies at once.

And don’t try to remove every dependency. Some don’t carry enough pain nor happen regularly enough to warrant removal.

I like to map dependencies to make sense of which ones need urgent attention. Your first step is to list out every dependency you know that plagues your team. Then, organize them based on frequency and pain level.

Having mapped them, it’s time to focus on systematically removing them. Find the hand-off carrying the most pain, the most often. Then, work to change the organization to bring control back to your team.

Once fixed, pick the next most painful dependency and repeat.

It’s this steady, incremental practice of chain breaking that will unleash your flow more and more over time. And regular retrospectives can help you do this.

Use your Retrospective to rally the team around dependency-breaking.

Dependencies are heinous enough to be the theme for your Retro.

This way, the whole team can focus on removing a painful dependency together in the next Sprint. This works great because, most likely, you will need your team’s help in breaking the dependency.

With your team’s involvement secured, here are ways I’ve seen teams break dependencies.

• Form porous boundaries between teams.
• Give more authority to the team to decide.
• Automate compliance and security checks.
• Make quality assurance a full team activity.
• Create a workaround that allows you to ship.
• Use collective ownership over local ownership.
• Teach the team how to do the dependent activity.
• Put the right folks in the same space and time to collaborate.
• Use mobbing and pairing to squash the need for code reviews.

Any of these can be a solid step in the right direction.

Take a team of mine that did not do support for what it built. We decided in a Retro to take over for the support team for six months. What an eye-opener this was. After we witnessed our poor quality in the wild, we had a renewed interest in running a tighter ship. We kept the retrospective focused on this for several sprints. Before long, we had plugged the gaping holes and formed new, rigorous quality habits.

We found when we supported our work, we became more vested in quality. Excellence builds as control builds.

Like us, use the Retrospective to give momentum to your quest for end-to-end control.

As a Scrum Master, it’s your job to recruit outside help if needed.

You and your team may not have the authority to make these changes happen on your own.

In some cases, you will need to seek help from managers or others in authority to grease the wheels of change.

Be prepared. You might have to make a business case for the change. This is hard work in my experience because many managers have accepted dependencies as normal. I find this difficult to believe given their cost and pain, but it’s true.

Mindsets don’t shift overnight.

The good news: given all the waste generated by dependencies, it’s easy to show their menacing cost.

And if you can get backing to kill one dependency, real benefits will result. That proof will make it easier to do it again and again until your team is controlling its work. For example, the success of my team supporting what it built gathered trust to increase its control over other parts of its work.

Little by little, you can tame this beast with a full team effort and management backing.

---

Breaking dependencies is one of the best things you can do as a Scrum Master to unleash your team’s flow.

Each dependency you break will make Scrum suck a little less and will help deliver value sooner.

It’s a given that your team and organization care about the flow of value. So, you must be a control freak Scrum Master when it comes to your team owning its work.

By fostering a self-reliant team, you can achieve a smoother flow of value.

Depend on no one. And control your flow. This gives you autonomy over your value achievement.

More flow control means sooner value.

That’s a win in anyone’s book. Good luck breaking the chain.

---

➡️ Sign up for weekly tips like this on doing more with less while respecting people.

---

References

1. Impact of Multiple Team Dependencies in Software Development, Troy Magennis, observablehq.com, July 29, 2019