Agile and Waterfall are two very different to build software. Here at T R I M, we take the stance that Agile is the right way. If you’re not sure what either methodology is, here’s a little bit of info about each of them.
Waterfall
If you’ve worked with an agency in the past, chances are your project was designed and built using the waterfall methodology. Waterfall projects are sequential and everything gets specced out early on. Typically, the vast majority, if not all, of the design work is done first and then gets handed off to development for them to start building. Then, the developers build everything and pass it back to design to review. If everything matches the original design, then the client gets to finally see it. It’s common for waterfall proposals to have “rounds” of “revisions” built in to the scope and if/when those are exceeded, a change order is necessary.
The problem with waterfall is that it is very difficult to define and account for all of the project requirements at the very beginning. In software development, there are always what we call “unknown unknowns”. Also, if assumptions are made at the beginning that prove to be incorrect, it is time consuming and costly to send everything back through design and development. Compared to Agile, Waterfall is very high-risk. Opportunities to identify necessary changes are few and far between, incorrect assumptions are made often, and revising things late in the game is expensive.
Agile
With Agile, projects are completed incrementally. Iterations are made quickly and often in the form of what’s called a “sprint”. Sprints at T R I M are one week long, we build Monday through Thursday, and then demo our work to Product Owners on Friday. Rather than attempting to spec out the entire project to the last detail, we get a general idea of the full scope and then define requirements at the sprint level. Design and development can happen in tandem as well. If we know we need a log-in screen, there is plenty of development work that can be done before we need to see pixels, why wait? This also allows product owners to review a team’s output at the end of every sprint, rather than wait months like they would with Waterfall.
For many reasons, Agile is a much less risky approach than Waterfall. Since necessary changes can be identified and implement at any point in the project’s lifecycle, agile allows for unmatched flexibility. Communication is a constant with Agile, both internally and client-facing. Developers are collaborating with each other, designers are weighing in, and the product owner is a part of the conversation every week so there are no surprises. The product owner is also in the driver seat the whole time, the get to choose exactly what gets worked on every sprint. Need to move a feature to the backlog to tackle a hot fix that popped up? Not a problem with Agile.
With Agile there are no silos, big refactors rarely happen, if ever, and progress is easily measured. We swear by it, our product owners love it, and we’re not alone. Most of the blue chip tech companies that are household names use Agile. Google, Facebook, and Twitter, to name a few. Don’t take our word for it though, let’s get started on your project today and we’ll show you just how powerful Agile can be.
