Scrum does not allow for any detailed planning for longer than 30 days at a time. So how can you make a list of functionality that will be implemented within 3 months? Short answer, you can’t. If you do, it’s not Scrum, nor is it agile.
Old style waterfall planning let’s you promise:
A) “Within 3 months you’ll have this list of functionality fully functional and ready for launch. (insert impressingly long wish-list here)”
Scrum planning let’s you promise:
B) “Within 3 months we’ve shipped three increments of the product. We’ve been focusing only on the most important functionality, so some less important functionality are likely to be missing. But the important ones are there, and they are working properly, leaving your most important and current business goals taken care of.”
History of software development using waterfall planning, shows us that the “A”-promise really is more of a “wouldn’t it be nice if”-statement. It sounds a lot better on a contract, but then that’s also all it does. Research into the software development process has shown us a few things.
- Up-front and long-term planning misses the target as implicit requirements explode once the implementation of explicit requirements starts to evolve. If you’re a developer, you know what I’m talking about. It’s all those nitty gritty requirement details that no-one was able to grasp or visualize during planning.
- A 25% increase in requirements complexity yields a 100% increase in solution complexity. Considering this (not indisputable) fact in addition to the first, it does not take long to figure out why the software development industry is know for its hampering of budgets and deadlines.
Benefiting from the Pareto principle, Scrum lets the less important features (likely 25% or more of the requirements) stay at the bottom of the priority list where they belong. Implicit requirements are added to the list (product backlog) during each sprint. The product owner (the customer) sorts the list by importance, pushing the less important features over the edge and spiraling down into the black hole. This, to some perhaps paradoxically, increases the likelihood of hitting business targets with the most important explicit and implicit requirements considered.
The caveat of Scrum is that upon delivery you have with no more probability fulfilled the list of functional requirements initially provided by the customer (they tend to provide such a list). But considering that we humans tend to wish for more than we can consume, and by following a process that helps us weed out the low priority functionality, it is more than likely that no-one will miss it as it’s never introduced. It has given way for a higher purpose, as the implicit requirements discovered during development tend to root in a higher understanding of the business goals, and are of higher importance than most items in the initial functionality list.
With Scrum (and similar agile approaches), we argue that the product is more likely to be ready for launch, on time, major functionality included. Not necessarily precisely as the initial intention, but closer to the current intention. And most important: Business targets accomplished.
This post is an extension to the recently published list of our reasons for implementing Scrum.
Through the years we’ve been blessed with our biggest customers understanding and cherishing a similar “organic” software growth process, and we’ve have accomplished some great results because of it. Not everyone has the faith and understanding for this process, however. It’s our responsibility to provide the customer with the needed insight and confidence. This is benificial for our customers, and for us. Everyone wants to achieve great results.