Scaled Agility vs. Team Agility – 5 Things You Need To Know

The concept of “scaling” within the world of Agile development is something that is often confusing because there is no single “book of knowledge” that provides a formal definition. Some organizations that I worked with previously feel that as long as you understand how to apply Agile methods at the team level, you can simply replicate the same techniques over and over again to manage more complex project environments. In this case, the idea is basically akin to building the same widget at a higher volume. While this approach sounds logical, scaling Agile teams and organizations is often not quite as simple or straightforward, and much of this depends heavily on the nature of the product that is being built.

Let’s take a look at an example to help clarify my point.

Let’s assume we are building a single-family house from the “ground up”…no pun intended. We would need all of the basic skills that we expect such as plumbing, electrical work, architectural/structural work, etc. The process for building a house has been established and standardized for some time, so this process should be relatively well-known without many surprises/uncertainty. However, if we are looking to build an entire community of homes, the level of complexity goes beyond simply replicating the exact same blueprint for a single home across the entire community. In order to build a collection of homes, we must now account for coordination of workers, supplies, equipment, etc. which will be required to ensure optimal deployment of key resources; more specifically, if we need two bulldozers to prepare the ground prior to the foundation can be established for a single house, we would not necessarily need 5 times as many for 5 houses because we should look for ways to optimize the use of the bulldozers in the interest of efficiency.

Scaling agility follows a similar thought pattern. If we are able to succeed with a single Scrum team and deliver a high-quality product, we will likely be ready to explore how to build larger, more complex products that offer even higher value to the customer. We will need to learn how to grow the project team in an intelligent and efficient way so that we minimize (or eliminate) duplication of efforts and enable teams to collaborate together successfully.

I have a feeling none of this is a surprise to you, but how do we exactly go about this? Here are a few ideas that I can offer you for your consideration when scaling Agile teams.

1. A solid foundation is critical – It is not a good idea to try to scale Agile if your organization has not yet demonstrated success with a single Agile team. Attempting to do so prematurely would be similar to trying to build an entire housing community without understanding how to build a single home first. This would be risky and likely lead to poor results.
2. Framework is important – Once you have mastered Agile methods at the team level, you are ready to expand the use of Agile, but you must choose a framework. Many organizations feel that they need something “special” because their business model is so vastly different than the rest of the world. My advice: choose a proven framework that is formally documented and has already been applied successfully by other companies. Inventing your own Agile framework may sound like an exciting project, but in my opinion, you should avoid reinventing the wheel when there are already many frameworks to choose from.
3. Do not expect results immediately – As with any large change initiative, success will likely take time. Do not expect to see benefits immediately. Be patient and establish some metrics to help you measure progress.
4. Set expectations early and often – It is usually easier to say “be patient” than to actually follow this advice, especially for senior leaders who demand to see the results of their investments ASAP. You will need to consistently manage expectations to help others understand how things are going because at times it will be very difficult to tell whether your scaling effort is actually working. Also, you will need to manage critics and skeptics who may not want you to succeed.
5. Ask for help as early as possible – Choosing a scaling method is easy, relatively speaking, but implementing it is definitely not easy. The increase in level of complexity to go from a single Agile team to five, six or even twelve teams is definitely a non-linear increase. This means that you will most likely benefit from acquiring support from an experienced advisor/coach who can help you avoid the landmines and help steer you towards the desired outcomes.

To wrap up, scaling Agile teams is not easy and is laden with potential disaster. Having a vision of where you would like to go with your scaling efforts is an important activity that should be done as early as possible. If possible, avoid trying to scale one team to ten immediately; try going from one to two or maybe three teams to see how they interface with each other. This will provide ample opportunities to inspect what is working and make adjustments as needed before you add even more complexity. Always reflect on the experience and don’t forget to celebrate small victories where possible to build positive momentum!

Eugene Lai