Improving Agile Process at Scale

Recently, in preparation to deliver agile training for a shipment tracking company, I was struck by how many of the comments I heard from stakeholders sounded familiar to issues I have heard in previous engagements with other enterprise companies.

“Our teams don’t fully understand agile.”
“Our teams don’t know what to do when there isn’t a scrum master.”
“Our sprints goals fall apart when dependencies are missed.”
“Teams work to capacity, not to velocity.”

Supporting any process at scale is a challenging endeavor. Middle market and enterprise businesses have many challenges as they start to grow beyond several hundred employees—teams have to be very specialized to support repeatability, and scale means that inefficiencies are amplified and redundancies easily created.

In a recent survey on agile, only 16% of 1100+ respondents claimed a high level of agile competency across business units within their organization. This number underscores the need for most companies to improve their agile process—and even the minority of organizations that are high on the maturity scale may be able to push optimization further. Below are a few best practices in helping multiple teams within an organization get better at reaping the benefits of agile, while minimizing the impact of common pitfalls.

Tie your agile improvement initiative to specific outcomes.

Process change of any kind is a means to an end. Before investing in an agile initiative that will affect multiple teams, you need to plan specific objectives and key results to measure against. For the previously mentioned agile training 8th Light conducted, the executives of the shipping company wanted the workshops to focus on:

Reducing hours worked by engineers by better milestone setting through more accurate estimation
Structuring sprints more effectively to reduce quality assurance churn during the second half of sprints
Reducing redundancy in planning and overhead meetings via better executed agile ceremonies

It’s worth noting that in our case, the company we were helping had been employing agile practices in product development since their inception in 2014. Not all companies are on the same maturity scale. For companies where agile isn’t mainstream or where the practice of agile is less sophisticated, you might get a sense of some expected benefits of agile from D.F. Rico’s book on ROI and other benefits of agile process—or one of his summary research papers.

Have a well-defined agile education process.

Agile is a core methodology with a handful of popular variants, and each variant has its own fan base, nuances, and depth of practices for DevOps. Even seasoned hires may have less exposure to your particular variant of agile, so you need simple tools and processes for newcomers to understand what agile looks like in their new business environment. Bases to cover with agile education include:

Access to your company’s agile methodologies via internal documentation or intranet
A process for company-based agile onboarding for new employees—what everyone needs to know / how agile looks within your business domain
An agile onboarding that is specific to a team or business / an explanation of how the team measures value

Templates can help new employees understand why sprints are structured the way they are, or why meetings are run in certain ways——and how your company has chosen to tailor agile.

Plan for distributed agile responsibilities within teams.

Scale means variable results along a bell curve, and this is no different with agile. Not all teams or individuals execute agile processes with equal skill. While some companies have agile coaches or scrum masters, there’s a high degree of likelihood that responsibility for agile will be distributed on some teams.

Common structures I’ve seen used to manage process are:

Partial commitment from agile coach or scrum master – one person owns facilitation of agile ceremonies and outcomes but has no delivery commitments within the team
Agile coach or scrum master responsibility is assigned to a team member – that team member’s throughput commitment is adjusted accordingly, since they are picking up facilitation and oversight responsibilities
Rotating responsibilities for agile – a single team member is responsible for facilitating all agile ceremonies within a fixed time period, after which the responsibility is assigned to someone else
Responsibilities distributed throughout the team – one team member facilitates sprint planning, one team member facilitates retrospectives, and the same applies for other agile ceremonies such as backlog grooming and estimation

There’s no reason why a single mode in the above examples needs to work for an entire department or division—or even for a single team over a long period of time. Teams can use a tool such as an agile team agreement, RACI matrix, or accountability definitions and revisit the tool on a recurring basis to make sure that agile process is covered, and that drift in responsibilities between team members is intentional.

Adopt consistent metrics or estimation scales across teams—when possible.

There’s not going to be a magic bullet for success metrics between teams—but in a best-case scenario, similar teams can use similar metrics to support interchangeable resource management and help managers evaluate performance in consistent ways. Beyond velocity, the book Accelerate identifies four key metrics for development teams—linked to overall operational success:

Lead time
Deployment frequency
Mean time to restore (MTTR)
Change fail percentage

Velocity has value for understanding output, but the Accelerate metrics map to outcomes with evidence to support organizational performance. Having multiple teams focus on consistent measurement like these metrics is a way to ensure that managers can compare notes between teams and more easily identify when teams need intervention.

Consistent measurement isn’t a case for holding every team within a company to the same standard for “good.” For example, deployment frequency might vary by team based on different contexts like the size of a team or the nature of their product. But the use of consistent metrics can be a way to benchmark an individual’s team against their own previous performance, and tracking the history can allow teams and managers to more easily understand where optimization is needed.

Ensure teams understand how to deal with dependency management.

Agile is a method for continuous improvement, but process gets messy when teams have dependencies because it’s nearly impossible to keep change cycles perfectly synchronized. There may not be a one-size-fits-all solution, but in general teams can be trained to understand what actions to take when dependency commitments from other teams show up late or inconsistently.

Let’s say you’re 3 days into the sprint and that API and data schema your team was waiting for just came in, but it’s not working according to the spec you provided and the developers are investigating. Should the team be modifying the sprint goal? Should additional change provided by the developers be represented as new tickets?

The point of these prompts is that dependency management is almost always situational to teams and often does require identification of root cause and process change. In most cases, how this looks will be very specific to the 2+ teams affected. If you’re looking out for early warnings that there is a recurring issue with a specific dependency, you can start collaborating with the 2+ teams affected to stay in front of necessary changes.