← Scrum Master Toolbox Podcast: Agile storytelling from the trenches
Scrum Master Toolbox Podcast: Agile storytelling from the trenches
Managing Dependencies and Downstream Bottlenecks in Scrum | Renee Troughton
00:16:48
Renee Troughton: Managing Dependencies and Downstream Bottlenecks in Scrum Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website:...
Loading summary
Transcript24 lines
- [00:04]
A
Hey there, agile adventurer, just a quick question. What if, for the price of a fancy coffee or half a pizza, you could unlock over 700 hours of the best agile content on the planet? That's audio, video, E courses, books, presentations, all that you can think of. But you can also join live calls with world class practitioners and hang out in a flame war free and AI slop clean slack with the sharpest minds in the game. Oh, and yes, you get direct access to me, Vasko, your Scrum Master Toolbox podcast. No, this is not a drill. It's this Scrum Master Toolbox membership. And it's your unfair advantage in the agile world. So if you want to know more, go check out scrummastertoolbox.org membership. That's scrummastertoolbox.org Membership. And check out all the goodies we have for you. Do it now. But if you're not doing it now, let's listen to the podcast.
- [01:12]
B
Hello everybody. Welcome to our Wednesday the Coaching episode, this week with Renee Trotten. Hey Renee, welcome back.
- [01:20]
C
Hey Vasco. And happy Wednesday to everybody. Midweek hump.
- [01:24]
B
Yeah, exactly. Happy Wednesday. So on Wednesday we talk about challenges and coaching. As Scrum Masters, our work happens in the middle of incredible complexity. Stakeholders, organizations that are constantly changing, like we talked about yesterday. And that means that we're always facing new and evolving challenges. And the way we approach these challenges, the perspective we bring, the mental tools we bring, of course, can dictate the potential for success and the potential for failure. So here on the podcast we like to think that there's never only one answer. And it serves as well to think about how to go about a problem in multiple different ways and then evaluate that. And we do that through coaching conversations. So, Rene, share with us what is a challenge that you're facing right now and let's have a conversation about that.
- [02:20]
C
Oh, there's probably a bit of a dual edge challenge. So I work in an organization that has a few dozen teams. Those teams work across a few different business lines. We do do quarterly planning, but the quarterly planning process is pretty high level. And as a consequence of that, we do have some very small downstream teams that tend to not be considered as part of the planning process and are too far downstream for people to actually know that they've got an impact. And so they end up having a huge amount of unexpected work inside of the quarter that leads to them having lots of peaks and troughs. We have a lot of services groups as well that we have some challenges with planning for them and so I'd say dependency management, identification of that, especially downstream areas, is pretty challenging. If I had to say where the root of some of this could be is we're also not that great at discovery. We just start work and we just get going without necessarily thinking of who are all the players that we actually do need to involve and how much do we need to involve them, and sort of thinking about them a little bit early before we go into our sprints to deliver it.
- [03:51]
B
So what I hear you describe is something that I think we all face. And full disclosure, I'm a project manager by trade. I often call myself a recovering project manager, and I do that. I use that term because even though I'm trying to apply Agile approaches, I very often end up falling back to the tool set that I learned when I was learning project management. And that has advantages. So there's a lot of great stuff within the project management body of knowledge, but there are also some incredibly important assumptions in project management that are not necessarily compatible with agile software development and agile businesses. So what I hear you say is kind of this contrast and perhaps this swinging effect between doing just enough planning so that we can get started, or doing too much planning because we want to know who is involved and how and when and so on, but then not really having time to get started. And I very often see teams and even organizations that are adopting Agile that swinging between these two extremes. I'm reminded of an organization where I worked at, where they are currently as of late 2025, going through their third agile adoption, where every time they adopt Agile, then they go back to project management, like literally hire project manager, start the PMO and so on, then go back to Agile and then go back to project management and now they're the third time back to Agile. So do you feel that there's kind of this perhaps a sense of loss for not having that more structured, detailed planning process that perhaps existed in that organization before?
- [05:37]
C
I think it's interesting and I think the swing is a really good analogy on it. For the actual, let's say product teams, it's not a problem for them. I feel like they are comfortable with the ambiguity of not having a lot of detailed information upfront. They're happy with being able to incrementally deliver Sprint by Sprint. It's more the downstream teams that aren't the product teams that are still dependencies like middleware or AI, for example, or even data. They're not embedded inside of those product teams and they're not set off slightly to the Side as a support team, they're really further downstream. They just don't see that work until hey, we urgently need this. So either it's not enough upfront planning or it's not enough visibility as part of quarterly planning. Or what I did also sense check was maybe it's not enough prioritisation as an organization. So yeah, you might have a pipeline of let's say 50 initiatives that you're working on as an organization this quarter. Have you actually set up stack rank them? Because as a downstream team, what you could just do is to say, well you just work in order of the priority of the organization.
- [06:59]
B
Okay, so that's a great, that's a great point. Because I mean if we, if we look at it like downstream, like you talked about downstream teams, imagine several rivers flowing into one main river, right? Like at some point all the water will end up in that main river. But I guess the ironic and sadly ironic part of this is that in many organizations that downstream team is probably by design under resourced and understaffed because of that picks and throws pattern that you describe, right? Because they are not always busy. So eventually their managers say hey, let's just move some people out to another team that needs more people and let's keep this team as a smaller team. And then you end up with this upstream or product teams as you call them, working and then this, some might call them service or shared service teams kind of getting a lot of work potentially all at the same time. Because if you do quarterly planning, the product teams are happy working on their own things in the beginning of the quarter. Come the middle quarter, middle of the quarter they'll say hey, we need data to do this, hey we need database to do this. Hey we need operations to do this. And then all of the work kind of floods those service teams. Is that how you describe it?
- [08:19]
C
100%. Yes, exactly.
- [08:22]
B
So what have you tried in that organization so far to try to cope with this?
- [08:28]
C
So what we are working on right now is that top to bottom stack ranked prioritization of initiatives. Then at a more detailed level for those shared service groups, just having a regular weekly or fortnightly, almost like prioritisation forum to say, okay, we've got all these different priorities, like where do we actually need to focus on? So that's an alternative that we're looking at as well. So rather than having the top down prioritisation, can we get a mini forum going obviously to your point, around peaks and troughs, trying to hold some capacity aside for those squads to say you'll have some unplanned change come in. You don't know how much, but use some historics from the last few quarters to say this is how much you've traditionally had. Hold that capacity aside for the unknowns that come through. And then lastly, trying to get tech leads to be the ones to say, oh, I actually identify there is a downstream dependency, and then connecting the dots with those groups to say, I actually do have work. We're in discovery. Just want you to let you know this is coming next quarter.
- [09:38]
B
I just wanted to do a very quick inventory of the possible approaches here. The top to bottom stack ranking that you talked about have some excess capacity because we know some work will come at the end of the quarter. A couple of other things that came up to my mind was in one company where I worked, we established this shared code ownership approach where the shared service teams were kind of advising on code changes and accepting code changes rather than making the COD changes, because that also brought the responsibility upstream to the product teams. But it kept architectural coherence from the service teams who in the end needed to maintain that code base. And then the other aspect which you already mentioned in this excess capacity solution is to think about the whole system of development from the perspective of theory of constraints. So knowing in advance that there is a bottleneck, we do a certain number of steps, steps by which we kind of, we control the flow of work into the bottleneck point in the system so that the bottleneck is never overworked. Because another aspect of this overworking the teams later in the quarter is that those teams get effectively slower than if we would be actively managing their capacity. So a simple approach to this might be to have some groups plan the quarterly work load on the first month of the quarter, while some other groups would plan on the second month of the quarter, while other groups would plan on the third month of the quarter, therefore creating more of a constant wave of work towards those teams, rather than this big lump of work coming at the end of a quarter, a calendar quarter. So those are just some ideas. But this highlights something that is very important for us to understand is that work really flows. And without the understanding of that aspect of flow, we might fall into the temptation of trying to plan everything in advance. And a couple of things that are important to mention here is that we can never plan everything in advance. Things will be discovered, right? So anything that. And being a no estimates advocate, one of the things that I say is that anything that depends on us foretelling the future will fail the question is just how fast and how big it will fail. So I don't know. These are just some of the ideas, some of the ideas that you mentioned, some of the ideas that come up in my mind through the conversation. What are your thoughts on that, Rene?
- [12:21]
C
Those are great ads. I think the other ad I would make is sometimes there's also non technical teams that can be the constraints. So legal is a really good example for us. And what we have found is by having just regular discussions with them around, these are the items that we've got for you as a leadership team. When you're looking at that as priorities, we can actually say no, I actually don't think that we have to do that this quarter. We can delay that till next quarter and making those the leaders, the ones accountable to say let's stop pushing that work down to that downstream team. And then the other alternative which is can we choose a different level of fidelity or risk associated with the work? So let's not put as much effort into that work. Let's do a bare bones answer to that, but we'll take the risk on as a business as a consequence of that. Other options as well.
- [13:15]
B
Yeah, balancing risk over workload. I think that's a great idea. That and the goal of this type of conversations, just like we had now and we hopefully have also at work, is not to be tied into one single possible solution because then our ego becomes entangled with the solution and then we stop listening to the system data, the system hints that are coming at us, but rather to consider many possible solutions because some systems are just complex enough and we have to sense our way into a solution rather than try to predict what solution will work in the future. And I think that this is why the experimentation mindset works so well. Right. Like we could just say, hey, for the next quarter let's try this. If this works, great. If it doesn't work, let's try something else for the quarter after that and then we're always progressing.
- [14:11]
C
Yeah, beautiful. I mean, I think the experiment approach is definitely one that I use an awful lot as well. Absolutely.
- [14:18]
B
Well, thank you for bringing that topic and for starting this conversation. Rene, thank you.
- [14:25]
C
You're welcome. And hope everyone else has a great rest of your day.
- [14:30]
A
Alright, I hope you liked this episode, but before you hit next episode, here's the deal. This podcast is powered by people like you, the members who wanted more than just inspiration. They wanted real tools and real connection to people who are practicing agile. Every day we're talking access to over 700 hours of Agile Gold, CTO level strategy talks, Summit keynotes, live workshops, E courses, Deep Dive interviews, books, and if you're into no estimates, we got the pioneers of no Estimates in those Deep Dive interviews as well. Agile Business Intelligence, creating product visions, coaching.
- [15:16]
B
Your product owner courses.
- [15:18]
A
You name it. You'll get invite to monthly live Q&As with agile pioneers and practitioners, plus a private Slack community which is free of all of that AI slop you see everywhere. And of course without the flame wars. It's a community of practitioners that want to learn and thrive together. It's the best place to connect with community and learn together. So if this podcast has helped you before, imagine what you will get from this podcast membership. So head on over to scrummastertoolbox.org membership and join the community that's shaping the future of Agile. We have so much for you, so check out all the details@scrummastertoolbox.org membership because listening is great. It's important. But doing it together, that's next level.
- [16:19]
B
I'll see you in the community Slack.
- [16:23]
A
We really hope you liked our show.
- [16:25]
B
And if you did, why not rate this podcast on Stitcher or itunes? Share this podcast and let other Scrum masters know about this valuable resource for their work.
- [16:35]
A
Remember that sharing is carry.