What Is Agile Methodology: A Primer on Moving Fast

Learning to build code, whether through self-study or a computer science degree, is not the same as learning to build software, especially in a changing company setting.

Your studies may have taught you what code needs to be written to build a better piece software, but they probably didn’t teach you how a team of engineers should think about writing that code. How does the work get divvied up? What does a development cycle look like? How does quality control work? Over the last 60 years, many methodologies have tried to define exactly how teams can optimize their software development, but the one that reigns supreme—at least over the last 20 years—is the agile methodology.

Emphasizing speed, adaptability, and user-centric design, the agile method is the backbone of modern software development. In fact, most of the popular project management tools you’ve likely used (like Trello and Jira) are based entirely on its features.

If you’re joining an engineering team for the first time or just looking for a refresher, this primer will get you up to speed with a functional understanding of agile methodology, its core components, leading benefits, and popular delivery implementations.

Agile methodology in 5 minutes

So what is agile methodology? “Agile” isn’t a particular methodology exactly, but is rather a set of principles and values, the core of which are defined by the signers of the Agile Manifesto as valuing:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

To think about how the agile process actually works in software development, let’s run through a quick hypothetical.

Let’s start with the antithesis of agile, the waterfall model. This was the standard development process for software in the 70s and 80s, and it is based on a series of sequential and separate development phases, each one flowing into the next like a waterfall.

For example, to build a piece of software using waterfall, your project timeline would look something like this:

• Phase 1 - Research: Identify and scope the needs your software will address
• Phase 2 - Planning: Decide on the project strategy and timeline
• Phase 3 - Design: Put together a blueprint for the software architecture
• Phase 4 - Development: Writing the code
• Phase 5 - Testing: Ensure the product works
• Phase 6 - Maintenance: Service the software post-release

While this may look neat on paper, in reality, it can create some problems. Think of it this way: How often do you see a piece of software released as a perfect 1.0? Almost never. Typically, software is released and needs to be updated based on user feedback and performance.

With the waterfall model, there is a ton of room for error in the research, planning, and design phases that likely won’t be exposed until the product is released to users—at which point, the process starts completely over to address the issues that emerged. This can create a laborious update cycle that produces slow timelines and subpar software.

Agile works differently

The emphasis in the agile method is getting working software into the hands of users as quickly as possible. This is done with frameworks that incorporate short, recurring development cycles.

For example, in the popular agile framework Scrum, development cycles are called sprints. A sprint is a short (typically two-week) period in which the team focuses on building a tightly scoped set of deliverables. They choose what those deliverables are on a rolling basis. A typical sprint looks something like this:

• Phase 1 - Sprint planning. The team, which includes engineers as well as other key stakeholders like marketers or product managers, determines what new features are highest priority for the next sprint to deliver.
• Phase 2 - Sprint. Each team member works on their portion of the delivery, checking in regularly—often times daily—to update on the changing progress and request help as needed.
• Phase 3 - Retrospective. At the end of the sprint, team members present their progress and reflect on their experience in the sprint. New needs are surfaced, and changes are made to roadmap and strategy.

Instead of spending months building a complete piece of software, each team releases new features to users on a constant basis. In this process, engineers are given more control over the product roadmap, software is more adaptable and changing, meanwhile users are able to have their needs addressed quickly.

In essence, that’s all an agile methodology is—a software development framework that focuses on the delivery of usable software to users quickly and consistently. But to really understand agile methodology, you will need to dig deeper into its core process components.

The essentials of an agile methodology

There are many flavors of the agile process, but at the core of every agile methodology is this concept of simplicity—figuring out what needs to be done to create a specific, desired result, but nothing more. Unnecessary efforts slow progress, and being able to iterate frequently is central to agile’s identity.

Underscoring this idea of simplicity, there are a few essential ideas that you’ll find in every agile methodology:

1. Iterative improvement and user-focused development

In the waterfall model, a piece of software is coded in one long, thoroughly planned development phase. In an agile methodology, a piece of software is composed of many smaller iterations, each contained in short, distinct development cycles. These small, but better, iterations are each focused on providing a new bit of value to users.

These iterations have a few common requirements:

• Timeboxing. Agile development cycles are typically timeboxed, meaning a hard time limit is set to keep them short.
• Adaptive planning. Plans and roadmaps are changed between development cycles, based on new learnings.
• User-centric design. Fulfilling user stories, or specific user-experienced outcomes, is the goal of each cycle.
• Short feedback loops. Related to timeboxing, teammates share work constantly and receive feedback immediately.
• Continuous shipping. Code is shipped early and often.

All of the above ideas are packaged differently by different agile methodologies—for instance, Scrum calls its timeboxes “sprints” and its short feedback loops “daily scrums”—but the core concepts are always present.

2. Cross-functional teams

One of agile’s core values is to focus on the delivery and improvement of software to users, and that requires agile teams to be comprised of more than just engineers. A few roles you’ll see are:

• Customer advocate. This role has many different names, with “product owner” being most common in businesses. Essentially, this is the person who represents customer interests in development cycles, making sure new features fit their needs.
• Development manager. Again, a role with many names (“scrum master” for example), this person’s primary function is to unblock teammates—whether that means providing resources or taking excess work off their plate.
• Individual contributors. These are the people who deliver things. Engineers, designers, copywriters, and more. Their jobs are to contribute certain deliverables within each timebox and participate in retrospectives and planning.

Depending on the project and company, the people filling these roles can come from a variety of backgrounds. On some projects, the customer advocate may be an experienced product manager, while on others it may be a member of the marketing or sales team. Likewise, the development manager could be a senior engineer, or it could be someone with more of an operational role.

By involving different stakeholders and domain experts in the entire development process, teams are able to prevent breakdowns in communication and avoid shipping software that solves a nonexistent need.

3. Built-in quality controls

In the waterfall model, testing and quality control are their own distinct phase of the software production cycle. Once all the code has been written, testers get to work finding bugs and send them back for the engineers to fix. This is a long, inflexible, and ultimately inefficient development cycle.

In agile methodologies, testing and quality control are baked into software development. Engineers test code as they write it, and typically, the code undergoes another set of automated tests before being deployed.

The most common types of built-in quality controls you’ll see are:

• Pair programming. Invented by Ken Becks, signer of the Agile Manifesto and creator of Extreme Programming, pair programming involves two engineers writing code on one machine, checking each other’s work in realtime.
• Unit testing. Related to test-driven development (also popularized by Ken Becks), unit testing involves writing tests for each single component of software to ensure that it performs as expected, with no errant behavior.
• Automatic code review. Related to continuous integration, there are many modern tools available that allow engineering teams to test every piece of newly shipped code to make sure it doesn’t break anything.

To summarize: In any agile methodology, you will have cross-functional teams staffed by members from various parts of the company, iteratively building software in short development cycles, and testing their developments every step of the way.

Agile methodologies mean happier users—and engineers

There are many different flavors of agile you may encounter at a company:

• Scrum
• Kanban
• Extreme Programming (XP)
• Lean Programming

Done well, any one will make software development faster, more adaptable, and ultimately more enjoyable for the engineers behind it. At the same time, these methodologies will also create software that more quickly aligns with and addresses user needs—leading to more satisfied customers.

The terminology can get a bit overwhelming, particularly as startups have a tendency of mix-and-matching terms from different frameworks (and sometimes even inventing their own), but if you understand the core ideas above, you will have no problem getting up to speed quickly with whatever framework your company uses.

And, if you’re interested in working for a startup that uses an agile methodology, you can start your search here.