Scrum at Scale: Changing the Conversation
Part of the key to Scrum's success is that it allows for context-driven solutions and processes – which is why no two Scrum implementations are identical. So why does the conversation about scaling Scrum focus on finding a proscriptive, one-size fits all solution? The conversation should instead be about how to scale the underlying principles of the Scrum framework that have enabled it to be so adaptable.
The Scrum at Scale framework is our first move in that direction. It is a minimal extension of the core Scrum framework that keeps the modular structure at the core of the Scrum framework, and allows you to scale a Scrum implementation tailored to the unique needs of your company.
In the video below Scrum Inc. Chief Product Owner Alex Brown talks about the Scrum at Scale framework and the rationale behind a modular approach.
There are four major reasons why we think modularity is important:
- Modularity allows versatility. Scrum has been successful in a wide variety of product and project contexts. It’s been used for everything from traditional software development to designing a new granola bar or designing complex integrated defense systems. No single proscriptive approach could work in all of those different contexts. You need something that is modular to adapt to the specific strategic context of your company.
- Scrum is modular. At its roots, Scrum is inherently modular. For example the Retrospective ceremony within scrum doesn’t tell you exactly how you have to implement the retro, it just says that at the end of it you need to have a plan for improving the team process, puts some bounds around how long that meeting should take, and gives guidance on who should attend that meeting. It leaves the actual practices for how to do that to the team that is actually conducting the retrospective. And as a result we’ve seen a proliferation of different practices that are successful in lots of different contexts.
- Deploying incrementally is easier. If you have a modular context and you define all of the inter-connections between modules ahead of time (namely what the goal of the module is, what the input to the module is, and what the output of the module is) then it doesn’t matter what happens inside that black box as long as it meets those constraints it still satisfies the goal of the module. That means you don’t need to have an entire solution delivered in one “big bang” at the very beginning of your scaling. It frees you to iteratively use Scrum to incrementally develop the modules that are most important to you and after several iterations have a fully-fledged scaled Scrum.
- Modularity supports a pattern library. A library of what people have tried in the past, and in what context, is a great way to accelerate the speed with which you can try new scaling experiments. As an agile community, we can quickly build, distill, and capture knowledge so that we can improve the state of the art by borrowing patterns and practices that have been used by other companies in a similar context to ours, and then contribute incremental learnings back to that library. It’s a powerful concept that allows us to crowd source the development of scaling Scrum.
Join the changing conversation on scaling:
Agile, Lean and Program Management Expert, Coach and World-class Trainer
9 年Both Mike and Jeff are Agile visionaries who I have followed for many years and I respect both of their points of view. I typically try to stay out the somewhat philosophical side of our industry, but I would like to weigh in on this topic since I too am concerned where we are heading. When the Agile Manifesto was written, I was a PMO consultant trying to roll out a 'standardized' project management across industries and organizations to improve project success. It was becoming clear to me and my colleagues who were leaders in the traditional project management field that we needed a more flexible approach to a project management implementation because one-size does not fit all. Fast forward ten years and we all realized that the software development community had found the hidden gem. Not in a specific framework like Scrum, Kanban or XP, but in the idea and principle within the Agile Manifesto whereby we "let the team decide." I am more than aware that large organizations are truly struggling with this concept and want someone to tell them how to do it down the last template. This is a slippery slope and to quote Edmund Burke “Those who don't know history are doomed to repeat it.”
CEO & Founder at LeadingAgile, LLC
9 年This approach to scaling Scrum assumes you can achieve modularity between teams. SAFe assumes that you can achieve modularity between enterprise value streams. I'm becoming increasingly convinced that helping companies become modular is the real end game here. Many companies don't understand how to make this journey to modular teams or value streams.
Scrum Master at Radian
9 年Generally, I liked the concepts you outlined and are many of the same issues I have with SAFe, when implemented rigidly (I don't think it has to be, but often is). I think part of the reason enterprises reach for something prescriptive is because they are often focused on predictability (which has a strong cost control implication). I believe they theorize that if everyone does it one way they will get consistent results so they can plan out a strategic vision beyond short sprint cycles with some level of confidence. I think this approach gives up a tremendous amount in waste and loss of innovation. I would rather the starting point of a large scaled scrum project was more self organizing and self managing. Instead of defining dependencies of existing teams doing the same core work they have always done. Throw the problem set out to the teams and ask them to organize in the best way to get the work done. Especially if you evangelize the success of building a modular delivery pattern with limited cross-team dependencies. Teams will probably re-distribute themselves to share expertise and / or work out a cross training strategy.
Agile Leader | Analytics Innovation Enthusiast
9 年A scaled Scrum implementation would indeed have to be modular. However I have been pondering, how this will work in practice when value streams touch several teams in crisscross fashion. It would require some ”heartbeat” synchronizing the flows and iterations. In order for this to work well I believe the implementation of the framework (patterns) has to be easy to understand and explain. At first sight the Scrum at Scale framework seems complex. I'll check your pattern library and PDF for details... Thanks for sharing.
Founder & CEO, SoftwareFactory.ai
9 年Putting the breaks on big program scaling is a step in the right direction, but Hyper Agility is only achieved by scaling down towards "inner space" as described in Value Stream