The most important piece of the puzzle when scaling Agile development processes is the cultural change required across the organization. Scaling Agile successfully means everyone’s mindset has to change – from developers through to executive leadership. Unfortunately, old habits die hard. Unless there is an exceptionally good reason to adopt change, it is often met with resistance. To get past this, the enterprise must reach its ‘tipping point’—the point at which the rationale for a significant change becomes overwhelmingly obvious.
More specifically, you need to get executive buy-in from high-level stakeholders, including VPs, senior directors, and other leaders. These people are needed to sponsor the change and support its execution. Senior leaders establish vision, lead the change, and remove obstacles that are encountered during an Agile transformation. Unfortunately, the inability to get executive buy-in from high-level stakeholders is one of the biggest obstacles to scaling Agile development processes in any organization.
Executives that either don’t understand Agile or don’t want to understand Agile, often put up roadblocks to Agile adoption. In this scenario, rather than “pitching” Agile to resistant executives, focus on the objectives of the business and how you can help management achieve their goals or alleviate their pains.
Let’s take a look at some of your executives’ leading concerns about scaling Agile development, how to educate them about the process, and then secure their buy-in.
Concern #1: With Agile, when will the product be done? How much will it cost? What exactly will we get?
These are probably the biggest questions you’ll face when moving over to an Agile development process. The fear 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.
Because Agile focuses on delivering value sooner and in smaller increments than waterfall, development teams can get feedback on what they’ve built and adjust or reset expectations as necessary. This is one of the main benefits of Agile development, but also makes it more difficult to definitively answer questions around timing and cost to executives upfront.
Using Agile, you will have roadmaps to define the product, release plans to loosely outline when executives will receive it, and Velocity x Resources calculations to tell them how much what you’re building will cost. 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 to address concerns about an Agile development process is assure your executives that:
- They’ll get a product that is focused on delivering value to customers – not ‘bloatware’ with an abundance of features that no one needs. And they’ll probably get it sooner than if they’d planned everything up front.
- Agile favors communication and collaboration over contract negotiation, which means executives will be as involved as they want to be. They can rest assured that communication is a cornerstone of Agile and that transparency is critical for success.
Concern #2: Agile is painted as the “golden ticket” that will fix all their problems
They’ve likely 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 customers need – not what their stakeholders think they need. In the end, this often translates into cheaper and faster delivery, but of course, not always.
The best way to combat this “agile will fix everything” mindset when looking for executive buy-in is by educating your stakeholders on what Agile can and can’t do for them. While it’s nice to present a perfect picture of an idea you’re enthusiastic about, it’s also important to acknowledge the weaknesses. Nothing is bulletproof, there is never a one-size-fits-all solution that will fix everyone’s pain and make lives perfect. The same is true with Agile; although it does improve the management of complex projects, it does not fix everything. Difficult situations and trade-offs will still exist, no matter the approach.
Concern #3: But I need my metrics!
Because Agile focuses on responding to change and adapting vs. following a set plan, hard and fast metrics are tricky to define and offer more of a false sense of security (the manifesto states that working software is the primary measure of progress). So, while some 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.”
Start with “Sprint 0” activities, where there are two main areas of work going on – the infrastructure work (team, testing, tools) and the product work (vision definition/communication, release plan creation, definition of your first releasable product, definition of done, etc.). It’s in this product work that you’ll find your metrics. By creating a high-level roadmap and release plan, you can create a series of “information radiators” that executives can use to gather an idea of where you are at any given time.
With the release plan, you can look sprint to sprint and evaluate what you “planned” versus what you actually accomplished. A burn-up chart can give you a sense of what percentage of “done” you are. By plotting both a pessimistic line and an ideal line, you can see the gap between where you want to stay.
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 in Agile development you’ll always be reassessing and adapting), you will see that too.
Concern #4: This all feels very 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 software development, 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 should be maintained and reviewed at the start of every sprint.
Also, Agile planning solutions like Blueprint’s Storyteller, help organizations reduce the risk of responding to rapidly changing requirements by automatically tracing relationships between artifacts, and viewing these relationships through an Impact Analysis. Automating traceability promotes ongoing feedback, enabling stakeholders to easily manage changes and risks as they occur.
Quelling your executives’ fears about risk starts with addressing project risk, but ultimately ties into something bigger and more challenging to overcome – personal risk. Often times “the issue isn’t the issue.” All problems are people problems, so focus on the person and what their objections or concerns are. It’s likely that the decision for this person is not entirely about facts, but about fear, uncertainty, and doubt. Also, keep in mind a few personal aspects of the individuals you’re trying to get executive buy-in from:
First, you have to make this Agile transformation a win for them personally. They have to believe at some level that you’re looking out for them personally. This builds trust, and that trust will give you the political capital to get things going and get things done.
So, if they have their neck on the line, you should present Agile as a great risk-mitigation method. Or if they need some wins with key management/peers in your company, present it as the best way to get game-changing features out, and out sooner. If getting stung by poor quality is the issue, take the approach of quality built-in upfront.
Second, don’t forget that your executives have personalities and strengths that incline them to interact with the world in a certain way, and this should influence the way you share information with them in your drive to get them on board with your Agile transformation.
If they are “me” centered, it helps to present information/options/decisions in a succinct way that allows them to make the decision.
If they are “we” types, present it as a something that the whole team (whatever he/she sees as team – project, department, etc) will benefit from and be a part of/involved in.
If they are “pace” types, you’ll have to deliver the information and decision points around Agile clearly and gradually over time. Be willing to invest in being patient, consistent and clear in your message.
And if they are a “process” type, present the information more as a clean system and process approach, not some foggy, no-documentation devs-gone-wild idea that they might have heard before. Give them the white papers and research from Forrester, Gartner, and other respected companies – and offer to send them any additional information they might need to make a decision.
The movement towards an Agile development methodology, or scaling Agile from one team to the enterprise, takes years and requires a mindset shift of all those involved, from developers all the way up to executives.
We suggest approaching conversations aimed at securing executive buy-in from the position that Agile adoption in itself is not the goal. The goal is for your organization to achieve high performance – to build high-performing teams and deliver high-performing products and applications that meet your customers wants and needs.
Hopefully these points will arm you with the information and messaging you need to approach your executive team and get their buy-in towards implementing and/or scaling Agile development processes at your organization. If so, you’ll be well on your way towards transforming how your organization delivers value through technology.
If you’d like to learn more best practices for scaling your Agile development processes, download a copy of our eBook, The Complete Guide to Scaling Agile Software Development by clicking below.