Stepping stones to an agile enterprise transformation

Few IT organizations—or enterprises—can make the leap to agile in one fell swoop. Here's how to make the journey step by step, realizing benefits at every stage.

More customer value, faster development times, greater responsiveness to market changes, better employee motivation, higher user satisfaction, and lower costs. The lure of benefits like these often motivates IT organizations to investigate agile methodologies, widely believed to be able to deliver such positive outcomes. However, transforming a traditional IT shop to an agile one is rarely easy or quick, and it can be even harder to extend the agile philosophy to functions outside IT to become a truly “agile enterprise.” Our experience shows that many agile initiatives get stuck in implementation, failing to deliver the hoped-for benefits. Why?

Learn more

Explore the Digital Transformation collection

Subscribe to receive related content

This article is featured in Deloitte Review, issue 25

Download the issue

Download the Deloitte Insights and Dow Jones app

One big reason is often the approach to agile transformation. Many leaders adopt a mindset that envisions an orderly transition from one stable state to another, seeking to move the entire IT organization to agile in one fell swoop. However, such an approach rarely yields the desired results. Instead, we have often observed that more-successful agile initiatives break with traditional ways of thinking to begin the journey with selected parts of the IT organization. This alternative mindset accepts a certain degree of instability and uncertainty during the transition to agile, and allows ample time for the IT organization as a whole to adapt (in essence, applying agile principles to the agile transformation process itself). Once agile practices are well-established in portions of IT, they can be expanded to other teams, and eventually to other functions within the broader organization, so that the entire enterprise supports the IT organization’s efforts to operate in an agile manner.

There is no way around the observed fact that a wholesale agile transformation usually takes time. Indeed, it can take up to 10 years to go from a traditional IT organization just getting started with agile to an entire enterprise where agile ways of working are part of the culture. But that is no reason not to start. We envision a four-stage transformation process in which every step along the way can deliver benefits—and where each step can be accelerated by taking certain specific actions (figure 1). Below is our guide to cultivating agility in an organization, from small beginnings in the IT department to its adoption across the entire enterprise.

Four stages in the journey to an agile enterprise

Stage 1: Traditional IT Seeding the agile alternative

At the first stage, the traditional IT level, the predominant operating model follows a “plan-build-run” approach. This model calls for each team within IT to focus on a certain activity that it and it alone performs. The planning team defines the strategy, processes, and governance mechanisms; the build team is responsible for all change initiatives, which are conducted with waterfall methods; and the run team focuses on IT operations. Process frameworks such as ITIL are often used, defining stage gates at which the most promising initiatives are selected and given resources and budget to continue.

To introduce agile methodologies into an environment like this, leaders can identify one or more projects or groups to manage separately from the prevailing plan-build-run model. This may mean implementing agile approaches for a specific project, or it may mean identifying a relatively self-contained group within the IT organization that can adopt agile approaches without extensive detrimental impact on the rest of the organization. The idea is to seed agile within the broader IT organization, creating a nucleus of experience and know-how in agile methodologies that can later be extended to other parts of IT.

Paradoxically, one step toward preparing an IT organization for the journey toward agile can be to establish a structured operating model for a plan-build-run approach. This step can be important for IT organizations where development occurs in an unstructured, ad hoc manner, as it allows IT personnel to become accustomed to following a defined process instead of approaching each project in an idiosyncratic way.

Another important action leaders can take to help accelerate progress out of the traditional IT level is to outsource a number of projects and encourage those vendors to use agile methodologies. The organization can hand over all IT services and initiatives related to the project in an unstructured state. The outside vendor then takes over, structuring the activities and providing services by applying standardized processes, while monitoring agreed metrics and intervening if the metrics fall outside the agreed-upon ranges. By observing the vendor’s actions, the client’s staff can learn how an agile project is managed, sharpening their ability to steer the outsourcing vendor over time.

The experience of a multinational banking corporation shows how a traditional IT organization can begin moving toward agile. Under pressure from new marketplace entrants (such as fintechs) that were often more flexible, had shorter times to market, and offered more comprehensive product suites, the company decided to experiment with agile methodologies to shorten its product development cycle. It had already outsourced most of its IT projects to vendors that followed agile methods, and the positive results from these efforts supported the business case for establishing an agile delivery model in-house.

The company decided to start the transformation in its offshore center in India to keep costs down, targeting IT executives in a specific organizational unit. Cultural differences between workers from the company's headquarters in Germany and those in India presented an initial difficulty, but after both sides reached a common understanding, the change of mindset toward agile principles—as well as the motivation to act differently—took hold. The teams in India learned agile methodologies from the overseas professionals and developed effective ways to manage multicultural teams in an agile context. Currently, the company is expanding agile practices throughout its Indian IT organization with the goal of eventually applying agile methods around the world. As a first step, the organization has refined its project approval and budgeting process so that agile endeavors are being evaluated on the same basis as classical projects.

Stage 2: Bimodal IT Straddling both worlds

An IT department at the bimodal IT level operates in two worlds. At this stage, IT organizations frequently have several initiatives or “digital labs” that use a broad range of agile methodologies and thinking approaches such as Kanban, lean startup, design thinking, and scrum. These digital labs operate as self-contained entities aiming to develop prototypes and minimum viable products outside of the traditional IT environment. Their goal is to deliver innovative solutions that are easy to understand by customers in the business. Meanwhile, the rest of the IT organization continues to operate along plan-build-run lines.

Tension between the digital labs and the remainder of the IT organization is not uncommon at this stage. For one thing, projects started in digital labs are difficult to complete by the classical IT organization, as the timelines for planning and implementation often differ significantly. For another, the classical IT organization tends to be skeptical of the digital labs’ agile project managers, perceiving them as lacking clarity on how to reach the final goal since the agile teams’ minimum viable products are developed in increments. The funding process also differs fundamentally between the digital labs and the rest of IT. While classical projects need up-front funding for the entire project duration, agile digital labs typically compete with each other for budget, with only the most promising developments receiving funding at each project checkpoint.

One way for a bimodal IT department to progress to the next stage more quickly is to require—not just encourage—vendors to apply agile methodologies to outsourced projects. This can deliver benefits on two fronts. First, technology companies frequently have agile resources and know-how on hand, so many vendors are able to start projects very quickly. And second, the client’s IT staff can learn about the procedures and tools of an agile way of working by observing how the vendor acts.

As an example of how digital labs can help an IT organization gain comfort with agile, consider the story of a global insurance company that had created a digital lab to gain experience with agile methodologies. The digital lab had evolved to the point where it was using agile methods to develop standardized insurance products without being technologically or culturally constrained by direction from corporate headquarters. In fact, by having experts from the insurance business work with the software developers, using journey maps to gain a customer-centric perspective, and continuously reprioritizing projects based on the end product’s envisioned value to the customer, the digital labs were able to develop more-relevant products—and get them to market more quickly—than the product development initiatives driven by headquarters.

Some time after the digital lab’s establishment, leaders decided to centralize the provision of IT services for all of the company’s products, hoping to take advantage of synergies with current and previously developed software products to reduce asset development costs. Encouraged by its positive experience with the digital lab, IT embarked on an ambitious agile transformation, establishing multiple cross-functional scrum teams in multiple delivery locations. A strong change management program enabled the scrum teams to spool up on a steady and gradual basis regardless of location.

The company intended to use the scrum teams to not only develop standardized products, but to apply agile methodologies to quickly consider and implement local requirements (for instance, to comply with specific countries’ regulations) into those products. The effort was successful. To date, the scrum teams have been able to produce more than 12 digital assets, which are live in eight countries.

Stage 3: Agile IT Focusing on products, not projects

The third stage, agile IT, is characterized by increased collaboration among groups and a prevailing mindset that focuses on outcomes over predefined outputs and deliverables. Typically, this stage is catalyzed by leaders who have seen the benefits of the digital labs’ agile operations in the bimodal IT phase and now want to extend those benefits to the entire IT organization. Although the biggest shift in this transition is cultural, there is also an organizational impact: Whereas a traditional IT organization organizes by process—putting together teams from multiple groups focused on completing specific tasks—an agile IT organization organizes around the product, integrating all team members into a single group striving to achieve the same outcome. The product they are working on, in essence, becomes the organizational entity to which these workers belong.

Operating as a product organization can enable the formation of stable, self-organizing, cross-functional teams across the IT organization that can be up to 400 percent more efficient than traditional IT project teams.¹Such product teams adopt an agile mindset and culture, and are thereby able to take over further development of any minimum viable products that a digital lab may produce.

Another common strength of a product-focused organization is that, as it becomes more mature, it is increasingly able to use a variety of different frameworks, such as SAFe and DevOps, that focus on different aspects of agility while still maintaining a common agile culture. The impetus for variety typically comes from the realization that a single framework cannot fit all situations equally well, and that teams could be more effective if allowed to pursue their method of choice as long as they commit to following agile values and principles. Hence, teams can use different methods, including scrum, Kanban, or even waterfall, without sacrificing the adaptability and focus on outcomes that are hallmarks of agile. (See figure 2 for a guide to deciding what kind of approach may be preferable in different situations.)

Several factors can help determine whether a traditional or an agile approach is preferable

To accelerate progress to the next stage, organizations can deploy transformation teams organized in communities of practice to share knowledge and lessons learned among the IT organization’s various development teams. The use of a minimum viable design approach, in which the most basic changes are implemented first, can help to reduce the transformation teams’ need to reinvent the wheel for each new group they work with. At the same time, the transformation team should be allowed the freedom to calibrate the speed of agility adoption to each group’s needs. We recommend taking a “minimum viable change” approach in which change progresses by making small, frequent adjustments rather than all at once. This can help the transformation team quickly test its approach with each new group with which it works, and speeds up the delivery of value for the larger organization due to the small but frequent increments of change.

One multinational telecommunications company that had historically relied on classical development approaches for its core systems wished to adopt agile approaches—both within the IT organization and across the broader business—to become more responsive to the marketplace. Since the company’s mission revolves around the technology-enabled dissemination of information, it had the advantages of both an advanced technical infrastructure and a culture that was supportive of innovative business solutions. At this company, the IT organization had reached the point where it was organized around products—but the business was still split into the familiar departmental silos of finance, procurement, marketing, and so on. The company sought to extend the adoption of agile principles across these silos by promoting collaboration between business and IT. Customer journey maps—which depict a customer’s interactions with the organization, along with the related internal processes and information systems, from the customer’s own perspective—and value streams—which show the multiple customer journeys that can lead to a given outcome—were extensively used to drive collaboration. These journey maps allowed personnel in different functions to understand, for the first time, how customers interacted with the organization’s technology at various points in their experience, which helped engage functional representatives in proposing and testing improvements.

Other changes also supported the business’s shift to agile ways of working. From a financial perspective, the company went from project-based funding to an incremental approach that allowed it to provide seed funding for developing minimum viable products. In terms of leadership, executives were coached to accept failure as an option, while remaining cognizant of the need to halt unsuccessful efforts. Finally, from a technology architecture standpoint, the company was able to allow classical methodologies (primarily waterfall) to seamlessly coexist with agile methodologies by eliminating “technical debt” and ensuring that the organization’s long-term vision was reflected in the data model.

Stage 4: The agile enterprise Teaming across functions

The fourth and final stage in the progression to agile is the agile enterprise stage. At this level, all stakeholders work closely with each other to increase the alignment between technology products and customer requirements. To increase collaboration, organizations create end-to-end teams that cut across functions. Further, the concept of the customer has evolved. All parties orient themselves toward serving the end customer—those who buy the company’s products or services—instead of considering the customer to be the internal business units or functions that use IT products.² Endeavors are funded incrementally in stages rather than contractually via a fixed project budget. (In an environment with stage-based funding, a project team must continuously apply for the next round of funding, with approval contingent on delivering the desired results.³ In this way, funding is directed to the most promising intermediate products rather than to a predetermined but possibly suboptimal final deliverable.) From an HR perspective, performance management also reflects an agile way of working, with workers’ performance being measured on multiple agile endeavors rather than against the outcome of a single project.⁴

It can be helpful, to ease the non-IT functions’ transition to agile ways of working, to develop templates or blueprints that give examples of how they can support agile approaches. For example, the finance department can be given an off-the-shelf model for incremental funding. In this way, the functions can more quickly and easily implement the changes they need to adopt to support IT’s use of agile methodologies.

Different stages, different benefits

That it may take years to move through one stage to the next should not necessarily be a cause for concern. Every stage in the journey to an agile enterprise can yield benefits, although the advantages (and limitations) can differ from stage to stage (figure 3).

Every stage of the journey to an agile enterprise has different advantages and limitations

An important point, too, is that many different methodologies can coexist in an agile enterprise—as long as all teams commit to a joint culture based on the agile values and principles defined in the agile manifesto:⁵

Individuals and interactions are preferred over processes and tools
A working solution is preferred over comprehensive documentation
Collaboration between all parties is preferred over contract negotiation
A fast response to change is preferred against following a plan

Becoming agile on an enterprise level is a long journey that, for many organizations, is most feasible to accomplish in a stepwise fashion. Starting the journey toward agility often requires leaders to accept that the IT organization will likely experience some instability and conflict during the first two stages, when pockets of agile activity are still surrounded by traditional development culture and processes. Although each of the steps toward enterprise agility has certain limitations, each also delivers worthwhile benefits. The ultimate payoff: the potential for gaining a competitive edge through agile methods that allow companies to be more responsive to and aligned with customer demands.

Acknowledgments

Endnotes

Topics in this article

Innovation

Deloitte IT Business Management

The Deloitte IT Business Management group has helped multiple organizations become agile by applying a lean approach following agile principles and coaching leaders to help them enable the transformation. Our approach is highly scalable and prevents teams from having to reinvent the wheel, while ensuring that all teams have enough space to inspect and adapt.

Learn more

Get in touch

Andreas Biermann
Enterprise Agility lead, Director
Deloitte Consulting GmbH
abiermann@deloitte.de
+49 40 320804856

DELOITTE INSIGHTS

DELOITTE RESEARCH CENTERS

Welcome!

Latest Insights

Recommendations

About Deloitte Insights

Topics for you