Best Practices for Adopting an Enterprise Agile Framework

Published: 23 January 2017 ID: G00278351



CIOs are aggressively building their enterprise agile capabilities often choosing to bootstrap enterprise agile by the use of a framework. All too often, however, they are used as drunken man relies on a lamp post: for support rather than illumination.


Key Challenges

  • CIOs and their application leaders are under increasing pressure to increase feature delivery while maintaining quality.

  • CIOs need to accelerate both the breadth and depth of agile adoption within their organizations, but must align to business needs.

  • CIOs do not have the time or skills to develop an end-to-end agile capability by themselves.


CIOs involved with strategy and governance should:

  • Understand that enterprise agile culture has to be earned — you can't simply buy it.

  • Define a specific business reason to adopt an enterprise agile framework linked to business opportunities and outcomes.

  • Delegate responsibility for framework adoption to a trusted team.

  • Build upon a framework rather than using it as a rigid standard that needs to be followed to the letter.

  • Avoid letting agile framework adoption lead you down the path of bureaucracy.


CIOs are under pressure to be more responsive to the needs of the business, not only in terms of what they deliver, but how they deliver it. This should come as no surprise as there has always been pressure on IT to deliver more. Higher productivity and greater agility are daily mantras for IT management. Nevertheless, we must acknowledge that there is a multidimensional change taking place, driven by the digital economy, which is forcing both the CIO and CEO to rethink the role of IT and its relationship to business outcomes and customers.

Figure 1. Multidimensional Change
Research image courtesy of Gartner, Inc.

Source: Gartner (January 2017)

If we look at any organization, public or commercial, there are two things we can guarantee about its business capabilities. Firstly, related products and services will be increasingly digital. Secondly, business capabilities will have to operate in a more dynamic environment driven by regional and global economics, regulatory mandates and increasingly demanding, technology-savvy customers.

To deal with these situations, CIOs are accelerating their agile adoption plans both in breadth and depth:

  • Breadth by looking to scale agile development to more teams and to larger programs and by extending into DevOps and web-scale IT.

  • Depth by applying agile principles end to end from strategy to delivery, including flexible funding, evolutionary architecture and adaptive portfolio management (see "How to Create an Agile Pyramid to Achieve Enterprise Agile Delivery of Business Capabilities" ).

Enterprise agile acceleration options are limited. Either CIOs can aggressively build their own enterprise using best-of-breed practices and integrating them across the organization, or they can bootstrap enterprise agile by the use of a framework (see "Market Guide for Enterprise Agile Frameworks" ).

The first option has the advantage of permitting the "cherry picking" of practices that are suitable for IT and business needs. However, the down side must be considered: They have to be the right practices, and the CIO must make sure they work together end to end to support the business.

The second option — using an enterprise agile framework — has the advantage of prepackaged roles, principles and practices, but these have to be implemented correctly, and the organization must still change its business and IT culture to enable agility.

Increasingly, Gartner is seeing clients turning to the second option, frameworks, as the solution to their agile scaling problem.

There are three main reasons for this trend:

  1. Awareness: CIOs and their application leaders are more familiar with enterprise agile frameworks.

  2. Urgency: Organizations do not have the time or skills to scale agile unaided.

  3. Risk: Frameworks are perceived as helping to mitigate the risks of scaling agile.

Used correctly, these frameworks can be an effective scaling mechanism. All too often, however, they are used as drunken man relies on a lamp post — for support rather than illumination. CIOs and their application leaders need a plan of adoption that considers the cultural and leadership aspect of framework implementation and, most importantly, how it impacts value delivery to the business.


All enterprise agile frameworks have a shared heritage in Scrum, kanban, extreme programming (also known as XP) and, to some extent, DevOps. Lean principles and system-based thinking underlie the scaling mechanisms here, and all such frameworks promote flattened management structures with autonomous product- or feature-aligned teams, supported by communities of practice.

Each framework tackles the issues of the enterprise in its own way, with its individual "secret sauce." Nevertheless, we would expect a framework to support the eight core enterprise agile principles seen in "Best Practices for Implementing Enterprise Agile Principles."

Enterprise Agile Culture Has to Be Earned — You Can't Simply Buy It

Agile is as much about culture and core values as it is about principles and practices. Adopting a framework does not automatically change the culture and values that allow enterprise agile to flourish. It's the difference between simply going on a diet to lose weight, and completely changing your lifestyle. The former may be quick and show results in the short term, but the latter takes considerably more commitment and gives greater all-round benefit.

If the strategy is to adopt a framework to drive agile across the enterprise, and use it strategically with the business, we need to be clear on the "cultural gap" that may exist within IT, and between business and IT. As such, you should ask the following questions:

  • Is the business clear not only on the benefit of agile, but on what has to be done to make it successful? This includes implementing product management, being open to new funding and prioritization methods (and not pandering to whoever shouts the loudest), strong collaboration between business and IT, and remaining open to change.

  • Is senior IT management ready for the greater autonomy of the agile teams? Have they moved away from command and control management to a more "servant-leader" model of management?

  • Is senior IT management willing to incentivize openness, trust and collaboration?

Enterprise agile requires change agents at all levels of the organization, IT and business, who understand the cultural implications of moving to enterprise agile. These "sneezers" (if one person with a cold sneezes, everyone gets it) are individuals trusted by their peers and often outside the normal chain of command. You must train them on the framework, and then put them in a position where they can affect the real cultural change (see "The Cultural Transition to Agile Methods: From 'Me' to 'We'" ).

Senior leaders from both business and IT units will need to create a common and consistent message around the move to enterprise agile, and they must actively support it. They must communicate their vision of what an enterprise agile capability is, and what it means to the organization. Above all, they must understand completely that such change takes time, which may feel uncomfortable, but it's worth it.

Senior management needs to learn the "gemba walk" (gemba is Japanese for "the real place"), by actually observing what's happening at a team level, showing an interest in the Scrum or kanban boards, and showing they understand and support the approach. This "go see" approach will have a positive effect on morale and helps encourage best practices.

Enterprise agile requires transparency and a simple set of metrics to help show and sustain cultural change. Examples of this would be a company survey every six months that asks about culture; team retrospectives asking about autonomy, trust and collaboration; and "information radiators" that measure issue resolution times and business "idea to implementation" lead times (a good indicator of collaboration).

Do not fall into the trap of bringing in an army of consultants and expecting to have an agile enterprise when the dust settles.

In the same way a doctor cannot lose weight for you, no consultancy has ever changed a single person's values or an organization's culture. The person has to choose to change, which ripples out across the culture. The consultant can only guide. So create an environment that encourages change, and in which your staff feel it's safe to change. This will lead to a culture where there's no blame, where it's OK to fail — as long as you learn — and where perfection is never expected on day one.

Define a Specific Business Reason to Adopt an Agile Framework

Adopting an enterprise agile framework takes a considerable commitment from senior business and IT leaders, and impacts all levels of the organization. Therefore, it is critical that there is a clear and specific business reason for wanting an enterprise agile delivery capability.

In our experience, those clients that have been most successful using an enterprise agile framework have done so because adoption was seen as a prerequisite to a strategic business initiative or critical business program.

This is not to say that using more-general arguments for adoption — like wishing to scale agile and Mode 2 capabilities, or replacing waterfall with a Mode 1 renovation initiative — cannot be successful. But it has been our experience that this tends to take longer, and it is harder to convince the business and senior stakeholders to make the necessary process, organizational and cultural changes.

Considering a business-specific need can also help with framework selection. If the program or product needs multiple agile/DevOps teams, and a change to program and even portfolio management, you might consider a Scaled Agile Framework (SAFe) or disciplined agile delivery (DAD). If, on the other hand, the business challenge requires multiple teams, but there is no need to change program and portfolio management (PPM) practices, or if you prefer not to use the framework guidelines to address these areas, then Large-Scale Scrum (LeSS) or Scaled Professional Scrum (Nexus) might be more suitable.

When formulating a proposal for framework adoption, it is wise to start by identifying a business initiative (ideally customer facing) that requires moving beyond what the organization has already done with Scrum or kanban. You should show how the framework reduces the risk of using agile on larger and more-complex programs, but do not oversell it — it is not a magic bullet. Be clear on what the framework will address, and what it will not. And remember that cultural change is still required.

Link the benefits of the framework to the specific business outcomes of the initiative. Start with general benefits of delivering the desired outcome sooner, and the net present value effect on the business, including improved insights (fiscal, customer and risk). For more specific benefits, link the framework to critical success factors of the program or product. For example, how it will help coordinate the feature teams or a release train across a customer journey (process) critical to the desired outcomes.

It is not enough to simply say it gives us faster and more-agile delivery; you need to be able to express value in the context of business capabilities and related business outcomes. For example, how the framework will improve average revenue per user, or lower the cost of customer acquisition. By making the benefits case more specific, it is easier to elicit business buy-in.

Delegate Responsibility for Framework Adoption to a Trusted Team

CIOs are the ultimate "master-servant." They wield power and influence — the former is needed to make the necessary organization and process changes, and the latter is needed to convince business leaders and to embrace agile methods.

However, there needs to be a clear vision of the transformed organization, the end-to-end value streams, the governance structure and, most importantly, the collaborative relationship between the business unit and IT. This vision must be in the context of business benefit. Don't sell the framework — sell the outcomes and impact on evolving capabilities.

Because the CIO does not have time to deal with the day-to-day implementation of an enterprise framework, it is essential to select an implementation team that can be trusted and that will share the CIO's vision. The CIO must delegate — not abdicate — responsibility. Ultimately, the CIO is accountable for the agile transformation.

As shown in Figure 2, you should agree in advance on a small set of millstones and KPIs (current and leading indicators), for example, adoption levels (number of teams and staff trained), culture change (supporting communities of practice team autonomy and business engagement) and business (improved business outcomes and lead times). Include KPIs and milestones that may not directly relate to the framework, but are critical for overall success (changes to funding, HR practices and regulatory requirements).

Figure 2. Sample KPIs for Enterprise Agile
Research image courtesy of Gartner, Inc.

Source: Gartner (January 2017)

Have clear communication of the vision for all levels of IT and impacted business, and frame the vision not just in terms of benefits the organization will reap, but also benefits to the individual. Anticipate the uncertainty individuals in both IT and the business will feel. The CIO needs to communicate a business vision. The CIO and senior management team must use their positions to remove impediments to success and influence the business to engage.

Build Upon Frameworks Rather Than Treating Them as a Rigid Standard

Some organizations adopting enterprise frameworks are treating them like sacred texts. They are trying to implement them exactly as the framework, book or consultant recommends. We must be clear that frameworks are created to be built upon, and they are not the finished article. Whether it's DA, LeSS, Nexus, or SAFe, or some other framework you decide upon as a foundation, your specific implementation must eventually reflect your organization's own culture, values and distinctiveness. It must be infused with your own agile DNA, and become unique.

Frameworks are not standards or regulations you need to follow to the letter, but that should not be an excuse to neglect key practices, process and roles recommended by the framework. Be clear about why you are modifying the framework. That said, if the framework recommends a role you already have under a different name, it is OK to keep the existing name. If you have a funding model that works for your organization and that will support enterprise agile, then keep it and combine it with the framework. The most important thing is to make the framework your own.

Some frameworks are versioned, and this has led to some people thinking "We must do exactly as the framework says so we can migrate in the future to the new version." This is an example of the framework becoming an end in itself, rather than the means of achieving a business outcome, losing sight of why the organization was adopting the framework in the first place. When a new version of a framework is released, do not feel duty bound to move to it. Assess its benefits, and if there are genuinely useful new practices that will add value to your organization, then consider adopting them. If the new version has made major changes to the framework that would require considerable reworking of your current implementation, then only move if it fixes a major deficiency in your current implementation.

Accept there will come a point when, if the organization has made the framework its own and unique, it will no longer have a simple migration path to new versions of the framework, and that is ok.

Don't Let Agile Framework Adoption Lead You Down the Path of Bureaucracy

There is a risk with any framework that it becomes bureaucratic and detracts from overall agility. In particular, there are two scenarios we should be mindful of.

First, the framework can suffer from "bloat" in the form of too many roles, activities or touchpoints. It's an axiom with frameworks that it is easier to add than to take away. As Mark Twain said, "I didn't have time to write a short letter, so I wrote a long one instead." As a given framework becomes more popular, the list of possible enhancements grows longer with tool vendors, consultancies, and the wider agile community all chipping in. It is often difficult, even for a proprietary framework, to maintain balance and remain agile.

The second, and more common scenario, is over-engineering the implementation of the framework. Often this is a symptom of the implementation not fully embracing the framework practices or, accidentally — and sometimes deliberately — misinterpreting them. If the necessary cultural changes have not been made, then framework will be "wrapped" in pointless documentation, nonagile metrics and bureaucracy.

A variation on initial over-engineering is the potential for creeping bureaucracy. The organization's implementation of a framework starts out lean and agile but, as the organization scales up agile, extra practices and documentation creep in, often to accommodate business units and other functions (like the program management office, enterprise architects, regulatory bodies or operations) that do not want to change their existing culture or engrained practices.

The golden rule with frameworks, agile or otherwise, is to pose this question: Does the implementation of a practice, role or artifact have direct business value? Otherwise, it is "muda" (Japanese for futility or wastefulness) in lean terms. If you extend the framework, are you doing so to add agility (which is right and proper) or is it just a way of avoiding real change and keeping the status quo?