The IIL Blog

LinkedIn Newsletter | Join our Email List
Agile Meeting

Building an Agile Architecture

By Darrell K. Rigby, Steve Berez, Greg Caimi, and Andrew Noble April 18, 2022

In IT, architecture refers to the standards and technologies that enable collaboration across the enterprise. Agile software development is often inhibited by a company’s legacy architecture, because the new software can’t easily plug into the rest of the system. It’s much the same with Agile teams.

For example, a large financial services company we worked with wanted to improve its agility, and it launched a pilot to build its next mobile app using Agile methodologies. Of course, the first step was to assemble a team. That required a budget request to authorize the project and fund the resources. The request was batched with other initiatives waiting for the annual planning process. After months of reviews, the company finally approved funding. The app development pilot actually went quite well, and the team was proud of its work. Before being released, however, it needed to pass vulnerability testing, which would be conducted in a Waterfall process that already had a lengthy waiting list. Then it needed to be integrated into the core IT systems—another Waterfall process with a six-to-nine-month logjam. In the end, the total time to release improved very little.

These productivity gains illustrate the problem of different parts of an organization moving at significantly different speeds—a phenomenon that has led George Tome, of John Deere, to formulate a rule that someone else dubbed Tome’s Law. The law holds that commercialization velocity, or time to market, equals team velocity (the speed at which a team produces new value) plus organizational velocity (the speed at which the larger organization accepts and integrates this new value). If a team takes four weeks to create a new product and the organization 16 weeks to integrate it, the commercialization velocity is 20 weeks. If the team doubles its productivity to two weeks but the organizational integration doesn’t improve at all, the commercialization velocity will improve by only 10%.

In our experience, implementing Agile at the team level is relatively easy. Results improve quickly. So does team happiness. The bigger challenge is how to handle Agile’s rapid growth as it catches hold and rolls out to other functions. That’s where the idea of an Agile architecture comes in, and leading companies build it on five pillars:

  • Everyone on the same page. Individual teams focusing on small parts of large, complex problems need to see and work from the same ranked list of enterprise priorities. Forr example, If a new mobile app is top priority for software development, it must also be top priority for marketing, budgeting, vulnerability testing and software integration.
  • Change in roles before change in structures. Many executives assume that more cross-functional teams will require organizational restructuring. Seldom is that true, and usually it is detrimental. New structures can shatter trust and impede creativity for years, especially if they involve downsizing. Cross-functional teams do, by definition, require some form of matrix management. But the most important changes are clear decision rights and team self-governance. Roles change in beneficial ways even though the lines on organization charts look the same.
  • Only one boss for decisions. In an Agile architecture, it must be clear who commissions cross-functional teams, who selects and replaces team members, who appoints the team leader, and who approves a team’s decisions. People can have multiple bosses, but decisions cannot. Senior leaders need to avoid second-guessing and overturning product owners’ decisions. It’s fine to provide guidance and assistance, but if you don’t like the results, change the product owners rather than incapacitating them. If you’re going to hire extraordinary people, give them extraordinary roles and treat them with extraordinary respect.
  • A focus on teams, not individuals. While research shows that the general intelligence of individuals can affect team performance, the collective intelligence of a team is even more important. It’s also far easier to change. Agile teams use process facilitators (usually called Scrum Masters) to continuously improve their collective intelligence. Metrics evolve from tracking outputs and utilization rates (how busy people are) to business outcomes and team happiness (how valuable and engaged people are). Recognition and reward systems shift to weight team results more than individual efforts.
  • Questions, not orders. General George S. Patton Jr. famously advised leaders never to tell people how to do things. “Tell them what to do, and they will surprise you with their ingenuity.” Rather than responding to arguments with orders (“Because I’m the boss, and I said so!”), Agile leaders guide with questions: “What do you recommend?” or  “How could we test that?” Senior leaders grow from functional experts to general managers and enterprise strategists. Cultures move from siloed battles for power and resources to collaborative cross-functional teams striving to achieve shared goals.

This blog is part of an article that was originally published at www.bain.com/insights/agile-innovation. It has been reposted here with permission. 

Darrell Rigby is a partner in the Boston office of Bain & Company. He heads the firm’s global Innovation and Agile practices and is the former head of the Global Retail practice. He is also the author of Winning in Turbulence.

Steve Berez is an advisory partner in Bain & Company’s Boston office and a founder of its Enterprise Technology practice. They are the authors of Doing Agile Right: Transformation Without Chaos (Harvard Business Review Press, 2020).

Scroll to Top