At Kenoobi Consulting 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 in this article we are 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 Nyambura and Her Startup Challenges
Nyambura 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 Nyambura 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.
Nyambura faces several business challenges. First, neither Nyambura 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 Nyambura’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 Nyambura’s startup? Scrum or waterfall? Let’s answer this question through examination — as we analyze the different aspects and constraints of Nyambura’s mobile application project.
Nyambura 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 Nyambura is how to go about tackling all of these features in the most effective way.
For instance, Nyambura 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 Nyambura 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 Nyambura 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, Nyambura 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), Nyambura could plan and build a “phase one” of a nutritional tracking module. Phase one could simply email meal photos directly to Nyambura’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 Nyambura 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 Nyambura’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 Nyambura’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 Nyambura’s mobile application must be developed and tested for both the iPhone and Android.
As there’s a moderate cost per change for Nyambura’s mobile application, waterfall holds a slight advantage over scrum.
Time to Market
Nyambura 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 Nyambura’s aggressive timeline. While waterfall is capable of providing accurate estimates for complex applications, it’s more important to Nyambura that she releases a MVP within her schedule — even if desired features will have to be dropped.
Scrum fits naturally with Nyambura’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 Nyambura’s aggressive timeline, scrum is simply the most appropriate choice for her mobile app startup.
Need help to choose either scrum or waterfall? Let us know by writing an email to consulting(at)kenoobi.com