Overcoming executive objections to Agile
Though a bit dated, the content is generally still relevant. The practice mentioned here was commissioned in 2014 and completed in 2015. I would suspect that adoption has only increased in the intervening years…
The first-ever product development success study found that companies that follow agile software development methodologies are far more likely to be successful at developing new software products than their counterparts. Each of the 204 respondents was asked how many of 7 different agile practices they followed. A full 50% of highly successful companies employ 4 or more agile best practices, and 71% employ 3 or more. On the flip side, of those companies that were found to be rarely successful, 41% employ 0 agile practices and 82% employ 0, 1, or 2 agile practices.
These stats beg the question — how can you get executives to buy in to agile when it opens the door to seemingly so much uncertainty? The inability to get buy-in from high-level stakeholders is one of the biggest obstacles to agile adoption in any organization. Executives that either don’t understand agile, don’t want to understand agile, or just can’t get their heads around how a process with so little up front planning can actually produce a sound product will both knowingly and unknowingly put up roadblocks to your agile adoption.
Let’s take a look at a few ways you can address some of their leading concerns about agile and educate them about the process.
Problem #1 When it will be done? How much it will cost? What exactly will we get?
Ah, the lovely triple constraints. This is probably the biggest problem you’ll face when moving over to agile. The thought is that because you’re not planning every last detail up front and locking down all of the constraints, delivering a successful product will be impossible.
Using agile, you will have roadmaps to help define what they’re getting, release plans to loosely outline when they’ll get it, and Velocity x Resources calculations to tell executives how much what you’re building will cost them. However, none of these are an absolute hard number. (Well, okay, cost can be,which means that scope and time will be adjusted to fit accordingly.)
What you can do is assure them that:
1. They’ll get a product that is focused on delivering value to their customer — not bloatware with a bucket full of features that no one needs. And they’ll probably get it sooner than if they’d planned everything up front.
2. Agile favors communication and collaboration over contract negotiation, which means they’ll be as involved as they want to be. They can also rest assured that they will be communicated with regarding what’s going on and provided full transparency into what’s transpiring.
Problem #2: Agile is painted as the golden ticket that will fix all their problems!
I’ve heard it a million times — if you just move to an agile development cycle, we can get this product out faster and cheaper. Which is all well and good until you have to explain to them how agile can do this.
Simply put, agile focuses on delivering value to customers sooner and in smaller increments than waterfall. This allows development teams to get feedback on what they’ve built and adjust or reset expectations. Agile is feedback-driven, ensuring that the product that is delivered is the product that their customer needs — not what their stakeholders think they need.
In the end, this often translates into cheaper and faster (but of course, not always — company culture and executive buy-in is essential!).
The way to combat this “agile will fix everything” mindset is by educating your stakeholders on what agile can and can’t do for them.
Problem #3 But I need my metrics!!
This is another big challenge. Because agile focuses on responding to change and adapting vs. following a set plan, hard and fast metrics are tricky to define and often give a false sense of security (the manifesto states that working software is the primary measure of progress). So, while some of the hard numbers are necessary for budgetary reasons, there are ways to show progress and trajectory without drawn out Gantt charts and exhaustive weekly status reports that go beyond just “working software.”
It all starts with “Sprint 0” activities. There is debate to this practice among the agile community. I personally feel that it is very helpful and absolutely necessary, especially when dealing with larger organizations with PMOs or companies that are new to agile. In Sprint 0 there are two main groups of working going on — the infrastructure stuff (team, testing, tools) and the product stuff (vision definition/communication, release plan creation, definition of your first releasable product, definition of done, etc.).
It is in that product “stuff” that we find our metrics. By doing a high-level roadmap and release plan, we can create a series of “information radiators” that executives can use to gather an idea of where we are at any given time.
With the release plan we can look sprint to sprint and evaluate what we “planned” versus what we actually accomplished. A burn up chart can give you a sense of what percentage of “done” we are. By plotting both a pessimistic line and an ideal line we can see the gap between where we want to stay.
And because we’re reviewing with our stakeholders at the end of every sprint, there are no surprises or secrets as to where we are with things. If scope was added, the radiator will reflect that information.
Another great information radiator is the task board (or the sprint planning boards). Live boards using post-it notes and/or note cards are great ways of disseminating information about progress. For those that aren’t in the same office or with teams that are not co-located, there are a plethora of methods to disseminate the necessary information and achieve a similar level of reporting.
So while you won’t have an exact percentage complete number, you will know where you are in relation to the goal. And if that goal is moved (because we’re always reassessing and adapting), you will see that too.
Problem #4 This all feels so risky!
It’s true that in a waterfall environment, risk is identified up front and addressed often. There are comprehensive risk mitigation plans in place before the project even begins. In agile, you don’t abandon the idea of risk mitigation, nor do you aim to define it all up front. Because agile is adaptive, your risks will change along the way. Instead of heavy change management processes and updates to the risk mitigation plan, however, a risk census is maintained and reviewed at the start of every sprint. Stories are added (like research spikes) to help suss out some of the larger unknowns or to try out an idea that may be more risky.
The movement to an agile development methodology, regardless of the flavor, requires a mindset shift of those involved all the way up through the executives that are demanding these things. Hopefully these points help you approach your executive team and get their buy-in for a move to agile.
