An oft-repeated mentality in not just software development, but throughout startup culture in general has been that agile or Scrum are universally better approaches to product creation and we should all embrace it with open arms. I whole-heartedly disagree, but before we get into that, let’s talk about what these methodologies actually are and where they came from.
The waterfall model, like other software development methodologies, has its roots in large-scale manufacturing of complex goods, like construction projects. It has a planning phase in which every aspect of the project is defined, and a development phase where the implementation of that plan happens, and it concludes in a delivery phase where the final product is released and the process begins anew. At its core this is how large-scale projects have been done for centuries, and it’s completely rational. But, the requirements of the project must be known in their entirety up front, as well as any constraints because once the project gets going, it’s too late to make changes.
Agile was created specifically to address the shortcomings of waterfall in software development, and it really started to ramp up with the adoption of the internet. Agile essentially restructures software such that the software is not the end product.
If we think about another manufacturing process that parallels waterfall, say building a house, the product is the house. It’s delivered one time, at the end of construction, and the customer has no ability to extract any value from the product until it is finished. In the early days of software this was exactly how it worked. A team would work away on a project until it was finished, at which point they would get it printed on disks and distribute to customers.
With the widespread adoption of the internet in the late ’90s things started to change. Suddenly, software could be distributed incrementally with downloadable updates. Fast-forward a few years and most software shifted to a Software as a Service (SaaS) model. In this environment, the software as a whole is no longer the entirety of the end-product, rather it becomes a platform on which features, mini-products if you will, are continually being delivered over time and each one is capable of immediately providing value to the customer.
Now that we’ve changed the definition of the end-product from a single, complex deliverable to many iterative deliverables, the methodologies used by large, complex manufacturing processes no longer make the most sense. Instead, the industry began to look at manufacturing processes with shorter lifecycles and higher volume of output, like the Japanese auto industry. In these environments, the opportunity to continually improve both the product and the process with each new unit produced is possible, and while we still certainly need a plan, we just need a plan “good enough” to get us through the first few cycles. After that, we can learn from the inefficiencies of the process and improve over time.
So agile is incremental, continuous, and requires a different delivery model in order to be effective.
Scrum is a framework for the application of the agile methodology to software projects. There are other flavors of agile, but Scrum has become one of the most popular, and for good reason. Scrum has a few basic tenants:
- Work is completed in consistent intervals, called sprints.
- Features are called stories, and every story in the backlog must have a level-of-effort estimation.
- Over time teams can better gauge how much work they can complete in a sprint by measuring velocity, the average number of story points completed in all past sprints.
- Every sprint has a kickoff, during which the stories to be completed are defined and dependencies are named, and a retrospective, where a team can learn from successes and challenges of the sprint.
- Daily standup meetings keep communication flowing and hold team members accountable.
The benefits of Scrum are numerous, but as a product manager the key benefit for me is in its planning capability. When we departed from the waterfall approach planning, in particular long-term planning, became extremely difficult. With Scrum we can track our velocity, break work up into estimate-able stories, and have a reasonable game plan for how we can split those stories up over time.
Methodologies are just tools. Use the appropriate one!
Scrum / agile has been a game changer in the product development world, not just in software. It’s been adapted over time to address the needs of particular hardware products and even services with success. But let’s keep in mind these methodologies are just tools, and as tools they have appropriate and inappropriate uses.
Just like we would never build a house one room at a time (and let the residents dwell in the completed rooms), some projects—even in software—simply don’t lend themselves to agile.
Where agile doesn’t fit
If the product development lifecycle has a fixed end
Agile relies on continuous development in order to be effective. It’s the embodiment of “better done than finished” and as such, requires successive iterations to improve on the things that aren’t up to par.
If the delivered product can’t easily be updated
If you can’t update your product after it’s released into the wild, you can’t really use agile. Sure, you can adopt agile-like processes to work towards a fixed release date, but once you cut a release there’s no going back.
If the scope of the project is fixed-in-time and wholly known
One of the fundamental concepts in agile is that project scope is minimally defined and is variable, meaning it changes over time. If your scope is completely defined and won’t be variable, the up-front effort to plan every phase of development won’t be wasted as it would be in agile. In fact, if the scope isn’t changing at all it’s much better to plan and optimize the entirety of the development lifecycle in advance to eliminate risk and uncertainty down the road.
So to wrap up, I believe most software projects these days are great fits for agile, and Scrum is a really solid framework to follow. If you would like to learn more about Scrum and how to implement it check out Scrum Guides, a resource from Scrum’s creators.
If this resonates with you I'd love to help!
I help business with problems like these every day.
Click below to schedule a call.