Planning to hire an external developer but not sure whether to pick a team that will follow a waterfall or agile development approach? Read on for expert advice.
Innovative visionaries, product evangelists, extreme problem-solvers, tireless fundraisers … today’s startup founders must wear many hats.
But it turns out there is at least one more they often need to fit into their wardrobe: the hat of wise development team chooser. And it’s not an easy one to wear.
For a technology startup, whether it builds products or software as a service (SaaS) solutions, there are at least two significant decisions to make. The first is which developers to hire, and the second is which development method to utilize for the project.
As I will explain below, these are not only technical decisions, but decisions that are vital to your company’s very existence.
Where to Start?
As is probably obvious, not all startup founders are programmers, not all of them know how to code. But if their dream (or their plan, to be more precise) is to build a company around a software product, they need to understand the various ways in which software can be built and decide which approach is best for their business.
The choice is not trivial and depends on how you answer the following questions:
- To what extent do you actually know how your product is going to look and behave?
- How much involvement do you want to have in the software development process?
- How much do you trust your developer team?
With these questions in mind, let’s take a detailed look at two of the most common types of software development: Waterfall (traditional) and Agile (iterative).
Waterfall (Traditional)
Waterfall is a linear approach to software development.
That means that project stages are executed sequentially, and no stage can begin before the previous one is finished. You receive your completed project, fully developed and tested, at the very end of the process.
Specification
The first stage of a waterfall process is gathering requirements for the whole system. That means that before design starts, you’ll need to determine how the application will look and behave.
Beware! For waterfall, it’s not enough to say that you want to build a clone of another web or mobile service. All features should be listed in the agreement you sign with your software developer. For some startup founders, this can be an extremely difficult task.
More than once or twice, we talked to clients who were convinced they explained everything in a short brief. But your project is much more valuable than just a brief, and your software team needs to understand it as well as you do. So be prepared for hundreds of questions and diving deep into the details, much deeper than you probably ever expected.
On the other hand, the advantage is that when development finishes, you’ll be able to easily determine whether the product you received is the one you wanted in the first place.
Involvement
You already spent a fair amount of time at the outset gathering project requirements. Are you sure you have enough of it to be constantly involved in building the product? The good news is that, if your software company uses waterfall methodology, you won’t have to.
Because of the thorough collection and analysis of requirements at the beginning, it should be clear as day what should be developed and when. Apart from approvals, reviews, and status meetings, your presence will not be needed after the initial requirements stage.
Trust
For a waterfall project, the most natural way to structure payment is fixed price.
You know exactly what you want, developers know exactly what to do, and the deadline is set, so you can easily agree on the cost. Therefore staying on a strict budget shouldn’t be a problem at this point.
But remember, once development starts, you won’t be able to add a single feature without adjusting the budget. And if it turns out that your requirement analysis wasn’t thorough enough, you will end up paying a fixed price for a project that doesn’t match your needs. That’s the risk.
All in all, traditional ways of building software are a good match if you want to build an MVP and you’re 100% sure of all the requirements it has to meet. It can be tricky for mobile apps when operating systems change frequently and often entail rebuilding the app to some degree to match the newest system release. For short projects (up to two months) with clear expectations, though, waterfall seems to be a good fit.
It is interesting to note that all of our clients came to us with fixed-price projects initially, but as their software grew, the approach became more flexible. Now 90% of our projects are developed through an agile process.
Agile (Iterative)
Agile development, as opposed to waterfall, focuses on building software iteratively, according to principles of the Agile Manifesto.
The project is divided into small modules (the smaller, the better) and delivered in weekly or monthly sprints. During each sprint, a certain functional set of features is developed, tested, and delivered to you for evaluation. This approach emphasizes rapid delivery.
Specification
With agile software development, it’s not necessary to have all of the requirements collected in the beginning. What is done in the initial phase is collecting all known requirements in a project backlog and translating them to user stories (what you need) and tasks (what developers are to do).
This process is usually done through a project management tool such as Pivotal Tracker (paid) or Taiga.io (open source). Keeping in mind that you can broaden your project scope at any time, developers need to build the product in a very scalable way. In agile software development, teams usually use Scrum or Kanban as their agile framework.
If you look for agile derivatives, you’ll also come across Lean Software Development. It comes from Lean Manufacturing, which was created by Toyota to eliminate waste in production cycles. Mary and Tom Poppendick adapted the concept to fit software development. The idea is not only to be flexible to change and proactive (as in agile), but to focus on what brings value to the project and eliminate every activity that doesn’t add value.
Involvement
The agile approach requires you to be involved in the process as much as your developers are. Communication between you and your software team should be clear and quick because time is a resource that one doesn’t want to waste.
Your project can always be “in move” and you are able to change, switch or add requirements to upcoming sprints. That’s where the true flexibility of agile development comes from.
Trust
This approach is for startup founders who cherish relationships and trust more than anything else.
Sounds crazy? Not at all. Being able to trust your software company doesn’t mean that you say what you want and they do what they want. Your project is not left alone because of your involvement.
Besides, since you usually pay for time and materials at an hourly rate, you can resign whenever you’re not satisfied with the outcome. As a result, the overall financial risk of choosing the wrong team is smaller than in waterfall where you pay when the project is ready.
Don’t go chasing waterfalls if your product and business are going to evolve with your customers. By having an agile development team, you can adjust whole modules of your application in the process of building it.
In a nutshell: you can make it better before it’s even released. The approach is perfect to develop an MVP for early stage customers or for a market you’re still learning about.
One Size Fits All?
So which approach should you choose as a founder? The honest answer is that it depends.
If your budget is limited, think about whether it’s possible to have your product developed at least to the MVP level that satisfies you. Can you afford paying all the money to the team you’ve just started working with?
How much time at each stage would you be able to devote to the project? If you’d rather be thoroughly prepared from the beginning, gathering specifications, getting to know your market, preparing application mockups, then waterfall might be the right approach.
If, on the other hand, you’d like to cooperate with the developers on a daily basis and evaluate the software frequently, the agile approach will probably be closer to your heart.
Of course the world of software development approaches doesn’t end with just those two. Many founders reach an understanding with their software team somewhere in the middle. That’s OK as long as everyone’s happy.
Either way, don’t rush. Choose the best fit for your personality, talk to different software teams, let them show you the way they work and the results they obtain.
But most of all, never hesitate to talk to your developers’ previous clients. After all, they’ve already worn the hat you’re about to put on.
Image Credits: Pixabay.com, Pixshark.com
