Scaling Agile 101

Now that many companies have found success with Agile development methods, they’re turning to the next logical question – how do they begin scaling Agile from individual teams to the enterprise as a whole so that they can realize even more of its benefits?

“Scaling” is the word many people use to describe expanding Agile processes to additional areas of their organization. What that looks like and how to make it work can be tricky to define, particularly in a large, complex enterprise.

What we do see, however, is that most efforts at scaling Agile are taking place on two levels:
1. The team level – broadening the use of Agile to more teams and users – including those on the business side, and
2. The project level – expanding Agile’s use to larger, more complex projects with many stakeholders and higher risk.

Ultimately, the greatest benefits of Agile development await the organizations that go above and beyond what we might call these “small-scale” efforts to transform at
3. The enterprise level – with Lean-Agile principles and practices permeating the organization from top-to-bottom and end-to-end, fundamentally changing the way business is done.

However, when trying to expand their use of Agile, most organizations encounter common challenges that prevent them from scaling as quickly or as widely as they’d like.

DevOps has helped to accelerate Agile adoption across organizations, but scaling vertically and horizontally remains the biggest obstacle. This is primarily because these organizations are unable to reconcile differences between traditional development and Agile development worlds and, more specifically, the people who live in them.

Scaling Agile from the Team to the Enterprise

Scaling Agile at the Team Level: Embracing the ‘low hanging fruit’

According to a recent Forrester report on the state of Agile, most organizations say they leverage Agile practices today. However, they also stated that more than half (60%) of their organizations’ teams are not yet practicing Agile. This type of Agile environment presents a significant opportunity for improvement at these organizations.

Because Agile best practices at the team level are already well-established at these organizations, broadening their use to additional teams and users is straightforward in most environments. The maturation of Agile practices at the team level has come to be known as the “first wave” of Agile.

At this level, CIOs primarily focus on expanding the use of Agile to more teams, including those that aren’t commonly considered “good fits” for Agile. These can be teams that are rolling out packaged applications or modernizing legacy platforms, for example.

They also try to spread Agile processes further into the business. Although the Agile Manifesto recommends that business people and developers work together daily, in reality, that is challenging. In most large organizations, research has found that only a small part of the company is consistently conversant about Agile and those folks are predominantly in IT.

Scaling Agile at the team level is the low-hanging fruit for a large organization that has realized success with Agile on a small scale, enabling them to easily gain additional benefits with a low level of effort and risk.

Scaling Agile to Large, Complex Projects with Many Stakeholders: Agile at Scale

Scaling Agile at the project level is more challenging than at the team level. It involves extending Agile principles and techniques to larger, more complex projects with multiple development teams and numerous business and IT stakeholders – something a first-generation, team-based methodology like Scrum wasn’t designed to address. It also requires an overhaul of early processes to accommodate distributed, part-time participation from specialists and the coordination of activities and deliverables across multiple Agile teams working on different products with varying cadences.

Unlike the widespread agreement on what works for Agile at the team level, we’re still in a divergent state when it comes to this “second wave” of Agile – which has been called “Agile at Scale.” In an attempt to converge on best practices for implementing Agile at the project level, scaling Agile frameworks were developed.

The three most common frameworks are the Scaled Agile Framework (SAFe), Disciplined Agile 2.0, and Large-Scale Scrum (LeSS).

Each  scaling framework takes a unique approach to solving the problem of Agile at scale, but they all share the following characteristics:

  • They are built on a foundation of Scrum and/or Kanban at the team level and leverage a wide array of Agile, Lean, and systems thinking practices.
  • They define a set of values and principles which build on Agile and Lean concepts.
  • They emphasize overarching concerns, like architecture, security, and performance, and the resolution of dependencies and inconsistencies across projects.
  • They synchronize the delivery cadence of multiple teams, rolling up features delivered by each team into a unified release.

The industry is in the early stages of adopting these scaled Agile frameworks. Studies show that only 28% of organizations have adopted SAFe and other frameworks are largely untested, having only single-digit adoption rates.

Scaling Agile at this secondary, project level is a significant endeavor. It not only requires new roles and processes, but also enterprise-scale support from technology to enable cross-company collaboration, precise cross-project traceability, and detailed impact analysis in order to manage the complexity involved in larger projects.

Scaling Agile to the Enterprise: Becoming an Automated Digital Business

We are now at the edge of a “third wave” of Agile, which requires more than just an effort to scale to multiple teams, stakeholders or departments. In this third wave, aptly dubbed Enterprise Agile, the objective is to transform how an organization leads and manages their business as a whole by shifting to an Agile mindset.

This large-scale transformation demands a fundamental shift in the way an organization thinks and acts. Everyone in the company needs to be laser-focused on delivering customer value as quickly as possible. Transparency, empowerment, and feedback-driven adaptation act as core enablers within this shift. In this state, the business doesn’t have to align with IT because business and IT are one.

As with smaller-scale efforts to expand Agile use within an organization, this third wave requires new roles and processes. It also requires that an organization embrace modern technologies to streamline and improve the software delivery lifecycle.

How Technology Enables Enterprise Agile 

Agile planning and project management tools accelerate product delivery by automating manual tasks and using artificial intelligence (AI) to learn and iteratively improve application development processes. They also enable predictive analytics through a combination of data mining, statistics, modeling, and machine learning to analyze current data and make predictions about the future.

Through intelligent automation of the software delivery lifecycle, organizations can reuse standardized components, like requirements, code, and tests, assembling them in novel ways to increase the speed of innovation and reduce complexity. They can also ensure continuous alignment to business objectives throughout the delivery lifecycle to make sure that controls and guardrails prevent innovation from becoming destructive.

As of this year, 75% of enterprises have more than four different automation technologies in their IT management portfolios, up from less than 20% in 2014. By 2020, 50% of IT organizations will apply advanced analytics in application development to improve the quality and speed of delivery. And 40% of the new investment made by enterprises will be in predictive analytics by 2020.

Scaling Agile: Key Concepts and Practices

Before we dive into each of the 7 steps above in greater detail, let’s review some key concepts and practices your organization should strive for and try to implement when scaling Agile.

Without a clearly-defined end goal, there’s no North Star to guide you through adapting your organization’s culture or structure to Agile methodologies. The result is a set of Agile practices that don’t make sense and don’t benefit your organization in the ways you intended.

Maintain Small Team Sizes – Keeping teams small ensures that every team member has the chance to absorb all relevant information, and allows members to effectively contribute to the work.

Reduce Iteration Durations – A common challenge for organizations trying to scale their Agile practice is finding the correct balance between iteration length and actual production. However, successful Agile implementations almost always focus on shorter iterations wherever possible. While short iteration durations may seem like a limitation at first, they will pay off in spades down the road.

Practice Organization-Wide Synchronicity – In many scaled Agile implementations, organizations will be performing simultaneous work across multiple teams, and likely on multiple products. It can be challenging to coordinate the contributions from across the entire company when each team is working with their own specific iteration duration and schedule. Therefore, plans should be made to synchronize the end-of-iteration periods across multiple teams. Failing to do so can lead to one team implementing a feature before another team is prepared for it, causing a negative cascade effect as teams throughout the organization must redirect resources to adjust to said new feature.

Utilize Specialized Roles – Many Agile practices have historically recommended a broadening of skill sets throughout the team, allowing for more generic, less specialized work to be performed. However, many managers and organizations are finding benefits from moving in a direction toward more specialization in roles but putting these roles on cross-functional teams, allowing for faster iteration and turnaround.

Evaluate Release Window Scheduling – Most Agile implementations are structured around a series of releases, each of which includes a series of iterations. It’s common practice for each release to coincide with the calendar quarter (e.g. six 2-week iterations, four 3-week iterations, etc). However, if you’re a larger organization that’s implementing a scaled Agile process then it may be worth synchronizing release cycles with business cycles, such as quarterly earnings cycles and the like. This allows the organization to better adapt to external factors between each release.

Assign Product Owner Roles – There are a number of benefits to assigning a product ownership role to at least one team member per product, even if your organization isn’t using Scrum. This individual should be the go-to contact and line of communication with users, able to communicate value-based priorities to the rest of the team throughout the development lifecycle.

By understanding the key concepts and practices your organization should be striving for and trying to implement when scaling Agile, your transformation will be much better positioned and focused for success, making it easier to adapt your organization’s culture or structure to Agile methodologies.

How to Start your Agile Transformation

If your organization is like most, you’ve likely begun to integrate Agile processes into your development practice to some degree and have reached a certain level of maturity. This is a great start, but it’s not Enterprise Agile – and enterprise-wide agility is what’s needed in order to remain competitive and innovative in today’s fast-moving digital environment.

Although there are many common challenges with scaling Agile, all hope is not lost. Our Complete Guide to Scaling Agile Software Development explores a number of techniques, best practices, and existing frameworks to help you and your organization scale your Agile implementations as large and as wide as they need to be.

To get started with your Agile transformation, you can jump to the beginning of the guide now or download a copy of the PDF to read at your own convenience