Are you Agile or Fragile? Why Agile Software Development Processes Can't Save Your Company, Career, or Credibility.

Introduction

Agile processes are the de-facto standard process tool set used in software production for the last 20 years. But as with any tool, the value depends on how well you use it.

Are you ready for the hyper-competitive world of SaaS product development?

The competition is getting stronger and more cutthroat by the minute.

Don’t you wish there was a simple way to instantly succeed with little effort?

(I do.)

For example, wouldn’t it be spectacular if a brief two-day training meant every single one of your projects always came in on time, on budget, and with acceptable quality?

It would be great, but unfortunately, you probably already experienced that there are no magic silver bullets to make all these dreams come true.

This includes “agile” processes.

A research organization called the Standish Group has studied success and failure in technology projects from 1994 to today.

The good news? They found Agile processes consistently outperform Waterfall by 3X.

The bad news? While Agile has been around for decades, the Standish Group research shows that 2 out of every 3 projects don’t meet critical success criteria today.

So beware of people proclaiming any particular process is a magical elixir curing all your software production pains (or eliminating the need for strategic thinking, planning, and design).

Maybe they don’t know better.

Or worse, they are scammers digging deep into your pockets to extract your hard-earned money. (like a modern version of a Snake Oil salesperson…. With outrageous, magical, and unrealistic claims failing to deliver the promised benefits.)

Here’s the thing. While having formal processes is essential, it isn’t the complete picture.

And if you’re reading this, you probably already know that, “Doing” Agile is just one aspect of what it takes.

Of course, we all require clear workflow, meetings, and checklists that everyone understands. They serve as a valuable bridge between technical and non-technical people. All stakeholders need to align, even if it is around a hazy window into the technological world.

But that’s the easiest part.

And blindly following prescriptive processes is problematic.

Here’s why: The fuzzy shadows seen through the process window is not the same as the sharp engineering reality on the other side.

For example, “doing” agile by following prescribed processes isn’t the same as “being” agile.

So, what can you do?

It’s worth asking yourself:

how agile are you?
And, if your company isn’t agile yet, how do you get there?

In this blog, I’ll cover what will enable you to stay competitive… Why today’s agile processes are only the tip of the iceberg… and why process alone don’t mean much without other critical parts of the equation.

Welcome aboard.

I’m happy you’re along for the ride. So hold on to your hat, and let’s dive into the details.

What is agility?

When you think about it, agility is just the ability to respond quickly to change.

That’s it. It’s really that simple.

For example, imagine if a new technology shakes up an industry. You only have an agile business if you can quickly adapt to meet new needs while taking advantage of new opportunities.

If you are agile, you can

Quickly launch new products in weeks or months (not years).
Easily add new services to attract new customers or help your existing ones.
Rapidly adapt your products to changing customer needs.

Here’s a good agility litmus test:

Do you safely and routinely change your software, strategy, or operations in days? How about hours or minutes?

If not, then despite whichever process you use, you’re not agile.

And being agile doesn’t mean moving quickly in a haphazard or unplanned way… that’s just being chaotic.

Instead, being agile requires a plan. You map how you expect things to go. And your plans must be agile, flexible, and easy to change.

Because, let’s face it, no plan ever survives once reality crashes in.

But that doesn’t mean you throw it out. You grow, develop, and improve.

Think of it this way: Your plan is a living organism, always adapting to not get in the way while providing a powerful tool to meet objectives.

So if your plans can’t evolve, your company can’t adapt. And any company that can’t adapt is not agile.

Here’s the surprising secret about planning: the point of planning is not to produce a plan… The value is all in the critical thinking required to prepare for surprises and adapt without having everything fall apart.

Isn’t the whole point of agile software development to be lean and figure out details as you go? So it would be crazy to not account for surprises, right?

Here’s one of my favorite quotes about military planning from President Eisenhower:

Plans are worthless, but planning is everything. There is a very great distinction because, when you are planning for an emergency, you must start with this one thing: the very definition of “emergency” is that it is unexpected; therefore, it is not going to happen the way you are planning. — Present Eisenhower

The problem with waterfall processes is that up-front design that is too detailed, expensive, and risky. You don’t have the full picture until you get into the weeds.

So why invest time and money diving into details that will almost certainly change?

It’s better to map out objectives, plot a course, and be able to adapt as reality hits.

The agile movement addressed this essential aspect of producing software so you get just enough details to make good decisions as you go. And whenever your current map doesn’t match the reality you discover on the ground, you reassess.

“A map is not the territory it represents, but if correct, it has a similar structure to the territory, which accounts for its usefulness” - Alfred Korzybski (father of general semantics)

Agility requires a map to think ahead. But you also need ongoing planning, adaptation, and coordination so you can easily adapt to change.

For example, you likely want to leverage the latest advances in technology, without blinking.

So, agility comes from “being” agile rather than from “doing” Agile.

And, contrary to what some people think, you don’t magically become agile just by following a process, even if someone slaps on a label saying “agile” to sell you books, training, or tools.

There’s more to it.

So, let’s dive into another level of detail and look at different aspects of agility.

Types of Agility:

When people talk about agility, they frequently lump several meanings under the single term ‘Agile.’

You can have agile

And knowing the differences makes all the difference.

For example, in agile software development,

You have the twenty-year-old agile software development movement with 12 core principles.
Then there are agile software development methodologies that pop up every day. These “productized” processes aim to put agile principles into practice (some better than others).
Then you have agile business operations, which include supply chain management and marketing operations, and strategy, which comprises a plan for what your company will do, who will do it, and how you’ll make money.
Finally, you have agility as a mindset baked into your culture, where people constantly challenge assumptions and make adjustments when needed.

How can anyone honestly say (with a straight face) that there is one and only one way to do things and that it’s the only way to be agile? Isn’t it the antithesis of agility? Crazy right?

If you’re agile, doesn’t that mean you adapt and improve when there’s a better way?

Side note: “Scrum” is a simple analogy to make agile software development processes easier to manage.

The Scrum process was first used in 1993 by the Easel Corporation. They used ideas from the 1986 Harvard Business Review article, “The New Product Development Game.”

The authors, Takeuchi and Nonaka, wanted to make it easy for anyone to communicate, estimate, and manage software development processes by comparing them to rugby.

Today, you can become a fully certified “scrum master” in this analogy by paying a couple hundred bucks to sit in a two-day class.

But here’s something to chew on: Don’t skills with more value take more time to learn?

For example: It takes months to learn to code. It takes years to learn to code well. It takes decades to learn how to effectively meet business objectives through architectural design aligned with processes, staffing, and technical strategy.

So, beware of the marketing pitch. While the “scrum master” label sounds fancier than “engineer,” like most things, the value correlates to the amount of knowledge, skills, and time required to become proficient.

Here’s a thought experiment.

Imagine you need emergency brain surgery to save your life.

The sun is just coming up as a family member drives you towards the hospital. Your nerves are shot.

It gets worse the closer you get. You get to the parking lot and walk into the building and up to the surgery prep area.

Your heart is pounding in your ears as you put on the hospital gown and lay on the operating table, and you feel the cold steel against your back. A clean-cut man strolls through the door in a freshly pressed, bright white lab coat, greeting you with an assuring smile.

“Hi. My name is Frank. You are going to be fine. I’ll be directing the surgeons on how to execute the operation.”

You ask, “Hey Frank, how long have you been a doctor?”

“Oh, I’m not a doctor. But don’t worry, I took a two-day class and even got certified by filling out a multiple-choice test at the end”.

I’m willing to bet you’d probably jump off that operating table and run for the hills, your hospital gown flapping in the breeze.

Seems crazy?

It is.

But I’ve seen software teams run that way, and I bet you have as well.

Don’t get me wrong, I understand the tremendous value of formal processes. But across every specialization, in every single industry, across the world, there’s always more to it than just process…

So we have to be careful because most non-technical stakeholders don’t know what they don’t know. And unfortunately, they are often decision-makers writing the checks.

In fact, studies show the high risk of gross oversimplification of highly technical practices. (check out the Dunning-Krueger effect)

Now, I’m no surgeon, but if it’s me on the operating table, I want the expert with the deepest knowledge and the most experience, on top of state-of-the-art process training, directing a team of highly skilled specialists.

In other words, the thought of Frank (the manager in our thought experiment) makes me nervous.

Here’s the thing: When you take a moment to think it through logically, it becomes crystal clear that “doing” and “being” agile are two very different things.

While the term may be the same, one is a software development process and the other is a way of being. Unfortunately, it takes a level of knowledge to make this critical distinction.

And while we need effective tools for non-technical leaders and technicians to communicate, coordinate, and understand each other, unfortunately, tools are useless without the skills to use them.

Today, highly skilled technicians responsible for doing the hard work end up getting hit by a tidal wave of oversimplification driven by the financial machinery designed to profit by selling us “Agile” books, training, and consulting.

And unfortunately, people who make decisions are often misinformed because of the sales hype.

Even worse is when they buy the lie that all you need for designing, planning, and making software is an agile process.

Don’t get duped and buy the lie. There’s more to production than process.

Why agile processes are not enough to stay competitive

Strategy without tactics is the slowest route to victory. Tactics without strategy are the noise before defeat. - Sun Tzu

Engaging in agile processes (like Scrum) with your engineering team is only a tiny slice of the pie.

And here’s why.

“Doing” agile is a prescribed process. While it focuses on tactical execution, it does not cover more critical components of success like business strategy, design, or planning.

And without strategic thinking, you’re just “doing” agile without “being” agile.

In fact, most software projects fail today from inadequate preparation, a lack of strategic thinking, and poor design—not process.

For example, imagine you have the wrong strategy. Or, you miss the market conditions for success. In these cases, no process will save you, even with a dazzling “Agile” label slapped on the box.

Let’s take the example of two companies.

On the one hand, imagine a ragtag start-up that just threw together a new product. Then, imagine a large, well-established company.

Which one is most likely to succeed?

Business Agility: The big company with battle-tested operations, a brand name, proven products, distribution channels, and the ability to successfully adapt to change?
Or Agile Processes: The fragile new start-up, with its tiny marketing budget squeaking out questionable products, “agile” processes, and a lack of strategy, is just throwing spaghetti against the wall to see what sticks?

The answer should be obvious.

The new company doesn’t even have a chance because it has a faulty strategy. It is all over the place, trying to do everything at once. It doesn’t have the resources to do an excellent job in any specific area.

On the other hand, the established company is truly agile (even if it does not follow a prescriptive “agile” process). There is a plan for what it will do and how it will use its resources. It might be slow. It may be bureaucratic. But it will win because true agility trumps chaos every time.

Here’s the critical bit: Chaos is fragile, not agile.

While sometimes you can get lucky and survive, you can’t be agile without strategy, planning, and coordination because

Lack of alignment around clear objectives means people are scrambling in different directions.
You have to think ahead to coordinate a successful pivot to meet your objectives.
You can’t effectively pivot your team, department, or organization in a new direction tomorrow if you don’t know where you’re headed today.

I don’t know about you, but I don’t want my success to be based on a lucky roll of the dice.

Building a culture of continuous testing and improvement across your organization.

Want your company to stay competitive?

You’ll need

Ubiquitous agility (including adaptable processes, strategy, and structure).
A culture of continuous testing and improvement.
To be agile, not just do agile.

For a business to be agile, everyone must work to improve the parts of the business where they are experts. And it has to be every day, with every breath.

Just going through the motions with a development process like Scrum won’t cut it. Still, it doesn’t stop people from trying.

But, as we have covered, “doing” agile doesn’t necessarily make you agile.

Agility is a mindset. It’s a culture. Agility must saturate every aspect of your business.

So, it’s really not achieved through the latest off-the-shelf process. Rather, it lies on the shoulders of the CEO and senior leaders.

The whole organization must be agile. So design your organization’s structure to leverage Conway’s Law and drive agility through your organization from top to bottom.

Conway’s law: “Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.” - 1967 Melvin Conway

As a leader, you must constantly challenge assumptions and try to improve what the company is doing, and everyone will follow suit.

For example, if a CEO is satisfied with the status quo, their company will be happy with the status quo. Nothing will improve.

Want your company to stay competitive?

Your entire organization must review its assumptions, operations, and products. So create a culture of testing and validating things all the time to make sure you have the information you need to make improvements.

It has to trickle down to every team to test new and existing ideas all the time and be willing to discard the ones that don’t work.

Be keen to change and commit to constant improvement.

As we covered, agile companies bake agility into their core culture, operations, and strategies. They constantly test new ideas, learn, and adjust with every opportunity.

Agile companies change when it is necessary. They will change their strategy, products, and business models when it makes sense.

They don’t get attached to anything. Not only that, but they always keep their thumb on the pulse of their customers. They are ready to discard what doesn’t work and replace it with something that does.

When a company commits to constant improvement, it doesn’t get stuck in its old ways. It is always trying new things, experimenting, and challenging its assumptions. When a new technology allows the company to do its job better or faster, it jumps on it.

While “doing” agile helps non-technical people communicate with engineers, being agile is the key to success in a hyper-competitive world.

Wrap-Up…

Want to stay competitive in the fiercely competitive digital world? You must be agile in your culture, operations, and thinking.

Never be satisfied with how your teams do things today (including your agile software manufacturing processes). Instead, constantly look for ways to improve and get better.

The more agile your company is, the better your chance of success.

If your company isn’t agile enough, it will probably get left in the dust as more agile companies improve, grow, and become more efficient.

I hope you found this brief journey with me useful.

Best of luck, warm regards, and best wishes

—Matt

By the way…

Do you want to be agile?

Truth Shield provides cutting-edge software development services. And we’re here to help you with anything from strategy, ideation, and assumption validation through planning, design, validation, specification, construction, and verification.

We have the expertise to help you flip the agility switch on. Contact us today for a free consultation!

I’d love to hear how we can help, so Click here now to get started!

Are you Agile or Fragile? Why Agile Software Development Processes Can't Save Your Company, Career, or Credibility.