In the old days of building software, you would discover, document, design and build an entire set of features before letting a user actually use the software.

This Waterfall model was supposed to be the most effective way to develop software. But we learnt its limitations first hand when we started using it.  It created a false sense of security.

We used to think that it reduced risk because if you knew all the requirements up front, you could accurately estimate the time and effort needed to build software.   Waterfall assumes that you can’t start until you know everything you will need to do, in great detail.

We found the opposite to be true: projects took longer, were most expensive, and were riskier than anticipated.   The requirements we originally specified were usually far from what we actually built.

Why? A few reasons:

• The list of  “must-have” requirements is long at the beginning of a project
• Users take forever to sign-off on requirements, because they do not want to miss anything
• Incorrectly interpreted specifications and time lags resulted in expensive re-work

We took a different approach with Rypple.  We decided to be Agile.  We studied the methodology, and most importantly, practiced it, to get better at doing it.

The more we use Agile, the more we are convinced it’s the right approach.

There are many excellent resources to get you up to speed. Our favorites is by Mary Poppendieck.  We met Mary at our last company and she’s a great inspiration for learning by doing.  We’d be remiss if we didn’t link to Mary’s suggested #1 book on the subject of Agile (it has nothing to do with software – it’s about building cars).

Agile forces us to:

• Break features into small and manageable chunks
• Start with the user experience (user story), not the screen design
• Minimize excess inventory and waste by not focusing on future features too early
• Get user input early and often

This approach initially made some members of our Rypple team anxious. They’re now Agile evangelists.   We now embrace Agile and all that it can do for us. We are most thankful that we don’t spend too much time trying to forecast the future accurately. We embrace user feedback so we get each small feature right.

Agile is a journey that we are on.  We continue to learn and improve our approach with what works for Rypple.

Agile means we’re already working quickly to deliver a constant stream of features that our users actually want and actually use.  And that feels good.