From Waterfall to Agile

 

When we began BiTE, we were a fixed price/scope studio. And while we were small, this model worked. Mobile was in its infancy, so projects were relatively straightforward. During these early days, we could grind out change on nights and weekends even if it wasn’t ‘in-scope.”

Fixed Scope Pitfalls

But as mobile started to grow in scope, complexity and budget, things changed. Fixed price projects were losing money, endless long hours and weekends were burning out our people and (worst of all) change orders and date slippages were infuriating to our clients. Often, clients simply could not get more budget to approve a change order. Schedule slippages were unacceptable, since they threatened hard deadlines. And scope, as we said, was fixed with the assumption that everything would go as planned. But of course, we all know the only guarantee in any project is change.

Exploring Agile

We needed find a way to run BiTE and still meet our clients’ most important objectives: quality software on budget and on time. So we moving to an Agile model. We fixed time and resources and kept scope dynamic. With fluid scope we eliminated change orders. Since resources and duration were fixed, we met clients’ budgets to the penny without threat of overages. All this while never, ever missing a release date. Because the highest priority items were always built first, the client got their “must-have” features. And if time and budget were insufficient to get every feature into one round, the lower priority items moved to a future release.

The Results

Agile made us fast. Agile made us adaptable. And Agile provided our clients with assurance that release dates would be hit each time and costs were certain. It aligned our internal goals with those of our clients and most of all, Agile helped us build better mobile apps. As mobile and the needs of our clients change, we continue to grow and refine our Agile implementation.

You Might Also Like…

The Line Between “What” and “How”

Introduction A pervasive problem in software development is finding the line between what is a sufficiently detailed description of a product requirement and describing the "implementation details" of that requirement. Put simply; it is a problem of finding the line between what and how. A product requirement should contain everything about the "what" (and leave …

The Line Between “What” and “How” Read More »