Agile Value Proposition: Why CEOs Should Care About “Being Agile”

Recently, I was in the office of a major client of mine and we were discussing the fact that the CEO doesn’t really understand why he should invest in becoming agile. Everyone continues to tell him that is the way to go, but he’s not completely convinced. He just can’t quite see the overall benefits and value proposition for the organization as a whole. So, in his mind, why should he spend all this money to give the CIO a fancy new toy and bragging right for “being agile”?

I get this question a lot… Why Agile? And many CEOs are asking this very question of late to those of us who tote agility. I think we in the Agile community do ourselves a dis-service by not talking about an approach that is holistic and involves the business, but when it comes to being able to succinctly explain to them why they should go on this journey to becoming Agile with us, we fall very short in stating our compelling case for change. Enterprise Agility is about the entire organization, not just IT. And, if we really want to make the impact we know we can have, we need to bring the business into the conversation.

Overall, Agile is still widely viewed as a software development process. Something that is done in IT and frankly, many times it is pushed by the wrong person in the organization, the CIO. When, in actually if a more holistic view of the Agile Value Proposition is introduced into the conversation, it now becomes something that the CEO understands and will fully support for the organization. By having CEO backing, it is no longer just the CIO supporting Agile adoption. It becomes a top-down initiative that garners official support from both the business and IT, thus increasing a company’s overall chances of successfully adopting and scaling Agile at the enterprise level.

But what is this Agile Value Proposition that should appeal to both the business and IT? Let’s spend a few minutes discussing the three major benefit of Agile in order to understand how they support and transform an organization when the dialogue becomes more holistic in nature.

Shorter Payback Periods
First, let’s get one thing straight, upfront Agile is actually more expensive than running a Waterfall shop. At first blush, that might be a starling comment. However, CIOs and CEOs are looking in the wrong place when it comes to benefits. The biggest benefits from becoming agile are not realized in cutting headcount, as has often been the focus in the past. The real benefits come from rapidly and consistently putting new features in the hands of those who will benefit from them the most… the end user/end consumer. By shortening the development window and pushing products out to the market faster, the payback period is shortened and true business benefit is realized.

Just look at Apple… Steve Jobs realized this long ago in the way he pushed products out to the market that were not fully loaded down with the features and functions that would come over time. He captured the market and established his place at the top by selling base models of the iPOD and iPhone, thus capturing the market and locking in future growth potential, while enjoying current revenue streams that made Apple a market leader. He was being agile before being agile was cool… he was iterating, and thus innovating around his product. When everything now moves at light speed being the first to enter the market is a big advantage! And the diminishing value of money or the concept of Net Present Value (NPV) means more profit dropping to the bottom line sooner. Now, if that doesn’t get the attention of the business, I really don’t know what will.

Higher Quality
Quality is the next place our C-suite should be looking for what I call… “The Agile Advantage.” Using Agile methods results in higher quality products. That translates into greater customer satisfaction and repeat business in the long run. I have no idea how much money I’ve spent on early adopter gadgets that didn’t’ work, or for that matter everyday products that just don’t produce the benefits to me personally as a consumer. For example, since I am a consultant, I spend a lot of the time on the phone. So, my phone is very important to me. And yes, I’m one of those people… that walks around with a Bluetooth in my ear, because I also travel a lot. I can’t tell you how many Bluetooth devices I’ve gone through in the last 5 years because the quality was lacking for one reason or another.

The key features I look for in making my purchasing decision include durability, battery life, sound quality, noise reduction, and ease of charging. Yep… that is my list and up until recently, they have all failed miserably at making me happy with my purchasing decision. I have a whole drawer full of them and I’ve tried everything from the cheapest to the most expensive models available. About a year ago, I finally found one that satisfies all my needs… Eureka! I paid $100 for it, but it now sells for $70 on Amazon.com, from Blue Ant and it’s exceeded all my expectations. It is a quality product that I would buy again and again. In a world that has lost sight of the quality factor, people will pay for a quality product that lasts.

Using Agile methods increases quality by decreasing defects. Practices such as Test Driven Development (TDD), Continuous Integration (CI), and Paired Programming all result in higher quality being built into the process and the product in the end. By designing and developing products the right way the first time, less technical debt is created. So, a company stops the cycle of paying for “the sins of the past” when it comes to the trade-offs that have to be made when the huge waterfall program falls behind, but the product still needs to go out the door. Agile insists, instead of compromises on quality. It is inherently built into Agile methods and whether you are new or have been using them for years, you can immediately reap the benefits of increased quality.

Flexible Predictability
When is the last time anyone in IT said to the business… tell me what you want and I’ll deliver it on time and within budget? Probably never… right!?! Why does it always seem like IT over promises and under delivers? It is a common complaint that I hear time and again from our business brethren. I believe this situation is created by a fundamental difference between how Agile and Waterfall methods work that I don’t think is discussed enough. That is, in Agile, schedule and budget are locked, and scope is what becomes flexible. In Waterfall, Scope and Schedule are locked, and budget is what becomes negotiable.

Well, not really right? As a business person, you want to know how much something is going to cost you so that the checkbook stays balanced. More often than not, what happens after the project starts is a long trail of change orders. And believe you me when I say this as a seasoned IT professional, we don’t like them any more than the business. Change requests are time consuming and at the end of the process, no one is happy as a result. This makes for unhappy business partners and a demoralized project team. Not exactly a win-win situation in my book.

It is inherent within human nature to change our minds and usually we only know what we want when we see it. Sound familiar? Remember the old term WYSWYG… it is still very much alive and well, because naturally as the development process unfolds, change is going to happen. Agile introduces what I call flexible predictability. By being transparent during the development process fosters collaboration between the business and IT that allows the product to change as we iterate, supporting the concept of innovation. We build in flexibility that is predictable and plan for change, instead of sticking our heads in the sand and insisting nothing can change.

By using Agile techniques, such as backlog prioritization and grooming (starting out with a stack ranked list by priority and then repeatedly going back through it time and again to refresh what is the biggest priority), time boxing (locking the development box and only allowing for changes in priority between development cycles), and fixed teams (not throwing more resources at the problem when we get behind); Agile methods reduce risk and allow for innovation. The cost of each iteration is predictable and limited to the amount of work that can be performed by the team within the fixed-schedule time box, but is still flexible enough to allow for that inevitable change that will occur.

Summary
So, to summarize, to me The Agile Value Proposition that savvy business and IT people should be talking about includes:

• Shorter payback periods that deliver greater Net Present Value (NPV) revenue streams and cover Cost of Goods Sold (COGS) sooner
• Increased quality resulting in less rework, cheaper cost of development, less technical debt, and greater customer satisfaction
• Allowing for change, reducing risk, and fostering innovation through the use of flexible predictability

If we shift the discussion to an enterprise view of why agile, and focus more on a holistic view of how value is derived, both the business and IT will benefit by being agile, bridging the gap and foster adoption much faster. Overall, once you see the benefits that agile can produce, the question then becomes… Why didn’t we do this much sooner? Now there is an “ah-hah” moment that is worth the wait and makes this journey well worth it!