Chapters
Agile software development is kind of like going on an around-the-world backpacking trip. Let me explain.
Custom software development is quite a complicated process, completely different from any other experience in our everyday lives.
During my interactions with potential clients, I often speak with people who have amazing ideas for their first startup, but no prior experience in software development. If you are one of them - this article is for you.
So how do I explain Agile software development in a relatively simple way?
With an analogy.
In this article, you will learn a few things about Agile software development:
- what are the similarities between Agile software development and a very long backpacking trip,
- why estimates are a form of an educated expert guess rather than a fixed scope & cost quotation,
- why it’s impossible to foresee and plan everything upfront (and why you actually wouldn’t want to do that)
- what is the alternative approach (Waterfall)
- why you can't put a fixed cost on an Agile project
What do a trip around the world and Agile software development have in common?
In this case, I'm thinking about the kind of trip, when you go with your backpack to visit a few countries half the world away and want to see as much as you can, or maybe even a backpacking trip around the globe.
Let’s list some of the main similarities between the trip and the creation of your first product:
- Both are quite different from our usual purchases or activities
- They are rather expensive one-in-a-lifetime situations, and you want to get the most out of them and do it right the first time
- Both are long-term processes rather than singular purchases
- Both mean doing something unique that probably nobody has done before
- It’s impossible to know or plan everything upfront in both scenarios
- You need to be prepared to accept the changes and adjust your plans on the go
One caveat in my metaphor: you can plan & go alone on your trip, but you cannot create your software by yourself. You need to either recruit your own design & development team or get external help from a software development agency.
So for the sake of the example let’s assume you can't (or simply don’t want to) plan the trip yourself and you need external help. Therefore you decide to cooperate with a travelling agency specializing in fully-customized backpacking experiences. They will help you not only with creating the travel plan but also take care of all the formalities, bookings, and expenses while you are out there traveling so you can truly focus on getting the most and the best out of your trip.
Planning your trip with the agency
Let’s dive deeper - how would that actually look?
We can imagine having a few meetings with the agency to establish your expectations, budget, main priorities, expected accommodation standards, 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 and help you adjust the plans to your budget.
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.
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) provided by the client at that point in time to the best of their understanding.
Preparation vs readiness to adjust to changing circumstances
Let’s say your original traveling plan assumed visiting Japan after completing your Thailand tour. But you find yourself trapped in Bangkok as all the flights to Tokyo have been canceled for the next few days. You need to adjust your plans.
However, the trigger for change does not necessarily have to be external. Maybe you actually like Bangkok so much that you simply want to stay there longer. Or on the contrary - maybe you’d prefer to cross out some items from your Thailand list in order to spend more time in Tokyo? Or maybe, after speaking to some locals, you realized there is a must-see location nearby that you’ve never heard of before and you want to add it to your list?
In any of the examples - this was not your initial plan, but the situation has changed, and you need to act on it. All you have to do is let the agency know so they can adjust the plans based on your feedback, and swiftly take care of everything for you.
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.
The estimation you established at the beginning is a general roadmap. It gives a general understanding of the scope, range of time & costs involved, but remains flexible.
Should anything change, you can act and adjust the timeline, and the costs and react accordingly. You’re not pressed to execute a strict plan created when the circumstances are different. To put it simply, it allows you to make the best decisions as you go without binding you to an unrealistic rigid plan from the very start.
Bearing that in mind, we can’t forget the natural consequence is that such changes also affect the time & cost. You cannot expect to stay a few days longer at the same hotel without extending the trip’s length and increasing your budget. You either need to extend the budget and your timeline or give up some other points on your list to compensate for it. It’s the exact same story with software development.
What's the alternative? A few words about the Waterfall approach
Let’s imagine you are not comfortable with the uncertainty in the plan and costs. You want a very fixed plan for a fixed cost. What do you do then?
Instead of starting with a general outline and staying flexible throughout the trip, you would need to plan everything upfront to the tiniest detail and stick to it regardless of what happens.
This means planning for months ahead, all the accommodation details, bus/train tickets, what landmarks you will see, at what hour, and for how long. Even what you will have for breakfast, lunch, and dinner. Every single day and activity is planned and fixed to the hour, months ahead of the actual trip, written in the contract, with no possibility of change. Just try imagining that.
This (pretty much) is the Waterfall & fixed-price approach in software development. There is very little space for adjustments, especially in real time. You need to plan everything at the very beginning and then follow it to the letter, no matter the changing environment or the situation around you and your product.
Not only that. In most cases, the Waterfall approach ends up being more expensive than Agile, and there are two main reasons for this.
The first one is risk mitigation. Working in Waterfall and fixed price means that the agency must compensate for the risks we covered above (internal and external) to avoid a financial loss on such a project. It simply translates to an elevated price regardless of whether the changes actually happen or not nor to what extent. The agency has to consider all the worst possible scenarios and put a price tag on that.
The second one is the additional workload and formalities. Not only the project documentation before the project starts is incomparably more complex and elaborate, but so is the contract and all the project documentation and procedures throughout the project. Each change request in the original plan requires its own process: estimating, describing, and formalizing with a legal document (e.g. Annex to the Contract, Change Request, etc.). All the additional activities done by the agency may seem “free” - they might not be stated in the offer or contract, they might just be courteously never mentioned. But given they all take time, rest assured they will be accounted for by the agency in the final cost.
When does Waterfall work?
In software projects - in some cases, projects, this is an approach that still exists.
Especially for large corporations and big companies, who have much larger budgets than startup owners, the government sector, this is an approach that sometimes works. Those types of institutions also usually have internal capabilities (their own specialized teams) that have the skills, resources, and time to prepare extensive technical documentation before the project starts.
The best Waterfall software project documentation I’ve ever seen was some 300 pages long and it was for the front-end part of the application only. It was so detailed that it even included mockups of all the screens of the application with thorough and precise descriptions of the tiniest detail (including the size and colors of buttons).
That is quite different than the Agile approach, where the key is speed, efficiency, and agility. But for organizations with the time, resources, and budgets for this approach - this can actually work.
But in all fairness, we see more and more even the largest companies deciding to choose Agile in software development for all of its benefits. I’ve personally had the pleasure of cooperating with one of the Big 4 Companies on a large Agile software development project. It’s no surprise - Agile is the go-to way to develop modern software for a reason.
So why not put a fixed price on an Agile project?
I’ve personally encountered situations where a client would hear about all the benefits of Agile, but to mitigate the uncertainties, expected to have it wrapped with a fixed price by the agency.
As great as it sounds, just as contradictory as it actually is.
Can you imagine the backpacking travel agency agreeing to cover all of your costs while you get to keep the absolute freedom to change, modify, and extend your trip potentially indefinitely? It’s literally a blank-check situation.
If the scope can change - you can’t have a defined price. If you want to define the scope and price - you take away the flexibility and increase overall costs.
In other words, trying to replace the downsides of the Agile approach with the benefits of the opposite Waterfall approach would be like trying to have the light switch both on and off at the same time. If we can leave quantum physics out of the discussion, I hope you can agree it’s just not possible.
How to get the most out of Agile?
Just as with the backpacking experience reference - start with knowing your budget, the estimated time & cost involved. Be ready to adjust, and use this flexibility to your advantage. Change, adjust, add, remove, replace. React on the go depending on the current needs and situation.
Find an agency that you can trust. One that from the very beginning will have a strong focus on understanding your needs and goals, you will feel that they are operating on the same frequency as you are.
I’d also advise you to make sure the agency you choose has strong Agile Project Management capabilities. You need someone within the project team to help you track and manage the budget, and monitor the progress. Or in other words - to have a person dedicated to minimizing the risks and downsides of working in Agile, while keeping all the benefits.
Because, all in all, Agile has stemmed from the original Waterfall approach due to the major problem it was facing. And this is why the vast majority of software projects today are conducted with Agile methods. Agile is simply the cheapest and 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 to Choose the Agile Framework for Your Project? — Our Senior Agile Project Manager, Paulina Piechaczek explains how to evaluate the method that is best aligned with what you have on the table.
You may also like
We’re available for new projects.
