This is the 2nd article in our scrum vs. waterfall series — where we analyze how each methodology affects the various aspects of software development through illustrative case studies built upon our very own experience with startups.
In our last article it was discussed how scrum and waterfall apply to the development of a mobile app in the health & fitness space. And it’s in this blog post that we’ll focus on effective software project planning for a startup that’s posed to be the Uber for masseuse and beautician services.
John is a serial entrepreneur and venture capitalist with a series of startups. And the latest startup that he’s backing is determined to create a marketplace for bringing salon and masseuse services directly to the customer.
John and his two-man team of engineers are looking to build a mobile-friendly web platform to power their Services Marketplace (SM). The budget for the project is $100,000, and John wants their official launch to take place within 5 months’ time.
Between developing the platform reputation system and determining the booking engine to be used — building a software based peer-to-peer SM comes with many challenges. So how do you even begin to plan such a project? And between scrum and waterfall, will either methodology be an obvious choice?
The choice of scrum or waterfall isn’t as simple as it’s sometimes portrayed. A small team isn’t the sole factor for deciding on scrum, just as how waterfall shouldn’t be the default choice for large organizations.
So in the case of John’s startup, we’ll want to focus on three key aspects of his project: the requirements of his marketplace platform, the budget involved, and the level of communication between project stakeholders and engineering.
John knows there will be many market factors that will later drive product decisions for his startup’s marketplace platform. But for their launch, he has a firm understanding of what key features need to be spec’d out. These include:
When it comes to selecting the software methodology that will produce the best time estimates for John’s startup project, waterfall holds a slight advantage. This is because its emphasis on upfront project planning can produce far more accurate time estimates than scrum’s.
On the other hand, the platform will initially be exposed through a website to end-users, which means a low cost per change. So while scrum may produce less accurate time estimates, there is little downside to requirement changes. Whereas the waterfall process can lead to higher friction if project specifications were ever to change.
John has a strict budget of $100,000 for the initial launch of the software platform that will drive the peer-to-peer marketplace he’s creating for beauticians, barbers, and masseur services.
If budget is of primary concern, scrum is ideal since it allows for greater flexibility regarding a project’s feature set. As when code modules are developed, tested, and released individually, a decision to cut a feature will have a limited impact on the project.
Yet going over budget could kill John’s startup altogether. So if John believes that he can accurately define the MVP he’s looking for, waterfall’s disdain for feature creep can help to keep the project on track. And the upfront planning approach of waterfall can also produce more accurate cost estimates than scrum.
If scrum is to succeed at any startup or organization, team communication needs to be strong. A tight communication loop between team members is what enables fast iteration between planning, development, and software testing. So product managers cannot be siloed away from developers if scrum is to succeed.
Yet at the moment, John is managing several startups. Leaving John with just 10–15 hours a week to collaborate with the engineering team of his peer-to-peer (p2p) based marketplace startup. And this presents a large hurdle for effectively implementing scrum.
So until John is able to hire a full-time product manager, waterfall holds an advantage over scrum when it comes to the product planning for his startup.
“Waterfall” is synonymous with a traditional approach to software development. Completing one phase (e.g. planning) before moving on to the next phase (development, testing, etc.). By contrast, scrum attempts to minimize project risks by taking an iterative approach towards software development. And each method has its uses.
In John’s case, waterfall is the ideal choice for his p2p marketplace platform. This is because he has a strict project budget, a well-defined scope, and for a temporary period — poor team communication. On top of that, if he’s unable to complete his project within budget, all of the individual software modules that scrum’s iterative approach could produce would be worthless.
Though once the first iteration of the marketplace platform is released and demand is proven, John’s startup may want to change their software development approach. Releasing small individual features could be ideal in the startup’s future, and thus justify a switch to scrum. Because as a startup evolves, so does their approach to software development and planning.
And what project requirements are you finding most challenging to manage through either scrum or waterfall? Share your use cases below.