Agile Scaling Techniques

#offthebeatenpath ideas for how to approach achieving agility at scale - As a thought exercise - let's say you wanted to drive towards agility with a group of around 300 people, and you COULDN'T use any of the established scaling frameworks. No SAFe, LeSS, S@S or even Nexus. Not even Flight levels. What would you do? Here's my quick answer, with multiple ideas in no particular order (to be elaborated in a blog post or a video later...)   - aim to descale before scaling by trying to organize around teams that are capable of delivering value on their own, with minimal dependencies. - use Scrum Sprints to help evolve this approach - identify who are the Developers/PO working on this complex problem and have them work towards the Product Goal of working effectively at this scale (probably clarify the Product Goal first…) - Agree on underlying principles that the people evolving the approach will use as decision filter/guidance. I would recommend Donald Reinertsen's flow principles… (beyond the obvious agile manifesto principles? ) - Use Kanban to get transparency to flow across this group - have a conversation about what flows at the level of this entire group (Features? Rocks? Bets? Objectives? Key results?) and what its overall value stream looks like and get that going. Teams might establish their own Kanban boards as they get inspired by that. (check out https://vimeo.com/54005347) - Have a conversation around what problems they see with current ways of working across this group and choose from a palette of principles and practices that could potentially address the issues (e.g. Integrated Sprint Review, Nexus Sprint Planning, maybe Big Room Planning once in a while) - Have a conversation about Scaled DoD - what’s the DoD in each team, what only makes sense once they integrate, how often does that happen (and flow/kanban should indicate that) - Start to identify constraints/bottlenecks and focus attention there - whether it's a team, a process, a policy, etc. - Invite the group to an open space to discuss scaling considerations - maybe seed with some topics/influence but also leave a lot of room for whatever comes up (Daniel Mezick's Open Space Agility comes to mind here https://lnkd.in/eDsDTGHC) - Align on strategic outcomes (e.g. using Objectives) and self-organize/self-select into teams which are each focused on a certain Objectives, that will establish the set of Key Results (KRs) they are focused on achieving.

Running a big game studio project? Steal this 90-day scaling strategy from me: This was a critical project. Stakes were high & we needed to move fast. -100+ People -Dozens of large features -New tools & tech we hadn't used before. -International footprint. -Huge player impact -Lots of internal cynicism from the past. It was a massive pile of complexity, and I was responsible for the organization's structure. We needed to move quickly. We needed to scale quickly. And it needed to work. The system had to be durable and effective. I approached it with a couple of principles: 1. If Leaders have tools & autonomy, they can flex with uncertainty as we scale. 2. Attitudes, loyalties (Project>team), and behaviors are reinforced daily so people know how to interact with each other as things change. 3. Everyone knows what's valuable so they can pull signal from noise and focus. 4. Over-communication to honor the company's sensitivity around the project and the criticality of its launch. 5. The process should be light. What exists should be standardized for simplicity. As a result, we built systems to scale... 1. Product Knowledge & Goal Focus 2. Collaboration within & across teams 3. Leadership Roles & responsibilities 4. Communication with the rest of the company. This led us to a large-scale multi-pod structure with a lot of centralization. The system we built persisted for almost 2 years after we set it up. -It scaled another 100 contributors over that time. -It encountered massive changes, shifts, and pivots and could adapt. -It delivered a product to players globally AND knowledge and support for internal adoption. -It managed expectations across the org & eased anxiety among stakeholders. These projects don't come along often, but maybe this will help you with your teams or a project you're on in the future. Check out the carousel below for more details on what we set up. There's a lot I can't go into here because there's too much to cover. Also attached is a diagram of the team setup as a bonus. Ask questions below if you want clarification on anything!

Key takeaways from Steve Pereira's #agiletoagility talk on scaling flow in a 20,000-person enterprise. 💡 Start with Value: Map out your real customer or business objectives before designing any change. A crystal-clear “why” guides every decision. 💡 Visualize the Current Flow: Visualizing bottlenecks and dependencies is the best way to rally people around fixing them. 💡 Empower Teams, Don’t Prescribe: Shift from handing teams solutions to giving them problems to solve. Trust the experts closest to the work—they’ll discover better, faster paths. 💡 Loosen Dependencies: The fewer “hand-offs” you need, the faster your overall flow. 💡 Measure & Celebrate Progress: Track lead times, throughput, and quality as you iterate. Early wins build momentum and strengthen trust in the new approach. 💡 Scale Iteratively: Instead of a “big bang” change, tackle one high-impact area at a time. Prove success, earn credibility, and then expand. 💡 Flow engineering isn’t about layering on more processes—it’s about removing friction so your teams can deliver real value quickly. https://lnkd.in/etSqMq2m