After discussing both scrum projects and the waterfall software development model here on our blog, we’ve been noticing startup clients coming to us not knowing what methodology best aligns with their unique projects.
Understanding the fundamentals of both scrum and waterfall is necessary. But we can go another step further. And that’s to cover the startup challenges that have influence on the effectiveness of both scrum and waterfall.
So we’re kicking off our new article series on scrum vs waterfall software development methodologies — by analyzing how each methodology affects the various aspects of mobile application development, through an illustrative case study built upon our very own experience with startups.
Introducing Jane and Her Startup Challenges
Jane is the founder of a tech startup within the health and fitness space. She’s building a mobile app that tracks the daily food intake, water, and exercise of her users. And both Jane and her technical co-founder will be working together to release a minimum viable product (MVP) version of their Android and iPhone app within four months’ time.
Jane faces several business challenges. First, neither Jane nor her co-founder can predict with high confidence what features will be embraced by their target audience. Then there’s her limited budget, as additional investor funding is dependent on the performance of her initial product launch. And lastly, this leads to Jane’s aggressive project timeline, that will limit the feature set that can be developed for her mobile application.
So what software development methodology will best fit the needs of Jane’s startup? Scrum or waterfall? Let’s answer this question through examination — as we analyze the different aspects and constraints of Jane’s mobile application project.
Project Requirements
Jane knows what core functionality is required of her mobile meal tracking app. She knows that her users want the ability to determine the nutritional value of an immediate meal. And she knows that the social sharing of daily exercise and food choices can have a positive effect on making healthy decisions. But what’s fuzzy to Jane is how to go about tackling all of these features in the most effective way.
For instance, Jane is considering the use of a third party service that can derive the nutritional information of a meal through photo analysis. Yet integrating this service is technically complicated and requires a significant upfront cost.
If Jane were to use the waterfall methodology, the extensive requirements for her product features could be determined in advance. The fruits of this effort being a realistic estimation for the time and money necessary for development.
But no matter how much planning Jane and her CTO put into their project requirements, their users will ultimately reserve the right to deem a feature impractical or uninteresting.
So in contrast to waterfall, Jane could divide her large mobile application into separate software modules or “features” through the agile approach that scrum prescribes. Within two weeks’ time (a sprint), Jane could plan and build a “phase one” of a nutritional tracking module. Phase one could simply email meal photos directly to Jane’s inbox, so that she can manually look up and enter nutritional information. While this implementation will not scale beyond a few hundred users, it will give Jane the insight she needs for determining if it’s a feature worth investing in.
The Cost per Change
In the later stages of software development, a project’s cost per change (CPC) comes into play. It’s the cost of making a software change, when the original solution developed was imperfectly implemented. In Jane’s case, this could be finding out that the capturing of meal photos crashes her app on a particular Android phone.
When the increase in cost per change is rather slow (see the red area in the graph above), the consequences of imperfect project planning lessen. A low CPC example would be correcting a styling issue for a webpage.
On the other hand, if a project’s cost per change increases exponentially as time progresses (as depicted in the green area of the graph), the time invested in planning has a greater payoff. An example of a high CPC would be deploying a software update for an air traffic control system.
As a general rule, scrum is a best suited for projects with a low CPC, and waterfall holds an advantage when CPC is high.
While no lives will be in danger if Jane’s mobile application needs to be patched, there are various negative aspects of her project’s cost per change that she needs to consider:
- Apple’s App Store approval of updates take significant time.
- Users with limited data connections or phone storage will be slow to adopt software updates.
- Each change to the native version of Jane’s mobile application must be developed and tested for both the iPhone and Android.
As there’s a moderate cost per change for Jane’s mobile application, waterfall holds a slight advantage over scrum.
Time to Market
Jane requires a fast time-to-market, as her mobile application needs to go live within a timeframe of four months.
The upfront planning that waterfall relies on will pose a challenge for Jane’s aggressive timeline. While waterfall is capable of providing accurate estimates for complex applications, it’s more important to Jane that she releases a MVP within her schedule — even if desired features will have to be dropped.
Scrum fits naturally with Jane’s time constraints, as it allows for software modules to be individually developed and tested within short periods of time. As her deadline approaches, she can maintain an accurate perspective of what features can be included in her startup’s MVP release candidate.
Scrum or Waterfall?
Software development methods are not inherently good or bad. It all depends on the nature of your startup projects. And given the project requirements, the cost per change, and Jane’s aggressive timeline, scrum is simply the most appropriate choice for her mobile app startup.
What project requirements are you finding most challenging to manage through either scrum or waterfall? Let us know by commenting below.
