If the leading business literature from the past couple of years is to be believed, leanness and agility have become must-have characteristics of any company that expects to thrive. Yet, lack of executive support is consistently reported to be a primary reason that enterprise agile transformations are unsuccessful.

How can this be? If agility is essential to an organization’s business success, how can executive-level support of the adoption of agility throughout the enterprise not be a top priority?

As perplexing as that is, here are some things we do know:

Just the Facts

  • Executives have limited time to take on more.
    More than 60% of the executives surveyed by the Standish Group reported that they spend less than 5% of their time on executive sponsor responsibilities related to the projects that they already own.
  • Executives aren’t focused on the same things that most agile practitioners talk about.
    When is the last time you heard your CEO talk about ATDD, story point normalization, or team empowerment?
  • Executives are accountable for business outcomes.
    Growth, profitability, cost containment, and business strategy development rank high on the list of things that keep CxOs awake at night.

Missed Opportunities

The struggle these days usually isn’t in convincing executives of the general benefits of agile. By now, they’ve at least heard about it or read about it. The challenge lies in connecting agile values, principles, and practices to their needs in a compelling-enough way to convince them that leading fundamental change in the way their organization thinks about and goes about its business will be worth the effort.

Most agile champions and practitioners have limited opportunities to influence executive leadership. And when the right circumstances have presented themselves, we typically haven’t done a very good job of advocating agile as a means of achieving business outcomes. In order to gain enthusiastic executive support, we’re going to have to maximize our opportunities by effectively talking about agile in the context of their needs and responsibilities. They won’t be into agile unless there’s something in agile for them.

Reframing the Discussion

You can use the three-component approach below to help you talk about agility more effectively at the executive level. This can close the perceived gaps between agile’s capabilities and the challenges that executives are focused on. The three components are:

  • Message (a relevant statement of the challenge): says “I understand your needs”
  • Methods (what we can do to meet the challenge): says “I can help you”
  • Measures (how we’ll know that what we’re doing is working): says “I can prove it”

Here’s a familiar example from the bottom-up perspective (you can probably already do this one in your sleep):

lees-post-e1436377133612Message: “I understand that you’re frustrated at how we consistently plan more than we can do, which leads to unrealistic expectations and missed deliverable dates.”

Methods: “Why don’t we limit our commitment to how much we’re really getting done? That way, we can set realistic expectations as to how much we can deliver within a given time frame, at a given level of quality.”

Measures: “We can use the observed velocity trend to determine how much we can commit to. We’ll continuously update that trend, and investigate the causes of any negative trending.”

That’s just an introduction to velocity-based planning, and applicable to somebody directly involved with planning and delivering software. But in order to get the attention of executive leaders, we have to communicate in terms that really impact their world.

The skeleton of that discussion looks like this:

Message: “I understand that we are facing [higher-level business challenge]…”

Methods: “[these agile practices] can help. Here’s how it typically works [no agile jargon – use their language]. Here’s an example: [quick example of what ‘xyz company’ did]”

Measures: “These are the simple metrics we can track to know that it’s working…”

Here’s a fleshed out example:

Message: “I understand that we are facing increasing costs of developing our software, and that this is impacting our overall profitability. A significant factor in this is the amount of test and re-work churn we have during the development cycle.”

Methods: “Test-driven development and continuous integration can help reduce that expensive churn. The development teams continuously build and test small changes in a version of the finished product, allowing them to immediately catch and correct anything that isn’t working the way it should. That eliminates long, expensive integration and test phases. XYZ Company adopted these practices and reduced their overall cost of developing software, while gaining higher quality, and increased sales. And they achieved that without having to hire additional people.”

Measures: “In order to verify that our efforts are working, we can measure the trend in feature cycle time – how long is it taking us to get features completed and delivered to our customers? We can also track the trend of how many defects we are releasing to our customers. Both trends should go down.”


Now I realize that some might see this as a myopic approach, too focused on a particular set of practices and not focused enough on the values and principles behind them. Remember, though, that if questions are asked, there’s nothing preventing me from, say, further explaining the impact of these practices on throughput and how that affects both the revenue and cost components of the ROI equation. What I’m trying to accomplish here is simply flip the light switch on. We can talk about voltage, current, resistance, and luminosity later.

Of course, the flawless execution of this technique won’t guarantee that the executives in your organization will become agile fanatics. But they certainly won’t embrace agile if they don’t perceive it as a means of meeting their business challenges.
The point here is to be prepared with the right message, and with the methods and measures to back it up, when the opportunity to influence your executive leadership presents itself. Give it a try, and let me know how it goes!


Join the Discussion

    • Peter Jetter

      In general, i agree. It depends. If value delivery is still dominantly limited by things within the given sphere of influence, your model works. While CD is viable in SaaS environments, many on-premises delivery models do not have the sinking capacity at the customer side to match your CD output capacity. That requires organisational development at the customer side, on which you have typically very little influence.
      Another aspect: Customer involvement is easy, if you have a single customer or a homogeneous market. Yet, mature markets are often characterized by diversification – all the common needs are already delivered commodities. That makes the PO job difficult and the value delivery less tangible (for CxO eyes).
      Additionally coaches are often involved in Agile Transformations, that got stuck, because it requires changes outside the Scrum Teams sphere of influence. These changes require upfront investments to remove some organisational dysfunctions (pay back organisational debts!) . CxOs probably don´t like to hear, that they accumulated organisational debt (transparency means also to see the ugly and the bad!) and the business case for change is not bullet-proof enough for them. In non-agile minds there are no unknown unkowns and certainty and reliability can be achieved, if you just put enough effort upfront. IME the concept of Emergence does not exist in many Engineering or Controller minds. Complex just means “more complicated” to them. There is no such thing as “irreducible”. To them the world consist mainly of linear relationships and clear means-ends mappings (and no such thing as super-summative net effects). Bringing different Dynamic System Thinking to C-level, which invalidates many of their paradigms and believes, is difficult and takes longer than the time span, which they tolerate to wait for desired outcomes ($). C-level usually believes “trust is good, control is better”. It is mainly luck(statistical probabilities), whether you can deliver a sufficiently long sequence of ” minimum viable improvements” before a “failure” will occur (heuristics! experiments!). Then it depends whether you accumulated enough trust to have enough left to be allowed to continue.

      In short:
      IME the established organisation achieved the levels of self-sufficiency, self-maintenance and resilience to internal disturbances, that agile tries to achieve for external perturbations.

      (Many human brains tend to prefer certain pain over uncertain wellbeing. ->Kotters Sense of Urgency)

    + 40 = 47