Micro Focus is now part of OpenText. Learn more >

You are here

You are here

Why your execs don't get agile and what you can do about it

Matthew Heusser Managing Consultant, Excelon Development
Board room

At my first major agile transition, senior management was fully supportive, providing training, tools, and consulting. They had a company meeting with everyone to describe this new way of working and how documentation, programming, and team structure would change.

The one strange thing was that project plans, portfolio management, and budgeting needed to stay in place, not to mention HR and finance. Since then, I have heard people say similar things many times, but such announcements about what will remain unchanged are rarely followed by details. Everyone in the group (except, perhaps, a few executives) nods in agreement.

Our executives often spent large amounts of time and money on agile and then compromised the very initiatives they championed. This isn’t just a common problem; it is a nearly universal one, and universal problems tend to have root causes.

Here are the five most common reasons executives don’t get agile—and what you can do about it.


1. Executives see agile as a team-level activity

Consider this scenario: A typical agile “transformation” starts with reorganizing the technical staff into Scrum teams. That eliminates hand-off time between requirements, development, and test, but it doesn’t solve any dependencies with external teams, IT, operations, or HR.

As Mike Cottmeyer recently pointed out at the Agile & Beyond conference, external dependencies mean the team’s velocity is not stable. And without stable velocity, it is impossible to predict when the project will be done.

Cottmeyer says that this is where agile coaches cause problems, suggesting that management should “trust the team.” Trusting the team is fine, but executives have questions this does not answer. For example: When can we start the next project? What should marketing be focused on and when? How much budget do we need to plan for the next thing?

Cottmeyer sees dependencies outside the team as the obstacle. He suggests the way for companies to adopt, or “get agile,” is to eliminate, work around, or negotiate service agreements to make the functional teams predictable. Scrum and XP do not address these issues, yet I have seen these problems in every organization that has three or more Scrum teams.

In many cases, dependencies between teams turns out to be the primary bottleneck. If it remains the bottleneck, agile methods won't help, and executives will continue to not see the benefits they had hoped for, while continuing to ask the wrong questions.

2. Executives receive agile training at the wrong level

Recently a colleague of mine took a two-day course alongside the senior executives of a very profitable company. The course was called "Agile for Executives," but it turned out to be mostly a course in Scrum—teaching about sprints, standups, stories, and self-organizing teams. After the class, his executives had a good idea of how “those” people should be “doing” software, but no real tools to manage dependencies or deal with the portfolio or budget.

Most executives are too busy to go to two days of agile training, and learning Scrum is not helpful to them anyway. Even a software library isn’t much help; most books on agile management are a collection of methods to be applied at the team level. Websites on how executives need to change are full of well-meaning advice, such as “explore and adapt” or “learn fast,” but this kind of advice doesn’t tell the executives how to actually manage projects for a large organization.

Eric Willeke, an adviser for enterprise agility at CA Technologies, points out that most team- and program-level agile coaches have not been faced with the decisions that executives are routinely asked to make. And the fact that they do not have the experience necessary means they are not prepared to create the training that executives need.

3. Waterfall hides inefficiencies from executives

When waterfall was common, organizations would try to pursue two dozen initiatives, sometimes more, at the same time. Maybe the top eight were high-priority, the next eight middling, and the last eight low-priority. Dates would be invented based on past experience and public commitments, and the PMO would create virtual teams to get things done.

The good thing about this idea is that if things are late, the teams will simply multitask and focus on the few things rated top priorities. This avoids the consequences of Brook's Law (that adding people to a late project makes it later), because teams are simply increasing time-slice, or a percentage of existing people are allocated to the project—that is, you're not bringing on "new" people.

As a result, some companies using waterfall were able to avoid some of the pain that results from late projects. Of course, the things rated as lower priorities were very late or canceled, but they were low-priority anyway. The organization got what it said it needed, at around the time it was planned for. Of course, all the well-known hidden inefficiencies of waterfall were still there: Things take too long, and there are hand-offs, dependencies, and rework. But to leadership, that mattered less, because the project was done.

A completed project is a pretty decent pressure-relief valve, which the organization loses when it moves to agile development and limits work in progress. Why? Because when teams are dedicated to one project, there is no percentage of time to steal from them, no way to shift things around to make up for a loss. As a result, management has one less lever for steering toward a deadline.

Of course, things were always hard to steer, but some organizations were able to hide that with waterfall. Management that lacks those things will find that the "tools" available for waterfall are gone with agile software development. If the organization is blocked by dependencies outside the team and velocity is not stable, delivery may continue to be late.

To a line-of-business executive in a company such as this, things look as if they got worse when agile was adopted, not better.

4. Leaders over-focus on one aspect

DevOps is incredibly appealing and popular for many reasons. Executives naturally want it, but some believe DevOps is something you can buy and install. If you get modern version control and add some continuous integration, automated tests, and push-button deploy, you suddenly have a committed-to-deployed pipeline that runs in minutes, not months.

All that may be true, and the tools are very powerful, but nurturing an effective organization takes a lot more than buying a toolset or thinking you need to "install" something. When Scotiabank started an agile experiment, it found seven layers of signoff to get a change into production. The consulting company that started the process simply hired extra people to get the signoffs in parallel to the development work, which drove up results, but also drove up billings to the consulting company. Dave Dame and Aaron Sampson, who worked on that project, suggest a different tactic: re-engineer the process, so that the controls are appropriate for the (now reduced) risk.

However, you can't reduce risk if the only thing executives are interested in is a status update on continuous delivery and the only obstacle listed is "Docker-izing the server farm."

A complete agile-conversion will include changes to organizational structure, technical craft/skill building, process, culture, product management, procurement, contracting policies, and, yes, even HR. Focusing on just one of those, or even just a couple, can lead to building the wrong thing, including a pipeline that has far too many delays, hand-offs, and a whole host of other problems.

5. Multiple, conflicting goals at the leadership level 

People adopt an agile approach for a reason: to get some desired result. CA Technologies' Willeke is quick to point out that “agility without purpose is pointless.” Agile adoption, he suggests, can tie back to business outcomes with improved time to market, decreased costs, better customer service, better product/customer fit, and higher quality. But if the goal or the “why” is not clear, then the “what”  and the “how” will be confused. The “what” might end up not being what the executives thought they were getting.

Getting to a single goal for an agile conversion might be hard, and in fact, you shouldn't have to: After all, the executives have been promised all of the benefits listed above (see point #1).  But, still, anything can happen.

How to fix it

Once something is broken, it may not be too late for a fix. But it’s definitely harder to fix a broken thing than to prevent breakage in the first place. In a large organization, the conversations will keep coming back to the errors outlined above. If you find yourself with these root causes (unstable velocity, no time for executive training, statements such as “we never had these problems before,” focusing on only one aspect of agile dev, etc.), that's a good sign that confusion exists at the executive level on what agile is and how to get there.

You can’t overcome this by talking over the water cooler about how your executives don’t "get" it. And facing the issue head on—for instance, correcting people in meetings—is a good way to get shunted aside.

Instead, find the worst root-cause problem and try to address it. If it is training, get the information in. If the problem is alignment, ask clarifying questions to bring the lack of alignment to the table. If your prior waterfall methods hid problems that now emerge with the openness of agile methods, then gather that historical data and solve the predictability problem.

Think of the problem of executives not "getting" it as a bottleneck problem. Don't complain about it. Find ways to increase your capacity.

Keep learning

Read more articles about: App Dev & TestingAgile