Agile is a methodology for approaching software development. It consists of different frameworks such as SCRUM or Kanban that help development teams continuously build, test, and gather feedback on their product.

Agile consists of four core principles:

  1. Individuals and interactions over processes and tools
  2. Working software over comprehensive documentation
  3. Customer collaboration over contract negotiation
  4. Responding to change over following a plan

I will revisit these principles later and make more sense of them. In order to do so, it’s important to take a step back and understand software development practices that were previously used.

Waterfall

Waterfall development is a very linear approach to building a product. It has little to no room for feedback or iteration until the product is completely built and tested.

Here is how it works: teams spend weeks (and sometimes months) drafting product requirement documents.

Before any code is actually written, product managers, analysts, and designers will put together one massive document that outlines the product requirements in extreme detail.

To say the least, this is a long and laborious process in which, inevitably, some things get missed.

Here is a simple thought experiment. Think about Google search or a client email finder.

Now try to try to picture the requirements document for these products.

Undoubtedly, important things will get missed. One simply can’t conceive the use-case or scale or scope of how these products will evolve over time.

If you have built a product - as a solo builder or as a member of a team - you can likely relate to this assertion.

When everything is agreed upon, the specifications get handed off to the engineering team which then builds the product to spec, leverage qualitative and quantitate data and inputs.

When everything is coded up, testing commences.

If it is a complex product, testing and bug fixing can take weeks or months since the entire product needs to go through rigorous review. When testers and product managers sign off on the test requirements, the product is ready to ship to production.

There are a number of shortcomings to waterfall development, and here are a few.

Lack of built-in feedback mechanisms

What if the development team follows the specifications exactly and it turns out that seeing it come to life just isn’t as compelling as the product team thought it was? Or worse yet, what if there was an error in the specification document?

In Waterfall development, you won’t know the answer to these questions until the product is already built.

Product development can lead to large fixed costs. If the product doesn’t work, these costs might become sunk costs.

Sunk costs are the enemy of the builder because a sunk cost is a cost that has already been incurred and cannot be recovered.

What if the roadmap changes?

This happens all the time. It happens on the computer you are using to read this article, it happens in your company, and it happens at technology firms large and small.

What if the roadmap changes and the team needs to turn their attention to something else? Under Waterfall, you are left with an unusable product. Think: rigidity.

Again, if you can’t turn your fixed costs into something flexible you will be left with a large bill and not much to show for it.

All the dedicated work, stressful deadlines, whiteboard calendering, and late nights will not lead to the outcomes you wanted at the beginning of the project.

The product collects dust until it’s finally shipped

Instead of incremental enhancements being delivered to production over a period of time, the waterfall methodology waits to deliver the whole product until the very end.

While this is a reasonable approach for building a car, this is not a great approach to software.

Software, unlike cars, is flexible in the design inputs.

People can't use half produced cars. But we use half built software all the time.

Enter Agile

Agile helps solve these problems by allowing product development teams to continuously build features that add value. It also allows teams to consistently get feedback on their work and to make changes as necessary.

With the employment of Agile methods, teams consistently and predictably ship small pieces of code to production at a rapid pace.

Once they have completed any sort of feature that will add value, they test and release it to the world. This is an iterative approach to technology building.

Instead of taking months to build a final product and run an end-to-end test, Agile development enables teams to continuously build smaller pieces of the final product and add them to production over time.

This means testing goes faster since you are only testing the compatibility of the latest piece of code. This also means that users and stakeholders are happier because they get to see and utilize the latest product enhancements on a continuous basis.

Consider both approaches to a real word example of remodeling a kitchen. Let’s say it will take six months to do the remodeling job well.

Waterfall would suggest that the contractor and his or her crew rebuild the entire kitchen, then reveal the whole kitchen to the client after the six months are up.

While the job gets done in the same amount of time, the owner is left in the dark. Simple questions like how is it going go largely unanswered. Worst of all, the owners are unable to use any parts of the kitchen until the very end.

With Agile, the contractor would instead figure out what their team could get done every few weeks, and then allow their client to see it and use it while they remodeled the rest of it.

Maybe they can replace the cabinets in the first month, the countertops in the second month, and by the third month they install a new fridge and stove. Not a bad outcome for both parties!

In the second approach, the owner gets the benefit of using parts of the kitchen before everything is complete. Instead of the new stove just sitting there and collecting dust, it’s actually being utilized as soon as it's able to be used.

And maybe the kitchen owner wants to swap out one cabinet for a shelf?  

The contractor can now at least plan for that change before the six months are up and let the owner know how it will affect the project timeline.

Seemingly both parties can work together and communicate transparently to ensure the right outcomes and work are done.

These are some of the many benefits of Agile. Both parties are better off.

Try to take this lesson forward as you learn new development skills on freeCodeCamp and apply your skills on projects.

Let’s consider some other examples in the software world

Revisiting the four principles of Agile, we can now start to find examples of Agile's application in the real and digital worlds.

By now I hope you can see how these principles are a direct assault on the waterfall process.

Principle #1: Individuals and interactions over processes and tools

Having a solid process and set of tools is very important in Agile. However, valuing individuals and interactions over tools enables more value creation and output.

Individual team members can innovate.

Instead of forcing people to conform to strict ideation and specifications, you can give them more bandwidth to experiment.

Part of placing individuals over tools is experimentation with new work-flows. One example that is relevant to innovation in Agile software development is codec, a computer program which encodes or decodes a digital data stream or signals.

The H266/VVC codec uses about half the data to stream 4K videos. And it is recognized as the most efficient coding solution for the future 4K and even 4K VR real-time streaming.

How was this discovery made? It was made by people using Agile to solve video compression problems.

Specifically, it was made because individuals were given freedom to build, test, experiment, and innovate over a period of time. They were not told to build the kitchen from scratch and come back in six months.

They took small steps in the right direction. This outcome is instructive.

Here is a second example: when Lastpass was acquired by LogMeIn, LogMeIn was as interested in the technology as they were the culture of design that Lastpass had implemented to build products.

What type of culture was that? One that prioritized Agile.

Agile not only brings products to market faster, but it creates creative and synergistic outcomes that are valuable.

Creating value is embedded in the culture of Agile.

Principle #2: Working software over comprehensive documentation

This one should be obvious by now. Instead of verbose specifications and planning, just write a few lines of code that work.

Test it. Get feedback on it. Ship it.

Then, do it again.

Repeat.

A highly relevant example of this repetition process is found in Forms on Fire.

They created software to make mobile data collection easy. They didn’t write their entire company before launching; they wrote a few lines of code, tested it and shipped it.

As they got momentum, they accelerated their testing and iterative steps.

And they repeated what worked and tossed what didn't. The results speak for themselves.

Principle #3: Customer collaboration over contract negotiation

Agile promotes a quick feedback loop to get customer and stakeholder feedback.

What could be better than working backwards from what real users and customers want?

I have a business mentor who advised that instead of over-analyzing what customers want through endless planning, just keep it simple. "Mitigate distractions," he said.

I have written about the KISS principle in freeCodeCamp and that advice certainly holds true in Agile: build something small and see if your customers like it.

If they do, keep going.

Principle # 4: Responding to change over following a plan

Quick feedback loops beget rapid change and adjustments. This is what makes Agile so great for development teams.

This is why you should embrace it.

Roadmaps always change, this is a known constant. Using Agile methodologies, teams can respond to change by listening to customer feedback and making necessary adjustments.

There are times when responding to change means adjusting your product or changing how you think about users or the competition.

A classic example that students of agile can look at in the e-commerce space is selling on Amazon. How do you rapidly adjust to competition? One way is to build gated communities or try different product launch strategies.

Deploying solutions that are tactical and malleable is advisable.

There is a wonderful proverb: “We can’t change the direction of the wind. We can only adjust our sails.”

When I think of Agile, I think of this saying.

Agile is about learning, Agile is about teaching. Agile is about flexibility.

You can practice Agile in your day to day work or take online courses to develop further.

Some people are smart enough to predict what their customer wants. They know which way the wind is blowing.

But for us mortals, Agile is a methodology for navigating around our deficiencies in understanding what customers want.

It is the system that lets us constantly adjust our sails.