4 essential elements of Agile at scale

The principles of Agile software development are on the move in many enterprises: Agile principles are moving into other parts of the IT organization besides software development, and they are migrating as well to other business functions.

This movement, known as Agile at scale, involves a whole way of working. Dave West, the CEO and product owner at Scrum.org, focuses on scaling Agile in the IT organization in part one of this two-part series. Among the must-haves: establishing business value metrics, aligning Agile teams with customer outcomes, developing Agile talent and managing change. But before embarking on Agile at scale, cautions West, CIOs must decide what kind of IT organization and IT leader they want to be.

Editor's note: The following has been edited for length and clarity.

When we talk about Agile at scale, what does it mean? Is it agility on steroids?

Dave West: We should never aspire for agility. We should aspire to deliver more business value in a complex world. The way you deal with complexity is empiricism, self-organization and continuous improvement -- which is labeled agility. It's the ability to be responsive to the market, to basically change how you organize the work and how you do the work, which includes how you deploy technology in the complex situations that you're trying to solve. So, ultimately, Agile at scale is the ability of an organization to respond to the environment in the most effective way.

Dave West

The Scrum.org website talks about Agile at scale horizontally and vertically. Can you define each of those?

West: You can scale Agile teams horizontally: An IT organization can add more Agile teams without being an Agile organization beyond those teams. So, you have more people doing Scrum, more Scrum masters, more product owners, more developers all working together.

Vertical scaling is about adding the [customer] value stream. The value stream might start with the product manager or the businesspeople who are actually involved with IT. It might include the operational and deployment departments that are involved, so suddenly you're building this truly cross-functional set of teams that are aligned to customer outcomes. One of my favorite versions of this is the Spotify model. Spotify created squads that were aligned to customer outcomes or elements of the customer value stream. And then those squads included people from operations, marketing, music procurement if that was necessary, all sorts of bits and pieces.

If a CIO were going to scale Agile within IT, what are the essential elements to get right?

West: I'd say four elements. No. 1 is measurement. You need to put in place a series of measures that aren't motion measures like on time and on budget, but rather measures that are more about outcome. One measure is about current value; if you're an IT organization, current value could be measuring how satisfied your customers are. Another measure could be time to market, or how long it takes for your customer who wants a new feature -- an internal customer if it's IT -- to get that new feature. You can also measure how much of the IT work is innovating vs. upgrading. Obviously, each situation will be different and will determine the metric deployed, but these types of metrics at least provide us with an idea of the value we're getting.

No. 2 is alignment. You must align the Agile IT teams to the customer.

No. 3 is really around decoupling what I describe as work management from talent management. The classic Spotify model is chapters and guilds vs. squads and tribes. Work is aligned around squads and tribes, and skills and development are aligned around chapters and guilds.

So, we've got measurement, alignment and this decoupling of skills vs. work.

No. 4, which I think is super important and that most organizations sort of just do for a moment and then forget, is [managing] change. You need to build an organization that's continuously monitoring the impediments to change and continuously helping resolve those impediments if they can't be resolved by the team.

What is the biggest challenge for CIOs as they bring Agile at scale in IT?

West: Ultimately, CIOs have to decide what they want to be. Do they want to lead an IT organization that responds to its internal customers in the most efficient possible way? Do they want to be order takers, ultimately, and start building an Agile factory of delivery to support the business? Or do they want to champion more systemic change where they engage with the customer -- the external customer -- in the most effective way and involve the business in that transformation and drive that change? That's the No. 1 question IT leaders need to answer.

So, CIOs can't just stop with scaling Agile within IT?

West: I don't believe it works within just IT. If you're a CIO and you're being measured in terms of delivering new features that the business asks for -- delivering it in the most efficient way possible, delivering it faster -- OK, then you can build an Agile organization that delivers to that metric in a very effective way. But it doesn't mean you're getting business value, because the business is a proxy for the ultimate customer, the external customer.

The unification of technology and business together is how you deliver innovation. That fundamentally means becoming Agile across the whole product delivery lifecycle. That means the specifications are never really done. That means continuous change and that means you have to frequently get the customer involved with product. It also means frequently releasing new capabilities to the customer.

So, for CIOs, the question they have to ask is: Is [my role] to deliver to my internal customer and do all the things they expect of me, or is it to drive business change to become a digital enterprise and deliver to the end customer more innovation?

Editor's note: In part two, West discusses fundamental steps for scaling Agile across the enterprise.