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.”
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.
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.
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.
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 …
Los Angeles
750 N San Vicente Blvd
Suite: Red West 800
Los Angeles, CA 90069
(310) 935-1581
Montréal
1275 Avenue des Canadiens-de-Montréal, Montréal, QC H3B 0G4, Canada
(514) 900-4830
Minneapolis
225 South 6th St,
Minneapolis, MN 55402
(612) 800-0995
San Diego
600 B St.
San Diego, CA 92101
(612) 800-0995
© 2023 BiTE Interactive. All Rights Reserved.