The single most important and valuable piece of advice that I have for teams that are struggling with organization-wide agile adoption is this: Break your team silos. In the early years of Agile's popularity, only core tech team worked on Agile principles. Then one day we realized that our design teams were also planning website updates in a sprint-like fashion. There were weekly rollouts and reviews instead of how they used to plan everything months in advance earlier. We were surprised by this but soon realized that a QA suggested the structured way of working. Seeing its benefits, the design team agreed. There was no need for governance or authority for driving this adoption. That's when we figured that when team members interact, information and ideas also flow. So, don't let your teams operate in silos. Strategically swap team members between projects and you won't just transfer skills but processes, ways of thinking, and information. It may feel disruptive at first because people need to adjust to new teammates, but it's far more effective than enforcing governance from the top.
Hi, I'm Alex Ramasheuski, Architecture and Solutions Director at ScienceSoft. My advice would be: don't rush into scaling. Make sure your teams are truly ready for it and that strong leadership is in place to support them. Having the right tools for cross-team transparency is also critical. From there - experiment, try different approaches, learn quickly, and don't hesitate to drop ceremonies that don't add value. Scaling agile is about adapting practices to the real dependencies and needs of your teams and product. There's no fixed template. For our projects at ScienceSoft, we tested a variety of practices - Product Owner rotations, shared Product Owners, joint Scrum of Scrums, combined Demo and Retrospective sessions, and more. None was perfect, but each proved effective in different contexts and scenarios. What often worked was combined Demo and Retrospective sessions. Bringing everyone together created a shared sense of progress and gave stakeholders one clear view of the product. Just as importantly, it sparked cross-team learning, ideas from one team often inspired improvements in another. The key is to keep those sessions focused and well-facilitated so they don't become too long or drift into status-reporting. We also experimented a lot with rotating and sharing Product Owners. Rotations broadened perspectives but hurt consistency in decision-making. And a single PO juggling multiple backlogs often struggled with prioritization, which slowed decision-making and left some teams waiting for clarification. Unless the teams are very small and tightly aligned, shared PO introduces more friction than it resolves. Best regards, Alex Ramasheuski Architecture and Solutions Director ScienceSoft
If you're stuck trying to scale agile beyond one team, my advice is this: stop treating agile as a process to roll out and start treating it as a culture to grow. Where most organizations get jammed up is they copy/paste rituals—standups, sprints, retros—without actually aligning leadership, product, and engineering around the same mindset. That's like planting seeds in concrete and wondering why nothing grows. What worked for us was starting with transparency at the leadership level. Instead of mandating "we're all agile now," we opened up cross-team demos and shared roadmaps so everyone could see how their work fit into the bigger picture. Once people saw the value—less finger-pointing, faster feedback, clearer priorities—adoption spread naturally. Agile scaled not because we forced it, but because teams saw it made their lives easier. So if you're struggling, zoom out: focus less on policing process, and more on creating the conditions where agile feels like oxygen instead of homework. That's when it sticks.
Based on our experience, investing in dedicated agile coaching is crucial when scaling agile practices across multiple teams. When we faced resistance to adopting agile beyond our initial team, we found that having skilled coaches who could tailor the approach to each team's unique dynamics made a significant difference. Additionally, we established regular cross-team retrospectives focused specifically on collaboration patterns, which helped break down silos between departments. Recognizing and celebrating small wins along the way helped demonstrate the tangible benefits of agile to skeptical stakeholders and built momentum for broader organizational adoption.
I would advise a company that is having trouble scaling agile practices to put more emphasis on mindset alignment at all organizational levels rather than tools and frameworks. In our instance, we discovered that scaling was unsuccessful when leadership saw agile as merely "a process for developers" as opposed to a cultural change that affects communication, prioritization, and decision-making. Investing in cross-functional alignment workshops prior to extending agile beyond the pilot team proved to be effective for us. We convened leadership, operations, and product stakeholders to establish common objectives and develop a common language around agility. As a result, when several teams implemented agile practices, they were working toward the same business goals and not in separate silos. Everyone, from executives to delivery teams, understood how their work fit into the larger picture, which led to quicker decision-making and fewer bottlenecks. The goal of scaling agile shifted from adding ceremonies to developing organizational agility overall.
When using agile in many teams, it's essential to have clear goals that everyone understands. This helps all teams work toward the same things. What helped us was letting team leaders work together to plan and organize, but still letting each team make its own decisions. This way, teams stayed flexible and creative and focused on the company goals. Always encouraging teams to improve a little every day kept the process moving forward.
When we scaled INK from a tight-knit squad to a fully remote, global team, we quickly learned that agility comes from clarity. Strict frameworks didn't hold us together. Rhythm and visibility did. We anchored our operations in EOS (the Entrepreneurial Operating System) to keep priorities sharp. Then we introduced short daily stand-ups to flag blockers early, and a 30-minute Friday meeting where every team shared wins, lessons, and friction. To avoid slowing ourselves down with unnecessary meetings, we leaned hard into async communication. The goal was to keep work moving and context accessible, no matter the time zone. But the real glue was values. At INK, we prioritized our values. When decisions get murky, they're the tie-breaker. They help us move fast without losing the plot. If you're struggling to scale agile, resist the urge to layer on complexity. Create a consistent cadence. Make progress and pain points visible.
As I was leading a team through this journey of scaling agile, the moment came, when we shifted from seeing agile as a process rollout, and began to envision it as a change in culture. Initially, we treated the agile rollout by copying the sprint cadences and rhythms of one high-performing team to implement everywhere. This approach fell short. Each team had different needs and behaviors. What was more useful was creating common principles-Such as short feedback loops, visibility of work, and ownership with agency along with flexibility to adjust practices to their context. We also spent time in cross-team retrospectives where we found bottlenecks not just in what teams were doing individually, but how teams were working with and relying on each other. My recommendation is to focus less on uniformity, and more on alignment; having clear goals, transparency and confidence to take risks within an aligned framework. That level of structure and autonomy enabled us to successfully scale.
Standardize the work before you scale the work. Our agency reached a design wall when the independent operation of design, development and SEO teams pursued "agile" methods. The team developed a common Definition of Ready and Definition of Done and tiny handoff checklists for use. Each week during the Ship Room on Thursdays the teams demonstrate their upcoming seven-day shipping projects. No slides, just the thing on screen. The single cadence system reduced the "almost done" accumulation while preventing continuous work shifts. The agency achieved boring standardization of operations thus preventing additional team additions from becoming challenging.
Small pilot testing should begin before bringing the room to decide on scaling. The initial implementation of our process involved two teams and a common board system. During my one-week observational period I maintained silence while asking those teams to choose a single change for testing during two sprint cycles. The team selected implementing a brief family meeting on Saturdays. The team implemented the new process into their standard procedures after its successful trial before moving to the next experimental phase. The process of listening followed by testing and then adopting maintained both high energy levels and low political tension. People trusted the process so much that replication became straightforward.
Protect cadence before you buy tools. The team at Alpas experienced an overwhelming number of good intentions combined with disorganized tasks. Our organization established four weekly rhythms which we maintained regularly: case review, ops standup, data huddle, and process fix session for one hour. All tasks need to fit into the designated categories. The team achieved peace of mind because of the predictable routine while actual limitations became visible. The constant rhythm enables teams to implement long-lasting improvements. Tools entered the picture after the calendar system became our primary solution for success.
Frontline staff should lead the development of any new change design. Leadership continuously wrote the playbook for ceremony implementation across units when we attempted to expand ceremonies. It never landed. The organization established a Change Circle that meets once per week. A tech, a nurse, an admissions representative, and a counselor share the responsibility of facilitation duties through a rotating schedule. The team selects a specific friction point to address it. Leadership provides funding to support the proposal and removes obstacles that stand in its way. The basic procedure established ownership which produced consistent results. The team upholds what they have constructed themselves.
The entire value stream should be visible on a single board. The entire wall displayed intake, clinical, billing and compliance processes. The cross-functional team began their daily walk at the left end of the line which stretched to the right end. Red cards indicated that work was blocked. The ability to halt production existed for solving recurring problems. The established practice revealed hidden production queues while establishing clear responsibilities for each team member. A shared visual understanding by teams eliminates localized optimization efforts to reveal the actual bottleneck.
Before adding teams to your organization you need to establish capacity limitations. The initial surge in demand pushed us toward quick expansion. Quality slipped. The team stopped work to establish hard ratios and create a shared rubric and review checkpoints. The success of scaling depends on achieving defined performance targets twice consecutively during a pilot program. Advisors maintain awareness of their workload and students experience steady services while leaders monitor equivalent indicators. The system operates through basic repetitive procedures that maintain its efficiency in expanded operations.
Wait until the floor is prepared before you open the marketing faucet. We approached agile scalability through the approach of valve management. The first step involved mapping the initial 72 hours of stay procedures between teams followed by time reduction efforts. Intake and admissions received training to prevent clients from being delayed because of staff absences. We began campaigns only after completing this step. A streamlined operational process emerged as a result of these efforts together with reduced emergency situations. Agile at scale is choreography, not more ads.
SEO and SMO Specialist, Web Development, Founder & CEO at SEO Echelon
Answered 7 months ago
Good Day, I'd suggest starting very small but consistent around aligning leadership and teams with shared goals more than enforcing frameworks. What really helped us was creating cross-team communities of practice, and that was where everybody talked about what they were winning at or struggling with. All this just built the buy-in, and scaling agile did not feel like a mandate for people but rather like a shared state of evolution. If you decide to use this quote, I'd love to stay connected! Feel free to reach me at spencergarret_fernandez@seoechelon.com
To effectively scale agile practices beyond a single team, organizations should cultivate a culture of collaboration and transparency throughout all levels. This includes implementing agile values organization-wide, not just at the team level. Agile champions or coaches play a crucial role by facilitating inter-team collaboration, running workshops, and creating forums for sharing experiences, which fosters idea exchange and enhances processes and outcomes.
If an organization wants to use agile with many teams, the most crucial advice is to ensure all teams talk and work well together. Agile works best when people share information and give feedback often. Using a simple framework like SAFe or LeSS helped teams follow the same way of working without complicating things. Also, teaching each team about agile and having a few experts inside each team helped everyone learn and keep improving.