How high-functioning teams build software.
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.
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:
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:
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:
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.
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:
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:
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.
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:
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.
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:
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.
There are many different flavors of agile you may encounter at a company:
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.