Agile For The Rest of Us

This article was originally written for the Fusionbox blog in January 2015.

The Fusionbox process takes many pages from the Great Big Book of Agile Methodology to streamline and modernize the production of web content, etcetera, but for the folks at home, what is agile development? Where did it come from? Who let it in? Should we feed it?

⛓ Waterfall

Software development used to be treated the same as the development of any other product. Guidelines would be set, features would be decided upon, and a timeline would be locked in place. This is because in the worlds of manufacturing and construction, after-the-fact changes to any design or aspect of a project are prohibitively costly, if not impossible, so it only makes sense when planning to “pick it and stick with it”. When software development was in its infancy, no formal alternative methodologies had been invented, so the manufacturing model was just adapted to fit the software industry. The idea is that requirements are established, and production ensues.

This became known as the Waterfall Method, which until recently tended to be the standard for software dev. In its purest form, Waterfall designated this list of steps:

1. Product requirements specification
2. Design
3. Programming
4. Testing and debugging
5. Delivery of product
6. Maintenance

With these steps, it’s fairly easy to budget and set timetables, because it is already known on Day 1 of design what the finished product will be when on Day X when it is delivered. Also, if a developer can’t be involved in the project for one reason or another, the concrete plan makes it easy for another programmer to hop right into his or her spot.

Here’s the problem:

The Waterfall method is typically incredibly rigid and inflexible. Altering the project design at any stage in the project is nearly impossible. What happens when down the road, someone decides they want some extra functionality for their website? Waterfall says no. When an apartment building is planned, no one decides they want an extra floor or balcony at some point during the middle — but when designing a website, it’s not uncommon in any capacity for requested changes to arise. “Let’s add an eCommerce section to our site”, “can we put the navigation bar on the side, rather than the top?”, “how do we add mobile functionality to our page?” Those suggestions and queries are very difficult to respond to in Waterfall.

And what about debugging? The testing stage of Waterfall method is deferred until especially late in the project. To put this in perspective, remember that apartment building we were talking about earlier? Construction contractors won’t test if the building will stand on its own while they’re still pouring the foundations. Which works quite well for the apartment building. So much planning has gone into that high-rise since the start that the contractor pretty much knows without a doubt that his product is structurally sound. However, software programs or websites are not high-rises. It’s so often impossible to predict how the many MANY different pieces of a site will interact with each other, and this leads to problems in the debugging phase. All of the design steps and all of the programming steps will finally end up in the lap of a QA tester who has a week or sometimes as little as a day to solve every little problem and glitch in the product to deliver it on time.

At the end of those months and months of painstaking planning and prediction, the “finished” product is buggy and might not meet all the needs it is supposed to fill because the requirements may have changed at some point during the process.

⛓ Agile

So by now it’s easy to see that building a website is a different task entirely from building an apartment tower. Why would the same development process be applied to both? Pioneers like E. A. Edmonds, Tom Gilb, and Dan Gielen all concurrently started publishing or applying different ideas about adaptive software development in the early- to mid-seventies, but it wasn’t till the mid-nineties that those methodologies started seeing widespread use. Initially, there were many different forms — Rational Unified Process, Scrum, Dynamic Systems Development Method, etc. — but these were for the most part collated under the term Agile Development after the “Agile Manifesto” was published in 2001. (For more information on the Manifesto, see here — it’s a quick read.)

Agile focuses on team-based, adaptive development. Rather than setting all the requirements and solutions at the beginning of the process and not obliging any sort of change, requirements are allowed to vary and solutions evolve in real-time based on those changes. The Agile approach, in essence, works like this:

The process is iterative — rather than the Waterfall style of an ordered list, it is based on the cyclical use of repeated steps. The requirements for a software product are gathered and organized by the team or by a team leader into “sprints” — short bursts of development activity resulting in large leaps forward in production. Frequently, the minimum requirements for an operable product are put into the first few sprints, which means rapid delivery of useful software is standard.

The best analogy we’ve found to describe Agile sprints is this: With Waterfall method, first built are the wheels, and then the chassis, and then the engine, and eventually those leather seat covers are tossed on and that new “fresh-off-the-lot” smell is pumped in, and there is FINALLY a car that can be driven away. With Agile, rather than taking all that time to build a whole car (which we’ve established may or may not work as well as it should), the first “sprint” builds a skateboard. It’s not the aerodynamic supercar that is the end goal, but it’ll get someone down the street from their mom’s house to the grocery store, and it’ll be produced and deliverable in a fraction of the time.

Through further sprints, which are usually a few days or a week long, the skateboard is built out more and more. Maybe a bicycle, second, and then halfway through go-cart stage, someone might decide they actually wanted a Mazerati, not a Ferrari. With Agile, that’s not a problem. One of the primary principles of Agile development is to welcome changing requirements, even late in development. With each sprint, or iteration, working software is delivered — visible proof of progress to put a client or customer’s mind at ease.

“Well, that’s awesome, it’s so intuitive and fluid, why would anyone NOT use Agile?!” Agile isn’t a be-all, end-all solution to development. Agile is very flexible, but that means it operates without the structure of Waterfall method, and that CAN have some drawbacks. Agile projects are harder to predict — changing requirements also means changing budgets and timelines, and that’s not how most business works. Waterfall was so widely accepted because it makes sense outside the world of web development, but Agile is not the same. While it is more intuitive to design and development teams, it is truly a leap of faith for different departments in their organization, or for clients in an agency context. The price paid for more efficient and functional software is sometimes an extension on deadlines and budgets.

⛓ So What?

Ultimately, neither methodology is “better” across the board. Waterfall is sometimes better for static projects, where the requirements are not expected to change at all, or for situations where a client can’t commit to a lot of communication, or the deadline or budget is adamant and inflexible. Here at Fusionbox, we love how collaborative and personal Agile development is. We think face-to-face conversation is the best form of communication, and we love giving the continuous attention to technical excellence and good design that is essential to the Agile process…