The waterfall method of development is as old as time itself. For those unfamiliar, waterfall is a production process in which the development of a product takes place in sequential stages. It has served as a ubiquitous framework for production in various industries. Most notably, waterfall has been the go-to method for development teams in the software industry. In recent times however, time has caught up with the old waterfall process. This once popular software development process is losing substantial ground to more agile frameworks like Scrum. Where waterfall errors, Scrum thrives. Here’s why.
One of the most common criticisms of waterfall is that the process allows for little flexibility. Developers are not able to make changes on the go. In today’s world, a lack of agility can cost a company time, money, and ultimately their business. This is why we at Intronis have bet our own business on Scrum.
Scrum in the Channel
Scrum is a framework that grew out of the Agile programming methodology and Object Oriented movement. Here’s how Scrum ultimately benefits managed service providers (MSPs), VARs – and their customers – out in the market.
Scrum is directly related to the principles laid down in the “Toyota Way” lean manufacturing process. You might ask yourself why and how a manufacturing process could be related to software development, and why Intronis — which specializes in online backup and recovery — would embrace Scrum to run our entire company. We’re about to answer all of those questions. And more.
One of the realities of software development is that requirements change. Sometimes requirements change faster than the project can be completed, and sometimes they change because what the customers thought they wanted was different from what they actually wanted.
How many times have you walked into an ice cream shop thinking “chocolate chocolate chip” and looked at the case and decided on the strawberry cheesecake? How many times have you used a piece of software and said to yourself “wow, this is nice, but wouldn’t it be great if it did this too?” Sometimes what you see just makes what you really want a little clearer.
Inflection Points
Sometimes the market changes too. New competitors surface all the time and old competitors are constantly changing and upgrading what they offer just as much as you do.
A company needs to be able to respond quickly and efficiently to changing customer needs and competitive pressure from others in terms of product offerings and cost if they want to survive. Many legacy companies failed to do this. But here at Intronis, we believe we have found a solution to this problem: Scrum.
The whole idea behind Scrum is iteration and small steps that deliver real business value. So instead of focusing on the “Big Picture” while trying to implement the entire project with all items defined beforehand, Scrum starts with the truly American idea:
“How can I do the least amount of work and deliver the most value?”
Slyly, this doesn’t actually mean working less, it just means working RIGHT. We believe that, while thinking of the “Big Picture” is important, it isn’t as important as developing software that your customers really want and find it ridiculously easy to use. It follows that our customers — MSPs, VARs and businesses — will know what they want as they see it, and developing software is as much of a partnership with them as it is an engineering feat.
We believe that trying to do it all up front in the traditional waterfall method doesn’t work when your partners and customers are the focus, and the market is constantly changing. In order to get it right, you have to be agile in the true sense of the word, and Scrum provides the way to be truly agile.
Mark Hatch is VP of software development at Intronis. Guest blog entries such as this one are contributed on a monthly basis as part of The VAR Guy’s 2009 sponsorship program.
Read More About This Topic
Share This Post
Tags: Intronis Scrum | Scrum for SaaS | Scrum Software as a Service | Scrum software development | Scrum vs. Waterfall
Interact: Add a Comment | Trackback Link | Permalink
Subscribe: RSS Feed

Check out http://www.agilebuddy.com/ Pretty much all the Scrum tools you need to manage anything.
Andrew: Quick questions
1. Do you work for Agile Buddy?
2. Also, do you agree with Mark Hatch’s views on Scrum vs. Waterfall?
Thanks for stopping by.
-TVG
No I don’t work with AgileBuddy it is just a great toolkit, and to your second point ~ if you aren’t using Scrum and your competition is, you will soon be working for your competition..
Andrew: The VAR Guy thanks you for your answers. Short and sweet and on the mark. Thanks.
Sounds like a new name for the old incremental development/rapid prototyping idea. So what else is new? I’ve been doing software development for clients in this way for over a decade: get some initial rough specs, go away for a couple of weeks, show them an initial working prototype based on those specs, get refinements and corrections, wash, rinse and repeat.
That way the client gets the reassurance that progress is being made, and they are happy to pay my monthly invoices.
Since we manage several development teams on a global basis, we use a system called Version One. It allows us to manage multiple teams very easily and also makes the roll-up reporting less of a hassle. It also helps when everyone is pulling from one common backlog. If your scumming in a more localized way or just beginning, Pivotal Tracker is good, and we used that here to get up and running.
This isn’t really incremental development. The Product Owner can set the stories and the priority but doesn’t get to set the time or committment. Only the team can do that. It’s the crucial point, and why scrum is so successful. Once velocity is established it makes hitting your deadlines a certainty, not a guess. And customers love hit delivery dates! Development may be interative but, in essence, scrum is a framework for hitting the release with the most value.
Re Mark Hatch: “This isn’t really incremental development. The Product Owner can set the stories and the priority but doesn’t get to set the time or committment. Only the team can do that.”
That doesn’t make any sense. A business arrangement is a two-way bargain. Both sides have to commit to that.
“Once velocity is established it makes hitting your deadlines a certainty, not a guess.”
That’s getting scarily close to market-speak. Deadlines are far from a certainty even in non-software-development projects, how can you seriously expect that claim to be credible in software development?
Can someone help with 2 questions:
How in the Agile/Scrum process is “the big picture” reinforced while focusing on immediate and small (daily) tasks within the sprint?
How in the process to distinguish between the important and the urgent?
Thanks,
Stephen (Newly adapting Agile/Scrum)