- Use Cases
The most important (and often most difficult) piece of the puzzle when scaling Agile is the cultural change required across the organization. Unfortunately, getting executive buy-in and making sure that all teams are on board is easier said than done.
Unless there is an exceptionally good reason to adopt change, it is often met with resistance. In fact, you’ll often hear phrases like, “that’s the way we’ve always done it around here,” or “that won’t work here” from people who may not initially see the value in Agile methodologies. To get past this, the enterprise must reach its ‘tipping point’—the point at which the rationale for a significant change becomes overwhelmingly obvious.
1. Identify and Educate Lean-Agile Change Agents – They provide the knowledge and horsepower needed to implement specific process changes within your teams.
2. Get Buy-in from Executives, Managers, and other leaders – They sponsor the changes and support the implementation by setting the vision, showing the way, and removing any impediments.
Scaling Agile across the enterprise requires new training for every individual who influences the development of digital products. To make this practical and cost-effective, Lean-Agile Change Agents and a “train the trainer” fan-out model can be used.
Your Lean-Agile Change Agents are responsible for the successful adoption of scaled Agile across your organization and the results it delivers. Sourced internally and externally, these Change Agents may come from many roles, including trusted consulting partners, internal business and technology leaders, portfolio/program/project managers, architects, analysts, and process leads.
Their role is to empower and help teams build better systems by first learning and then exhibiting, teaching, and coaching Lean-Agile principles and practices to others within the organization’s Agile teams. This provides an affordable training strategy and provisions teams with the information needed to initiate and implement change.
Change Agents can ignite change within an enterprise, but they aren’t a sufficiently powerful force for guiding an Agile transformation on their own. For that, other stakeholders and senior executives must step in, step up, and help lead the change.
To effectively implement Agile at scale, and to provide the inspiration for relentless improvement, the enterprise’s executive leaders must:
1. Lead the change – Exhibit and express the urgency and need for change, and build a plan for successful change. Then, understand and manage the change process, addressing problems as they arise.
2. Know the way; emphasize lifelong learning – Create an environment that promotes continuous learning. Strive to learn and understand new developments in Lean, Agile, and contemporary management practices.
3. Develop people – Employ a leadership style that focuses on developing skills and career paths for team members rather than on being a technical expert or coordinator of tasks.
4. Inspire and align teams with the mission; minimize constraints – Provide the mission and vision with the minimum specific work requirements. Eliminate demotivating policies and procedures. Organize teams around Value Streams.
5. Decentralize decision-making – Take responsibility for making and communicating strategic decisions—those that are infrequent, long-lasting, and have significant economies of scale. Decentralize all other decisions.
6. Unlock the intrinsic motivation of knowledge workers – Provide purpose and autonomy. Help workers to continually master new skills.
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 and how you can educate them about the process and benefits to secure their buy-in.
We suggest approaching conversations 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’ expectations and needs.
These are likely the biggest questions you’ll face when moving 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 about 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 is an absolute hard number, which is typically what executives are looking for.
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 then adjust or reset expectations. Agile is feedback-driven, ensuring that the product that is delivered is the product that the customer needs – 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 potential 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.
Because Agile development focuses on responding to change and adapting instead of following a set plan, hard and fast metrics are tricky to define and can offer a false sense of security (the Agile 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.
Start by looking at “Sprint 0” activities, where there are two main areas of work going on – the infrastructure work (establishing 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.
Additionally, by creating a release plan you can evaluate and compare what you planned to accomplish versus what you actually accomplished sprint to sprint. A burn-down 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 establish the metrics that you want to ensure you stay within.
So, while you won’t have an exact percentage of how complete your product is, 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.
In a waterfall environment, risk is identified up front, addressed often, and there are typically comprehensive risk mitigation plans in place before the project even begins. However, because Agile software development is adaptive, organizations do not define all risks up front because they know that their risks will change along the way. At the same time, they don’t abandon the idea of risk mitigation altogether. Instead of heavy change management processes and updates to the risk mitigation plan, 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 is not entirely about facts for this person, but about fear, uncertainty, and doubt.
First, you have to make this Agile transformation a win for them personally, and 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 quickly and get things done.
So, if they have their neck on the line, you should present Agile as a great risk-mitigation method.
If they need to achieve 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 reminding them that in Agile development quality is 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. 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 feel like they’re able to personally assess the situation and 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 or 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 – nurturing them through the decision-making process until they come around.
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 Blueprint Resources page is a great place to find white papers, videos, reports, and other helpful Agile development assets that can help you secure executive buy-in.
You can also download our Complete Guide to Scaling Agile Software Development to access a PDF copy of our step-by-step guide for scaling Agile to the enterprise.