Do agile principles work at scale: Part 1?

The agile manifesto and principles have been excellent guiding lights for the IT industry for close to 20 years. They have revolutionized the way software is developed and have spawned the DevOps practices that many organizations are adopting for their digital transformation journeys. While agile principles arose initially to help small teams deliver their IT solutions, many organizations are trying to apply them to large-scale enterprise solutions that require hundreds if not thousands of practitioners. 

To solve this challenge, many scaling frameworks have been developed. Some (e.g., LESS and Scrum@Scale) try to solve the scaling problem without veering from the original 12 principles.  Others, namely the Scaled Agile Framework (SAFe), recognize the importance of the 12 principles, but seek to evolve their application to work effectively at scale. In this two-part blog, I explore each principle and identify the issues with applying them at scale. In this first post, I’ll focus on the first six principles.

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

This is still the goal at scale. The problem is that the earliest agile practices primarily focused on development not operations. This is why DevOps is so popular. If we can’t effectively release software incrementally and often in a complex multilayered platform, all of our agile teams are stuck. Agile without DevOps makes scaling exponentially more difficult.

2. Welcome changing requirements even late in development. Agile processes harness change for the customer’s competitive advantage.

This is also a goal at scale; however, change at scale has a much larger potential impact on the development organization. Changing what a team of 7 to 11 people is doing is a walk in the park compared to the change required for a solution involving thousands of developers.  Reprioritizing a single feature may impact several teams. Making a single architectural change may impact every team. Just communicating such a change is significantly more complex. 

To pivot easily and quickly, all work must be in a completed or not started state. Scrum is designed to enable change to be introduced at the start of each sprint.  Once the sprint has started, good product owners know that they need to protect the team from changes. This is why SAFe introduced program increments. Large solutions need a longer-term vision in order to manage planning properly and respond to change. You also need every team sprinting on the same cadence so that all work is completed in a synchronized way.

3. Deliver working software frequently, from a couple weeks to a couple months, with a preference to the shorter timescale.

As with principle 1, DevOps is a key accelerator for making this happen at scale. You also must consider that the organizational impact of changes to complex solutions is often significant. Changing how an ERP system is going to manage the supply chain could require weeks of preparation and training of the organization, for example.  Additionally, there are compliance issues that must be satisfied. You would need agile teams of 20 or more people to deal with all of these issues. This is why frameworks such as SAFe have a system team to support the agile teams so they can focus on building the next feature.

4. Business people and developers must work together daily throughout the project.

At scale, we move away from projects to products. Products need constant care and maintenance. There is no end to the work. Banks will always need lending systems; manufacturing companies will need ERP solutions. You can pull a business person from their day job for a short project, but not for a never-ending program. The day you designate a business person as your product owner who is to be dedicated to the team, because that person is no longer part of the business, their value in terms of business understanding will diminish rapidly.

SAFe introduces the product manager role as a key enabler. This is a part-time role that allows this person to stay in their day job, thus maintaining their value of understanding the needs of the business. They work closely with the product owners and rely on them to provide the day-to-day interaction required by the team.

5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

This is still the best way to work. At scale it takes exponentially more effort, especially when you are dealing with multi-cultural distributed teams, often spread across 3 to 4 different time zones and countries. The communication challenges create significant barriers to building trust. Team structures often need to be morphed to include things like proxy product owners. Security concerns often hinder the ability to provide the environments and tools the teams need.

6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

This is still the most effective way but, at scale, not always the most efficient way. At scale, you have teams of teams. As a result, you have to be more creative in finding effective ways to connect. Communicating architectural decisions to thousands of people requires a well-documented solution intent and context. There are too many people involved to be handled face to face. SAFe includes a solution intent repository where this kind of information is retained and made available to all of the teams. Solution-level, non-functional requirements and personas are kept here, along with epic case studies, market research and any other information that will help the teams build the solution. Multi-cultural and distributed teams also make this more challenging. Body language and gestures have significantly different meanings across cultures. Having written documentation is vital to make sure people understand decisions.

These are just a few thoughts on scaling considerations for the first 6 of the 12 agile principles. In part two of this series, I’ll look at the remaining principles, and explore the challenges and best practices for scaling them.