When it comes to choosing the optimal development model for a startup project, there is absolutely no unanimity of opinion on the subject. On the one hand, startups are not exactly the wealthiest companies and typically depend on external – and limited – funding from investors. Therefore, there is a budget cap that the selected developer must keep in mind and observe. On the other hand, the very nature of a startup business suggests that the functionality, business model and multiple other aspects of the product are described very superficially and often reside in the heads of the ambitious startup founders. This naturally makes firm commitments very hard to make, if at all possible.
The choice of the very best approach to developing an innovative product, therefore, boils down to weighing multiple factors that may affect the outcome and defining their priorities. For example, here are some of the most important things that should be taken into account while deciding which avenue to follow:
- Budget constraints
- Timeline (presence of hard deadlines, critical milestones)
- Business plan
- Type of product
- Product architecture (scalability, expandability, workflow linearity)
Let's take a closer look at these factors in the context of a startup project.
Budget is always an issue. However, with no hard cap on the amount of money that can be spent on a product, agile development becomes a much more attractive option. An agile approach adopted from day one gives the team the flexibility they need to adjust to the constantly evolving vision of the product and shuffle the backlog as they and the product owner seem fit and appropriate. However, without a solid execution plan and ongoing supervision, this process can enter an uncontrollable state and start burning money without producing tangible results.
The bottom line is that an agile approach will work very well for projects with flexible or semi-flexible funding. The Waterfall model may work for a certain part of a project that has a set budget, but the mandatory analysis phase will inevitably delay the start of development.
Time is an integral part of the money-time-scope triangle that is found in every project. However, it is not uncommon that it’s not the absolute amount of time that is important, but the intermediate milestones. For example, it may be required that the project be started immediately, the first clickable prototype be delivered as quickly as possible and the MVP version rolled out by a particular event. In this case, a long initial analysis and requirements exploration phase could ruin the product owner’s plans and jeopardize the completion of the project in time. In addition, there could be (and most probably would be) multiple changes along the way that the Waterfall model would not be able to handle.
Summary: if timing is critical, Waterfall is hardly an option. If the timeline is defined by the product owner and there are no dependencies, Waterfall may be an option worth considering.
This aspect of a project’s biography is tightly interwoven with the previous one. By definitions, startups are companies embarking on the creation of something completely new. “New” implies uncertainty and risks. Therefore, startups operate in a dynamic, high-risk environment where functionality and even the business model are being constantly adjusted and re-aligned with the expectations of investors and the target audience. Under these volatile conditions, developing a pilot project from A to Z using the Waterfall model may be an adventurous undertaking bordering on financial recklessness. However, it shouldn’t be swept off the table altogether – it may still work for a certain milestone, such as a MVP version to be demonstrated at a show or presented to a board of investors.
Type of product
Not surprisingly, even the type of the product being developed matters and has a lot in common with the business plan and timeline aspects that we covered above. Think of a modular content-driven application or online service that can be released with minimum functionality and then wrapped into more and more layers of features and enhancements. This concept falls well into the agile framework and enables the team to make meaningful incremental deliveries over a long period of time. The owner has full control over spending and can pull the plug at any moment without compromising the functionality of the core product.
In comparison, if our product has a less atomized structure and its features are closely intertwined, there may be less room for iterative delivery. In this particular case, it may make sense to have a proper requirements elaboration stage first and then proceeding under a Waterfall model.
Largely coinciding with the point above, this characteristic of a product defines the complexity and cost per change. If both are high, using the Waterfall will exacerbate the pains of making architectural changes in a product that could be implemented at a much lower cost and at an earlier stage if an agile approach was used. If the architecture of the product and its main business flows are relatively simple and linear, the cost per change may be relatively low. However, as the complexity goes up, so does the effort and cost required to make a change while the team advances along the development timeline towards completion.
The choice of the right project management methodology and approach to product delivery have always been a fertile soil for argument and thoughtful analysis. Prioritizing flexibility and control over cost may work in some cases but fail in others. Conversely, detailed analysis of requirements and steady progress towards predefined milestones may benefit a large number of projects and customers that require a fixed budget and timely delivery.
Agile and Scrum in particular seem to be the most natural choice for startups working with or without a budget cap. However, certain parts of their projects can be delivered under fixed-price contracts using the Waterfall method – for example, relatively simple prototypes, technology demos or MVP’s.
Cortlex is ambidextrous in terms of development methodologies and can use agile and conventional Waterfall techniques with equal efficiency. If you are not sure which approach is the right one for our upcoming project, we’ll be glad to hear you out and propose the optimal action plan based on our multi-year experience in software development.