Let’s imagine you are the agile lead for various Scrum projects at your organization or your client’s. The agile teams are engaged, operating at consistent velocities and have shown solid signs of self-organizing. Moreover, after each sprint, workable and fully-tested software is being shipped. Next, imagine the CIO or client walking into your office and telling you that you need to scale your 2-3 agile pilot projects to 10 teams within the next six months. Yikes! What do you do? Maybe, implement LeSS (Large-Scale Scrum framework)? Bring in DAD (Disciplined Agile Delivery)? Or add a consultant to ensure that you are on the SAFe (Scaled Agile Framework) side?
Although the three approaches and frameworks mentioned above have been conceived to enable enterprises to scale their agile transitions (or at least make these transitions less painful), I was actually referring to a more organic way of scaling agile, namely scaling Scrum. Often, when teams are considering scaling their agile practice, they are not thinking of a C-level change, implementing a portfolio-wide framework or enterprise transformations. Instead, they usually want to scale what has been working for them so far – their Scrum development process.
In theory, Scrum can be easily scaled for effective use in large(r) projects. However, in reality, we all know that scaling is hard, IT problems are complex, and a lot of people are still married to waterfall. So, unless you have to, just don’t do it. However, since this post is based on the CIO walking into your office and telling you to scale the agile practice, here are some of the techniques or approaches that can help you with this effort.
My first piece of advice for scaling agile is continuing to do what has worked for you so far and that is keep focusing on doing Scrum. This often means continuing with the same product owner (PO), and keeping the same (singular) product backlog going. You may at some point increase the team’s size, or even add more teams to the project.
Once you have established multiple Scrum teams, convening Scrum of Scrums is a natural next step for scaling agile. The secret ingredient of Scrum of Scrums is multi-team stand-ups. With this approach, each Scrum team proceeds as usual, but each team identifies a (technical) member, sometimes designated as an “ambassador” who attends the Scrum of Scrums meetings. Scrum of Scrums is a short meeting and should not go beyond 15 minutes. Also, Scrum of Scrums is not a status meeting, rather it’s a focused discussion on potential impediments that may affect the teams. It’s perfectly fine to have a Scrum Master lead these meetings and team members can decide what actions (if any) to take and by whom. Scrum of Scrums is not intended to discuss team-level stories or releases unless these items impact the other teams. Often, Scrum of Scrums will center on large work items such as epics or themes. Scrum of Scrums does not necessarily happen every day and most of our teams chose to have the Scrum of Scrums only 2 or 3 times per week. Several of our teams have extended other agile ceremonies (e.g. sprint planning and sprint retrospectives) to Scrum of Scrums. Having Scrum of Scrums retrospectives after conducting team retrospectives can certainly enhance overall communication and cross-team coordination.
My second piece of advice regarding scaling agile is scaling the infrastructure or tools. As each agile project is unique, each scaling effort will be unique as well — as no magic bullet to scaling exists. Scrum Masters and Agile Coaches will constantly have to keep the organization’s culture, goals, strategies, challenges, opportunities, practices, people and infrastructure in mind when scaling agile. Although adding people or teams to an agile project may be the most straightforward scaling approach, scaling or investing in flexible infrastructures, continuous integration and automated deployments will often deliver more sustainable value, much faster. The combination of agile software development practices and IT automation to shorten development cycles also referred to as “DevOps,” frequently results in quicker and more efficient delivery of incremental working software. In the end, working software delivered faster is often what we want we when aligning IT with our business objectives.
Regardless of how you start your agile scaling journey, it’s key to keep your agile scaling effort itself “agile” and transparent by reviewing your processes, tools, architecture, team composition and cross-team collaboration regularly, and making tweaks and improvements on an ongoing basis. Lastly, choose a scaling framework that you are comfortable with, and adjust it as it evolves frequently.