This is for corporate managers or consultants, who plan to develop some software with an external team (means via an agency).
Agile does not mean fast!!
It often is, but there are also cases where it is not (e.g. if you have a lot of change requests).
This, however, is a common misunderstanding with managers, who think they know what it is, but do not.
In very short terms, AGILE refers to methods, where it is all about communication, flexibility, and getting the best quality, the fastest way, to a happy client. See the Agile Manifesto here.
Also mind that agile does not necessarily mean to use any type of Scrum!
WATERFALL, on the other hand, refers to the well known process, where the client defines, what he/she wants, the development team then spends a lot of time writing down every detail of it, this proposal gets signed by the client, the software gets developed, and finally shipped.
If someone forgot about something in the beginning, if the market or business case has changed, or anything else occurs, a new project for a new software version would be required.
Now that this is clear, let’s have a closer look at AGILE vs. WATERFALL when working with external development teams.
Internal Product Management
With an internal product manager, who steers the project, you should always try to go agile, because it is the more natural way of doing those things.
Software development cannot be compared to buying some machine. It needs to be compared to an R&D project.
Still, the risk for budget, time, and quality is all on your side.
In this scenario, you have basically only outsourced developers. If you do not have an internal development team, this is the maybe best setup.
External Product Management
Without an internal product manager, we are talking about buying the whole process from an external team.
The risk is now on their side, but mind the project types (the “client” is you):
Agile
Working with agile methodologies is often (not always!) faster at a way higher flexibility.
You also often receive higher quality, because the team can implement new learnings along the way.
Usually the result is also closer to your expectations, because of this flexibility.
Timing can be critical whenever something comes up new or changes.
Mind to include huge buffer for deadlines here.
Costs are lower, when compared to doing the same project with a Waterfall methodology.
The downside here, it is not possible to calculate the budget fairly and complete up front. I know, this is the nightmare of every controller, but the price to pay for a lower price at higher quality.
Process:
Mind that this is only a rough overview of a sample process. Especially at agile approaches, you have plenty of possibilities to tailor it to your needs.
- Research:
Finding out more about the users and sometimes even the market and business case. - Requirements Workshop:
Defining the overall requirements. - Concept:
Defining processes, the general architecture, the work streams and steps. Sometimes even the UI and design. - MVP Development:
Getting fast to a first version. This usually happens without larger adjustments during development. - MVP Test:
Testing this version against the market or at least the clients expecations. - Fine-tuning Requirements:
Adjusting requirements based on any learnings or changes. - Concept Update:
Updating the orginal concept and strategy, where necessary. - Agile Development:
Enriching the MVP with more functionality and features, while keeping close contact to the client, challenging every step and quickly adapt to changes and learnings. - Launch of Version 1 — usually followed by some kind of further ongoing development or at least maintenance. Sometimes, that’s where the project gets handed over to another (internal) development team.
Compensation and Planning:
- Pay as you go.
- Pay as you go with a monthly and/or weekly cap.
- Pay a fixed monthly or weekly fee, but without having a distinctive project deadline. The team would work untill money runs out, than wait.
Waterfall
A good waterfall software project requires at least two separated projects.
One part, where you determine the requirements (often combined with market research) and develop a concept for the second part.
At this second part, the concept gets build.
If this is done within one step at one price, you are either paying way too much, got lucky and found an inexperienced agency (do you want this?), or get really poor quality and results (that’s the most common consequence).
Such projects usually take longer (at least for the first version).
You often do not get what you expected and there is no flexibility to change anything in the plan until it is done (unless stopping and restarting the project with new cost, which basically is somehow agile, but more expensive). Budget will always be met, as long as you do not need any changes — usually you do. The same applies for deadlines.
However, those projects often come at poor quality, because clients lower the price in advance, which leads to the development team skipping some important steps in the background.
You always get what you pay for!
Process:
- Initial Requirements Assessment:
Defining the basic needs of the client. - Proposal:
A price for (hopefully) only part 1. If you asked for it, you will get a price tag for all parts. - Proposal Adjustment:
You want to kill some parts and negotiate about the price, until it is accepted. - Part 1:
Usually a lot of workshops to derive all requirements. Requires a lot of work from both sides. The development team will also already evaluate all technical details and execute some tech tests on the more complicated parts.
In the end, you receive a concept. - Additional Proposal for Part 2:
If you had no one before, you will receive it now. If you had one before, you might receive a new one here, if something has changed (except, the changes are in favour of the development team). - Part 2: It gets build. Usually without any chance for you to interfere.
In the end, you receive the final product, often combined with documentation and training. - Adjustments:
90% of all cases, you are not happy with the results and need to ask for additional adjustments at additional cost.
Compensation and Planning:
First part:
This should happen with a lot of workshops and adjustments. You should rather add a part 1b, if you need more time, than moving too fast. All projects, which I know of, that skipped additional conceptioning here, experienced huge problems in the end (missing functionality, wrong strategy, poor quality).
So, a fixed price is possible, but also think about paying per hour — maybe with a cap.Second part:
If the first part went all the way to a full-blown detailed concept, you can get a 100% fair fixed price here.
If the first part was fixed, you should expect some problem here (too expensive or poor quality).Mind the additional costs of follow-up adjustments, because hard cuts (budget and time) almost always lead to not meeting your expectations here.
Funny thing: Most controllers see Waterfall as the option, which is easier to calculate. Truth is, it is easier for them, but in terms of time and money still worse for the overall business.
Decision Helper
The following graphic can guide through your decision process.
Pro Tip
This even goes out to experienced managers!
Always tell everybody that technology projects never work out as they are expected to do first.
Even this is not true in the terms that you are experienced, know what is coming at you, and only if planned and executed properly, this saying provides you with some more freedom — and you will need this freedom, because many people will still believe, creating a from scratch software is the same as buying a printer 😉.
