What to Do When Scrum Collides with the Reality of Your Organization

In this video, we dive into the realities of Scrum in large, interconnected organizations and explore why traditional Scrum practices may not be enough to handle complex dependencies and cross-team coordination. Drawing from years of experience and conversations with industry pioneers, we discuss how proactive orchestration—beyond the typical Scrum framework—can help maintain velocity, produce meaningful outcomes, and ensure sustainable, value-driven progress.

Video Transcript

What we started to see in the methodology community is that Scrum was inherently insufficient as a methodology. So as we started to see Scrum emerge and take hold, people recognize that they didn’t have teams that stayed together. They couldn’t produce a working tested increment of software at the end of every sprint. They often didn’t have clear backlogs. And a lot of the reasons for that was the idea of external dependencies. And so if the team can’t make independent decisions about what’s in the backlog, the product owner can’t make independent decisions about what’s in the backlog. If the team doesn’t stay together, if the team has external technical dependencies between it and the rest of the organization, then what starts to happen is that you start to create orchestration mechanisms. And the earliest instantiation of an orchestration mechanism that I’m aware of was this idea of a scrum of scrums.

And I had a really fascinating conversation with Jeff Sutherland probably 15 years ago at this point. It was a minute. And the way that I had been introduced to the idea of scrum scrums is that the scrum teams are doing their scrum stuff. They have a product owner, or they’re doing sprint planning, they’re doing daily standups, they’re doing reviews and retrospectives. And then the idea was that the scrum masters would get together in kind of a meta scrum and they would work out dependencies or they would work out resource constraints or they’d work out whatever. And in that context, all that stuff would kind of play itself out. Well, what starts to happen is you start to have dependencies that can’t be resolved within the sprint. You have work that you need from other teams that they’re already largely booked. And so how we ended up addressing a lot of those dependencies over time was we created something that I had originally coined as a product owner team.

And I saw the scrum of scrums as a largely reactive model. And I felt like we needed something proactive. And so what we started to do was to get people who played an architect role. I know that’s not a popular word sometimes, but architecture exists. So whoever’s doing the architecture or whoever has a primary say or could be a representative of the architecture, get them together with a product person, somebody like an analyst, maybe somebody with a project manager view and have them collaborate and prepare backlog. Product owner could still bring it to the team. They could still do all the stuff. But the challenges we were starting to see is typically cross-cutting concerns or two pieces of the application that depended upon each other in order to be able to produce an integrated feature. And through that discovery process, the way I would kind of think about it was, are we doing a late dependency management strategy where we’re finding dependencies later in the process?

You could apply that to risk too. It’s kind of a risk mitigation strategy. Are we doing late risk reduction? Are we doing early risk reduction? Well, the things that are cross-cutting often need to be dealt with early. So who decides that? When does that happen in scrum? Scrum doesn’t really have a good mechanism for that. And my observation was that the scrum scrums, while theoretically able to accommodate that wasn’t proactive enough. It was reactive. So then we have teams that can’t establish stable velocity teams that are in weight states teams that can’t get to a definition of done. And so as we implemented this product owner team and we put together this kind of collaborative entity that could kind of play a look ahead game, a little bit like how I envision maybe while I’m not technically accurate, like a dual scrum or dual track scrum kind of model, where we had one team that was kind of scrumming on market identification and requirements and architecture and trying to get some ahead of some of the cross cutting concerns across the organization.

The Scrum teams could be left to work their backlog, deliver consistently, produce a working tested increment. And then as that matured, we started running that through more of a Kanban based system because a lot of times that team wasn’t dedicated. Sometimes there were other parts of the organization that we needed to include. So we went down that path. And that was early, early days. This was before my time at Version One. It was definitely before we started LeadingAgile. And somewhere along the way, I got to spend some time with Jeff and I told him what we were observing in market, my understanding of scrum scrums and how we were basically applying this concept that I had called product owner team. He just looked at me, he said, yeah, do that. That sounds like a great idea. Basically, I’m not sure if he was that affirmative of it, but he’s like, yeah, do that. And I had this moment where I went, oh, okay. Interesting. This is a more pragmatic, loose framework than I had experienced. Right? Or it is how I had applied it. I was fairly not respectful of the rules, not respectful of the rules.

And so that kind of opened things up for me a little bit. I’m like, okay, cool. That’s what I’m going to do, right? Jeff Sutherland says, I can do it. I’m going to do it.