At Oak City Labs, we’re an “agile shop” meaning we practice a project management methodology known as Agile, the specifics of which are interwoven throughout our relationship with each client. Most of our clients are entrepreneurs and organizations that are coming to us with a brand new app idea and don’t always have a background with software development projects. The words Waterfall or Agile, Sprint or Backlog often need explanation.
Waterfall vs. Agile: What’s the Difference?
Waterfall
Via
The waterfall methodology is exactly as sounds: linear. One phase in the process happens after another after another until the project concludes. From the onset of the project, each phase informs the next and must be completed before the project can proceed. If we were developing an app using this methodology, the project would begin with a set of requirements, followed by a design phase, then development, then testing and finally deployment. The client sees the working app once all development and internal debugging has been completed. Following their review, their bugs are fixed, the app would be released and maintenance begins! Hooray!
The catch? What if while reviewing that app for the first time you see that a feature isn’t meeting a user goal the way you thought it would and you know you need to make a big change to fix that? Since development and initial debugging are already complete, major changes aren’t so easy. Going back to the drawing board would likely require a change order, extra budget and a timeline delay. Oof!
Agile
The agile methodology is markedly different. The word agile is defined in the dictionary as “being able to move quickly and easily.” Nimble is listed as a synonym. Sounds about right, for projects that use an agile methodology are just that: nimble.
An app developed using the agile methodology would begin with a discovery phase, in which the client would work with us to not only lay out the strategy of the app (competitive research, user interviews, revenue strategies, etc.), but also to define a list of requirements and needs for the project backlog. These requirements are ordered by priority within the backlog. As development begins the team works through the backlog in that priority order during a series of weekly sprints. Each sprint begins with a planning session to review the backlog and determine what items will be tackled during the week ahead. As soon as a working version of the app is ready, even if not fully complete, we begin demoing the app with our clients during weekly check-in calls. And as soon as a functional app is ready, we provision our clients’ devices with beta builds so they can begin testing themselves, all the while development sprints continue. With each sprint, we add more features from the backlog and are able to adjust requirements and features as needed from feedback received from the client. This iterative approach not only enables the client to be involved earlier on, but also allows for feedback and adjustments to the requirements (aka backlog) as the project progresses without upsetting the apple cart.
So What’s Better for Your Project?
Both methodologies have their own merits, and as a PM, I’ve managed each. At Oak City Labs, we operate using the agile methodology because we believe by prioritizing features and getting in-progress builds in front of our clients’ eyes early on, agile leads to a better end-product for our clients.
