The case for CIOs taking charge of Agile at scale

Cross-functional teams, iterative development, minimum viable products, continuous improvement -- the hallmarks of Agile software development are increasingly seen as relevant to other parts of the enterprise, giving rise to a movement known as Agile at scale.

What does Agile at scale (also called Agile management or scaled Agile) actually mean for an enterprise? What are the impediments that can cause it to fail, and who in the enterprise owns it?

Dave West, the CEO and product owner at Scrum.org, tackles these questions and more in part two of a series on scaling Agile. One matter of urgency for CIOs, according to West: CIOs who aim to play a role in business transformation should position themselves as drivers of Agile at scale -- and redub themselves chief digital officers.

Editor's note: Read part one of this two-part series, "4 essential elements of Agile at scale," where West discusses doing Agile at scale in the IT department. Additionally, the following has been edited for length and clarity.

Does Agile at scale in the enterprise mean that everyone is working in an agile mode, or are there places where Agile principles won't work?

Dave West: That is the $64,000 question, and the short answer is I don't know. What I do know is Agile is very aligned to solving complex problems. And the most complex time is when you're developing a product or service, whether it's a banking service or a car.

Dave West

The traditional industrial model is a very small group of people working in a chaotic way where we pretend that we're using traditional project management [such as] waterfall, so we can develop and then build an operational system in which variability and change is nominal -- and then that's it.

The mantra with Agile is develop the product and then transition to a traditional operational system where variability and changes are relatively small, so complexity is much smaller.

But the reality isn't that. The reality now seems to be that that transition point is getting further and further away, if ever. That means [a company] is changing its software all the time and provides updates all the time.

When do you make the transition to a stable state?

West: The answer is, 'It depends on your situation."'

As software becomes a larger component in most of the things [you produce], it's certain that you don't just release once a year now, or once every two years. Software is continuously changing, services are continuously changing, so the relationship between operational and development is a lot more blurry.

The fundamental question for organizations becomes have you got a moment when the products or services being delivered go into a truly operational mode? Or are you always in this process of re-invention as your customers' needs change and as your understanding of the customer changes, or as the opportunities or the technologies change?

What gets in the way of companies scaling Agile?

West: There are impediments, particularly those around legacy systems, alignment, incentives, politics -- all these things that are also known as culture -- that get in the way of teams delivering in an Agile way. Therefore, you need to have some sort of enterprise change team. And you need to use an Agile approach to manage this change.

Ultimately, the leader, who is ideally the CEO, would be the product owner of this enterprise change team. All of those issues would come up and he or she would be prioritizing them and then bringing them down to the team and saying, 'OK, let's change this,' or, 'Let's provide this environment to be successful.'

Is there a point when you're achieved Agile at scale?

West: If you can build an organization that's always probing and sensing and responding, then I think you've become agile and that's Agile at scale. You've scaled [this approach] from a small team -- a developer, tester and business analyst working with a product owner from the business -- across that whole organization. That doesn't mean you're finished in terms of change, but it does mean you're finished in terms of building the environment to allow change.

What are the steps CIOs can take to bring Agile to the broader organization?

West: There is already a desire in the business to become more responsive to the market, so that means that there's a great opportunity for the CIOs to step into that. But it is a choice for the CIOs. I believe that they should do that. I believe that, ultimately, their responsibility isn't a technology responsibility. Instead, they're responsible to the company, the shareholders or the owner, if it's a private company. [Their responsibility] is to deliver value to the end customer and to increase the value of the company's investment by continuing to deliver more value to that customer.

I think CIOs should drive innovation, but what worries to me is that a lot of them are being left behind; their organization is functioning as service organization to these Agile squads and teams. CIOs have to say, 'I'm no longer a chief information officer, because that's an outmoded concept.' Rather, 'I'm a chief digital officer. I'm responsible for taking us into the digital age, that's my job.' Yes, we have some existing stuff we have to manage and control, and I'm going to hire someone very competent to do that mundane work, and I'm going to drive this huge agenda. That's what I would do.

Who owns Agile at scale in the organization?

West: I think it's the CEO. I think CEOs are the ultimate decision-makers and drivers. What they do is they empower, they create a proxy. The question is who is that proxy going to be. Is it going to be the COO or the chief product officer or some business proxy? I would argue that it should be the CIO, assuming that they are a fan of business and technology coming together. The CIO should be that empowered individual to drive this change.