Scaling Agile:
By Ben Hall, Vice President, Technology | Published: April 4, 2023 in Blog
Software developers have seen the success of being agile. Agility lets them deliver value early and often. However, an agile approach that works for a team or a small business does not always work for large enterprises. They look to frameworks such as the Scaled Agile Framework (SAFe), Disciplined Agile (DA), Large-Scale Scrum (LeSS). The challenge is to coordinate the work of various teams, aligning them to a common strategy, while keeping the teams individually effective. Scaling agile does work though…sometimes. Over the years, we at Intelliware have seen some large organizations have a great deal of success scaling agile, and others continue to struggle. What sets those successful organizations apart?
I. The Meta-process of Retrospectives
When anyone starts learning something new, instead of experience, it’s fair to start with existing rules. As we gain experience, it is appropriate to reflect on the rules and customize our technique. We look at how well we’re doing so we can adjust the process as we learn where it does and does not fit our specific context.
Many in the industry are skeptical about SAFe, but SAFe contains some good ideas. For example, the fourth pillar of the SAFe House of Lean is “Relentless Improvement.” It encourages practitioners to “optimize the whole, not the parts, of the organization and the development process.” This is a key differentiator between organizations who have successfully scaled agile and those who struggle. Those who succeed are willing to evolve and iterate on the process. What they do today looks significantly different to what they did five years ago.
For one of our clients, Big Room Planning originally consumed two or more days including everyone from the programme. Today it is just as effective with a couple of representatives from each team planning together for a couple of hours.
II. A Culture of Empowerment
High performing scaled agile differs from low performing in the degree to which they empower teams. Teams need to organize their local processes as they see fit. However, in some cases, the fourth pillar mentioned above (“optimize the whole, not the parts”) is used as an excuse not to allow teams flexibility. This misinterprets “optimizing the whole” as “don’t permit local optimization.” But as Daniel Pink shows, autonomy is required for motivation.
There are many ways for teams to be dis-empowered. For example, if there’s a separate team in charge of certifying the security of a release, then the development team does not control all of the necessary steps on the path to production. In fact, their incentives are at odds with each other—the development team has the goal of delivering more frequently, while the security team has the goal of safety and that’s usually in tension with accepting frequent changes. Consider the difference if instead the security team’s role is to enable development teams to assure security themselves.
Some of our clients have automated many of their security checks during the continuous integration pipeline:
-
- Static code analysis with a security profile.
- Scans for known vulnerabilities in third-party libraries.
- Dynamic security scans and automated security attacks.
- Fuzz testing.
Having sufficient automation in the pipeline helps them to create a proven track record of safety. This track record then allows them to do penetration testing outside of the pipeline, i.e., not on the critical path. They still do manual penetration testing, but batch it and perform it after several production deployments.
It can be challenging for organizations that were traditionally hierarchical to adopt a mindset of servant leadership. Ideally, these leaders should unblock the team and then trust them to do their best. Instead, leaders who struggle rely on their experience in “managing people” which tells them that the only way people do the right thing is if they’re told what to do and how to do it. However, our clients who get this right create a team environment that fosters autonomy and in which individual contributors love to work. In fact, our clients can create an environment that is so good that it’s difficult for Intelliware to reassign developers who’ve grown attached to their favourite empowering clients.
Often in large enterprises, we see that a particular group is tasked with leading “The Agile Transformation.” This group owns the initiative to make sure that everyone is “doing agile.” In the worst cases, the initiative is implemented as dogmatic pronouncement of the rules. As we said about retrospectives, it is good to have a starting point. But after that, your approach should adapt and evolve from there. Most importantly, that adaptation should be driven by experimentation that is empowered at the team level.
III. Delivering Value to Production
Organizations scaling their agile practices can get distracted by the process itself. They seem to forget their purpose, thinking more about how they are working and thinking less about why. As Jon Smart puts it in Sooner Safer Happier, we should focus on outcomes, not outputs. It doesn’t matter how many story points are completed, or the number of screens or components produced, or the number of test cases executed. The ultimate metric is the desired outcome: dollars spent, or customers acquired, or meals served. However, in the complex systems that make up our enterprise clients, it’s often difficult to look past the immediate few links of the value chain to which a team contributes.
Deployment frequency and throughput are two of the most predictive metrics for software delivery performance. Why frequency? To understand this, recognize that risk doesn’t come from the number of deployments. Instead, risk is a function of the volume of change in the deployment. That volume of change could be the amount of technical debt fixed or the number of new features. A software development team working for two months can create a lot of change and the quality assurance effort required to address that change is similarly large. If you compound those months of change with the coordination of multiple, inter-dependent service changes, the risk increases combinatorically. Instead, high-functioning groups can deploy every service every day with low risk. The risk is low partly because they have the right tooling but most importantly because the batch size of each change is necessarily small.
Success here requires a sophisticated technical delivery platform. A pipeline can include packaging a deployable, automatically testing and scanning it, deploying it to various environments, feature flagging, and blue-green deployments. This can be complex and difficult to build. How do you go about creating this pipeline? Repeatedly answer two key questions:
What’s the next change that will most improve time to delivery?
What’s the next change that will most improve team autonomy?
Recently one of our clients kicked off a new piece of work with an additional development team from Intelliware. The existing team prepared the ground for the new team before they arrived. They created a walking skeleton application, fully integrated with the CI/CD pipeline and deployed to production but not accessible to the public. Clearly this required a sophisticated technical pipeline, but just as importantly, it required the agile mindset of our business and technology partners to see the immense value of this approach.
IV. Align Teams and Architecture
When an organization is large enough to need multiple teams, the next challenge is how to distribute work or responsibilities across those teams. It turns out that team organization and technical architecture should be designed together. Conway’s Law comes from Mel Conway’s paper published in April 1968.
Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.
This is rephrased by Ruth Malan as
If the architecture of the system and the architecture of the organization are at odds, the architecture of the organization wins.
We see organizations struggle with this in a number of ways. A common failure starts with having multiple teams work on a single code base. Sometimes this is difficult to avoid, e.g., when a large monolithic system requires a lot of concurrent work. By itself, this is problematic, but not impossible. Failure starts when the teams are kept decoupled from each other by working on long lived source control branches. Branching sounds like a solution, but in fact makes the problem worse. In a recent case, we saw two teams working on two long-lived branches. All the developers were highly motivated to avoid merge conflicts. This meant that healthy behaviours of refactoring and addressing technical debt as it’s found were discouraged because the effort involved in resolving merge conflicts is huge.
Instead, the teams in this case decided to bite the bullet and merge their separate branches, and then combine into a single large team. This tactic unlocked the ability of the teams to improve the maintainability of the code base while they continued to deliver features.
Conversely, we also see organizations struggle when they assign a team to do a similar kind of work across several related services. For example, at first glance it might seem sensible to have a single team responsible for applying a series of security updates to third party libraries across several separate services. This path is well-intentioned: security updates are a specialized skill and by concentrating this skill in a specialized team will be more efficient. The problem came when the dogmatic process required the team that makes a change to also be the team that deploys the change. Instead, successful organizations know that a single deployable service should be owned by a single team. The best of both worlds (the specialization of skills with the ownership of a product) can come by treating the specialists as a team that collaborates with or facilitates the team that owns the service.
An Integrated Delivery System
So, is scaled agile working? In true consulting fashion the answer is “it depends.” What does success depend on if you want to scale to an integrated delivery system?
- Start with a plan or a framework but reflect as you go and iterate on the process.
- Move leaders away from directing work and instead have them clarify goals for teams, remove obstacles, and empower teams to find their own way.
- When clarifying those goals, focus on value and outcomes not the process or its outputs.
- Design team structure and architecture together, thinking about decoupling across both.
Contact Intelliware to discover how to create your own integrated delivery system, we’re here to help.
More recent stories
