How to Explain Agile to Anyone? With a Metaphor

Agile software development is like going on a backpacking trip. Let me explain. 

Custom software development is quite a complicated process. During my interactions with potential clients I often speak with people who have amazing ideas, but no prior experience in software development. If you are one of them - this article is for you.

How to explain Agile software development to non-technical clients?

It is a challenge to explain how the process of developing software works in the Agile/SCRUM approach:

• why estimates are a form of an educated expert guess (but a guess nonetheless) rather than a fixed scope & cost quotation,
• why it’s impossible to foresee and plan everything upfront,
• why you can't put a fixed cost on an Agile project. 

Especially that in the early stages, the majority of the clients do not have their idea fully formed, not to mention translating it into technical specifications (e.g. a backlog with all the User Stories and all the User Acceptance Criteria).

A few bullet points or even a good presentation is far from enough to give you an exact quotation for a project.

I’ve also seen instances where a client has heard a lot of good things about Agile, but their knowledge does not seem to be thorough enough. The most typical scenario is when the client would like to work in Agile due to the benefits that they’ve heard about, but at the same time they would like to have it all wrapped in a fixed price & scope model. This can’t happen, and it is contradictory to the Agile methodology at heart. 

So, how do you set the story straight? The easiest way to explain any complicated process is to use a simple metaphor or a generally understood paraphrase.

Finding the right paraphrase for custom software development is not easy.

• It’s a process quite different from our usual purchases or activities.
• It is a long-term process, not a singular purchase.
• Building each product is different as each has its own set of constraints and possibilities, and you create something unique every time.
• You don’t know everything upfront and need to make decisions as you go.
• It’s expensive - a few months worth of work of a good development team could easily buy you a really nice car or even a house.
• The software development environment is dynamic and accepting of change. 

What Agile and going on a trip have in common?

Software development is very much like going on a long sightseeing trip. And I don’t mean the all-inclusive type where you’d spend a week or two just lying on the same beach. I’m thinking about the one where you go with your backpack to a country half the world away and want to see as much as you can, or maybe even a backpacking trip around the globe.

On a conceptual level that kind of trip is a complex process that will be a considerable expenditure, involves a lot of planning, you or nobody has done it before in the exact way you want to, and it requires flexibility. Last, but not least - it might be a one-in-a-lifetime thing for you - you want to do it right.

Ok, I hope I have painted the general picture. But there is one significant complication when it comes to the example I brought up - you can plan & go alone on your trip, but you cannot create your application by yourself. You need to either recruit your own design & development team or get external help from a software development agency. No matter the choice, the trip metaphor works.

Since it’s close to impossible nowadays for people with no solid background in software development to assemble their own project team (and for those who have it’s still an incredible challenge), we’re going to focus on cooperation with an agency, which is the typical scenario in such cases. (See more about it: Your own team vs. hiring an agency - Which one is for you?)

Let’s dive deeper.

Booking your trip

You have decided you want to go on a trip of your life. It seems ambitious, tiring, but also exciting (just like having an idea or pitch for an application). Let’s assume you can’t do it yourself - you need external help - therefore you decide to cooperate with a travelling agency specializing in fully-customized backpacking experiences.

I can imagine having a few meetings with the agency to establish your expectations, main priorities, countries and landmarks you want to visit, and benefits that are important to you so that the agency can understand your needs and based on that propose the best experience for you. Similarly, when speaking with a software development partner, you will participate in a handful of meetings (maybe a Product Design Workshop) where the agency will discuss your ideas, expectations, needs and goals.

The agency will present you with a plan or an overview of what’s going to happen, giving you different possibilities and suggesting directions. At that point, it’s a draft with an estimated time and cost with high-level information - it’s all dependent on what options you’re going to choose and leaves the space for the unpredictable factors and changes.

In a software development environment, this would be equal to an initial estimation. The agency estimates the described application’s elements and features relying on the information (business & tech possibilities and constraints) we have from the client at that point in time to the best of their understanding.

Preparation vs readiness to adjust to changing circumstances

Imagine yourself landing in Athens and that all flights to Mykonos have been canceled for a few days. You really wanted to go there, but now you need to rearrange your trip and pick a different stop. Or you might actually like it a lot in Athens and decide to spend a couple extra days there. Or maybe you realized you missed a spot that is a must-see and you want to add it to your list while you are in the area. All is possible, you just need to let the agency know what you want to do and they will take care of it. This was not the initial plan, but the situation has changed, and you need to act on it.

The same thing can happen throughout your project’s development. Some features’ priorities may change; you might add new features or make the ones initially planned more complex. The situation on the market could be altered and force you to adjust your product to some new regulations or users’ preferences, or you simply missed something out.

The estimation you established at the beginning is a general roadmap for your product. It is flexible, and thanks to that, it becomes your risk airbag.

Should anything change, you can act and adjust the timeline, the costs and work accordingly. You’re not pressed to execute a strict plan we came up with when the circumstances were different. To put it simply, it allows you to make the best decisions as you go.

Bearing that in mind, you can’t forget the natural consequence is that such changes also affect the time & cost related. You cannot expect to stay a few days longer at the same hotel without extending the trip’s length and increasing your budget. It’s the same for software development. (Learn more about Agile’s most common traps.)

What's the alternative? A few words about Waterfall

Instead of starting with an outline and staying flexible throughout the trip, you would have to plan everything upfront to the tiniest detail and stick to it regardless of what happens. Imagine planning for months ahead all the accommodation details, bus/train tickets, what landmarks you will see, at what hour and for how long, or event what you will have for breakfast, supper and dinner and at what time. Every single day and activity planned and fixed to the hour, months ahead of the actual trip, written in the contract, with no possibility to change. Just imagine that.

If anything unexpected happened, you would have to contact the agency, negotiate everything, wait for the quotation and sign an annex to the contract. This (pretty much) is the Waterfall & fixed price approach in software development. There is very little space for adjustments, especially in real-time. You follow the plan you established at the beginning, no matter the changing environment and the situation around you and your product.

In most cases, the Waterfall approach will end up being more expensive for you than Agile, and there are two reasons for it. The first one: extensive paperwork to be taken care of. The second one: deal security.

A guarantee of delivering software at an exact price comes with a set of risks we covered above (estimation mistakes, contingencies etc.) the agency needs to cover from their own pocket. To avoid losing money on such a deal, a rational thing to do is to increase the total project price from day one to have the necessary safety margin for events you can’t really foresee.

The main benefit of the Waterfall solution is the guarantee of the time & costs involved. The question is - would it still be the perfect once in a lifetime journey for you?

In some cases, some projects, probably yes. Especially for large corporations. Generally, big companies have much bigger budgets, allowing them to cover additional Waterfall costs. Their decision-making processes are much slower than those at smaller companies, hence they may have difficulties managing the project real-time. Usually, these firms have internal capabilities and can afford to define the product fully and prepare extensive technical documentation before the project’s start.

In all fairness, we see more and more largest corporations decide to go agile in software development (I’ve personally had the pleasure to cooperate with one of the Big Four companies on a large software development project). It’s no surprise - agile is the go-to way to develop modern software for a reason. It allows you to stay flexible and react to market changes in real-time and is the most efficient way of creating digital products.

Check out also

• Agile: Maximize Business Value On a Limited Budget. In an agency’s model of software development, a limited budget is not a project’s death sentence. It's more of a reality check determining if a project is affordable for the client.
• How Agile Can Facilitate Design and Development Cooperation. Is a truly Agile approach to Design possible? EL Passion's Head of Design shares the road to our design process.