What’s the Real ROI of Agile?
By: Rebecca Holland, Myron Parks, SAFe 5, CSM®, CSPO®, ICP-ENT, ICP-CAT and Sheldon W. Foster, ICP-ACC, CLP, CSM®, CSPO®
In the midst of the buzz around “going Agile”, it’s getting easier to lose sight of the right reasons for adopting it. The talking head rhetoric is usually something like, “Your competitors, Company A, B and C have all gone Agile, and they’re leading the market.” But it’s easy to see that’s correlation, not causation, and the line of thinking that creates those arguments is more concerned with marketing Agile books and courses, and less about your company’s ultimate success with Agile frameworks. Agile, therefore, starts to look less like sound business strategy, and more like a racket.
But Agile deserves a second look, even from the skeptical. When done well, it will get you to the coveted market-leading position, and it will get you there faster than Waterfall. The real purpose of Agile is to help you build the right product — but that kind of clarity doesn’t come on the back of a cereal box. It starts with a strategy, informed by your enterprise goals, and an acknowledgement that Agile is just the framework that shapes your efforts. Use it properly, and it will more than justify its effort. Use it poorly, and you’ll backslide into Waterfall in a flash.
To get the most from your investment in Agile, you need to understand what it is, what it does, and your unique reasons for needing it.
Let’s begin.
Agile Does Not Equal Agility
Definition time: Agile is a category of process frameworks that allows companies to build the teams, processes and matrix of enabling technologies that will drive their products or services to market faster, while also allowing for changes to the market, the ultimate deliverables, the definition of done, and the feedback loop that informs the decisions based on these changes.
When implementing Agile, it’s very easy to get lost in the doing: Checking off boxes for ceremonies like standups and retros, and getting excited about all the new lingo. However, once everyone is equipped with the “red book”, eagerly filling out sticky notes with their feelings, and throwing around jargon like “continuous deployment” — you’re still not agile. You need to focus on people and processes, not checkbox ceremonies, in order to get to the kind of agility that pays.
We like to differentiate between capital A “Agile” and agility: the people, teams, processes and enabling technologies that accelerate change. This is similar to the definition of Agile, but it’s agnostic — It’s not about the framework you use to create and drive change. Rather, it’s about the processes that get you to the true goal of agility. After all, a framework is not a methodology. The way Agile is sold often obfuscates the two. It’s important to remember that Agile is only a tool, and a tool is only useful in skilled hands.
What Makes a Set of Agile Frameworks Work?
In order to see the value of whichever Agile framework you choose, you must appoint stakeholders in the process of creating your product or service, who must be responsible and accountable for fixing problems and the resourcing for fixing those problems. That usually means the stakeholders are at the executive level, and have the power to act quickly when problems arise, as they inevitably do (and that has nothing to do with which framework you choose, or if you’re still working in Waterfall).
Incidentally, we’re not proponents of any particular framework. It’s up to the individual company, or sometimes the individual team, to choose the framework that best suits their needs. Again, Agile is only a tool. You can’t buy a new philosophy for your company.
To enable Agile, think of putting together your own “A-Team” (yes, like the TV show). The A-Team is a collective of experts, each with their own specialty, who come together to solve problems that they could not solve on their own (that’s true cross-functionality). On your team, that might include delivery, product management, strategy, analytics, and so on. It also crucially includes executives and stakeholders who act like equal members of the team with a commitment to contributing through the ability to remove barriers to getting the work done.
Your A-Team learns how to use their individual strengths to work together to solve complex problems. Being on that team and understanding how to best work together is a discipline unto itself. The A-Team in your Agile organization is one that can do everything and is connected to stakeholders in your organization so they can get the most impossible things done.
What is the Investment in Doing Agile?
Though Agile is about getting your teams to move fast, the initial investment in resourcing and change management is heavy. You need multiple new roles, new managers, training for your teams, and coaches to ensure the tool is used ideally. Every function in your organization has to budget differently for Agile. What we mean by this is that every function has overhead: You know that you spend for resources, tooling or enabling technology, and materials. If you’re a technology department, for example, you may spend for DevOps setup, just to cite one specific spend you department will have that others won’t.
As you transition to Agile, you may choose new enabling technology during your transformation, because your tools enable your processes. And your processes are changing.
Once you understand tooling costs, let’s explore training costs. The below model assumes an initial training time of three months, or one quarter. Note that three months is not an arbitrary time frame. For motivated teams, three months is a reasonable timeline to ensure that the principles of Agile are well-understood (though not mastered). This is dependent on fostering the right environment, offering opportunities for active learning*, and intentionally training the teams to be as self-organizing.
* To understand more about how to structure your environment for active learning, refer to Bloom’s Taxonomy, and the related text Bloom’s Taxonomy of Educational Objectives.
Note that the table assumes a company or enterprise division/department of 150 people. The reasons for this are explained below.
Why 150 people?
It’s been our experience that startups and scale-ups with 150 people or less are more naturally agile. Information flows more easily between teams, as a good deal of cross-functional work is needed to supplement understanding, ensure delivery and share critical information. For this reason, we recommend enterprises consider organizational structure with divisions of this size or less, that report to the C-level to manage the overall transformation. In this way, an Agile transformation can start at the organization division level, and scale across divisions as success and learnings are shared.
The Agile coach touchpoints assume that each team member will need one to two individual training sessions with your Agile coaches each sprint to supplement their learning, and guide them towards a fulsome understanding of Agile. A touchpoint, or training session is a meaningful coaching encounter which helps the individual grow and accelerates their learning and behaviour change. Each contact is approximately one hour of coaching, and our calculations assume that each coach can meet with four team members per day. You may feel that your teams will need more individual coaching to adopt Agile successfully.
After a single quarter of active learning, the efficiency of the division may be nominal, but they will be ready to take a chunk out of your enterprise objectives for the year. To ensure the success of the coaching, we recommend that the team responsible for the budget should create some objective measure for what success looks like. What are the critical success factors for the Agile transformation? Revisit these success factors and their metrics each quarter to keep your transformation on track.
How do you measure ROI?
ROI for an Agile transformation can seem nebulous. Certainly, it may take several quarters for ROI to become apparent, and we don’t mean to suggest that a single quarter is all it takes. However, there are four indicators that can easily be compared for before-and-after results:
What are the things we can measure?
- Cost of attrition
- Cost of rework
- Team engagement
- Average number of days to ship value to market
Cost of attrition
Agile should improve the turnover rate of your organization or division. Consider that onboarding expenses usually total 20% of an employee’s individual salary. If you’re onboarding at above-normal rates compared to the standard for your industry, those costs can eat up a serious proposition of a department or division budget. To measure improvements, consider either a before/after comparison in attrition rate in the division, or compare the division to another as a benchmark for your organization.
Cost of rework
Rework is not a small cost, though it’s usually treated like an afterthought. Remember, stakeholders pay for rework on top of the CapX expenses for the product, after it is feature complete. These “hidden” or forgotten expenses cost money, and they also cost time — both in work hours for your teams, and potential lost time in-market, leading to lost revenue.
To measure improvement following your Agile transformation, compare the cost of rework for each release, including hours of work and any additional expenditures, either as a before/after, or to a benchmark division, as in the previous example.
Team engagement
Engagement can be judged by both productivity and sentiment. A team’s engagement is often measured as an eNPS (Employee Net Promoter Score), but an increase in productivity is an effective measure of the success of an Agile transformation, since it’s often the top goal of an organization looking to adopt Agile practices. Again, this can be measured as a before/after comparison within divisions, or by comparison to other divisions.
Average number of days to ship value to market
Shipping value to market is the key indicator of success in your organization. What “value” means may differ, depending on the organization (service packs, updates, etc.), but if the goal of Agile is in productivity, the proof is in a decrease in the number of days from ideation to shipping value to the market. In an enterprise, dependencies and silos often hinder releases, stretching an update that should be done in weeks to a timeline of months. We have experienced enterprise clients whose internal processes prevented them from releasing any delivery code for an entire quarter.
Assessing this metric is actually assessing how performant your enterprise is. This metric can be measured across divisions, but the before and after comparison is stronger in terms of proving the value of an Agile transformation within teams.
What do you get when you invest in an Agile transformation? You get organizational agility. You get to build the right tool, at the right time for your customer base. You get improved, positive employee engagement. You get cost savings from less rework, and in retention of your employees. It takes a time investment and capital investment in people and processes, but the payoff is measurable and provable — which makes agility scalable across your organization.
How Do You Make a CEO Agile?
Agile at scale is the unsolvable question for a lot of companies, even those that are successfully using Agile at the team level, and seeing the benefits in their output of products and services.
The reason, perhaps, is in the very nature of how we construct our businesses, government, or even schools. We are steeped in hierarchical, Waterfall structures that make the idea that bodies of people can be self-governing difficult to accept. Even when we study Agile, take classes, read books, and understand and are energized by the value it can bring, it’s very difficult to live Agile in practice. We are used to the chain of command, and the process of seeking and granting permission to do work — most especially when our ideas are novel or will change the course of our work.
To radically break out of Waterfall at an enterprise level is very difficult. These companies are structured with a single person at the top, perhaps under the direction of a board. Even when teams adopt Agile, it’s rare to make the executive-level responsive to, and in service of, the teams who create products and services. The best you see in practice is an executive team who decides to pivot quickly, and leaves product teams scrambling to deliver. We can call this Agile, but it’s more like chaos.
To support agility within an organization, it has to come (ironically) from the top, down. The CEO and executive team must commit to agility, not only as an expectation for their departments, but as a personal practice for their leadership. By de-centring their role as a leader and conceiving of themselves instead as enablers, CEOs can enable a truly Agile organization, and reap the ROI benefits of it.
The Real Reason for Agile
The promise of Agile is that your teams will be (1) self-governing, (2) will move faster, (3) will be able to react faster to problems, or (4) to changes in the market.
If Agile is “tacked on”, none of those things are possible. In other words, Agile must be set up as a function in your organization, as essential as Finance or Operations. When Agile is a function, you can turn your ship quickly as changes and challenges occur. This happens because there’s alignment within the organization’s leadership. Agile, as a key strategy for the company accomplishing its goals, is how you accomplish pivoting and adapting with speed.
Consider this scenario: You’re building serious, important software. A senior executive needs to know how long it takes you to debug and code a fix for your software. Just five minutes, you can confidently say. Well, that’s great! How long before you know for certain that your product is ready for the market? Three months, you say. Google, as an Agile company, can do this in ten minutes. Do you see value in that?
If you’re not Agile, it’s going to take you three months and five minutes to make changes to your product.
Agility allows you to fix problems in hours, not months. It allows you to know how much time it will take to fix problems. Best of all, it allows you to avoid as many problems as you can, by building quality into the process of creating a product or service from the start.
You’re doing Agile to build the right product. Not just to build faster, not just to test or to change more easily, or even get that product in market faster than the next company. Agile ensures fitness and purpose for your work and your company. You can’t know you’re building the right product unless you have the freedom to change quickly and test rapidly.
And knowing is half the battle.
