Nowadays almost every software development company and team claims to be agile and usually follows some kind of agile methodology. However in the middle of the whole agile movement the real meaning of "agile" is often lost. What does it mean to write code in an agile way? Or to work in an agile team, deliver a product in an agile fashion?
Where has the meaning behind agile disappeared - and what does it really mean at its root?
The Birth Of Agile
Let's take a step back to where it all started. In 2001 17 pretty well known software craftsmen gathered in Utah to summarize their views on efficient software development in a short document. The outcome of this meeting was the Agile Manifesto which forms the basis of agile software development (and marks the start of the agile movement). The 4 values the agile manifesto states are these:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
That's pretty much it. So why does "agile" seem to be something much more complex and difficult to grasp these days?
Agile Methodologies and Certifications
Today, 14 or so years after the beginnings of agile software development, agile is pretty much a synonym to following some agile methodology, the most popular without doubt being Scrum.
And it's little wonder it's so popular: for starts the methodology is very credible, as it was developed by Ken Schwaber and Jeff Sutherland, two of the members of the Agile Manifesto. Getting started with methodology is pretty easy - there are tons of online resources and more structured Scrum Master courses as well. I also took one of those a few years back - at my time at Skype almost every engineer got to attend a 2-3 days long Scrum Master training. (Note: while the in-person classes are interesting and entertaining, all relevant materials are available online and for free to get up to speed with Scrum.)
Scrum is also super popular because it's really simple to implement and follow. Implement a couple of lightweight ceremonies on a schedule - standups, backlog groomings, plannings and retrospective, and that's basically it. And results will come fast even if leaving out certain ceremonies. For example just by having a daily standup the team will be more productive if there's not been something similar in place beforehand.
And it's not just Scrum, but a bunch of other agile methodologies and tools that are gaining traction. Kanban is another popular one, as well as Scrumban (mixing Scrum & Kanban). Extreme Programming is also a tool that although fewer teams use, but those who do absolutely swear by it.
I've used Scrum, Kanban and Scrumban with various teams and projects, sometimes strictly sticking to their processes and other times loosely following recommendations. For example at Skype we did Scrum by the book and at Skyscanner we've tailored a version of Scrumban to fit our needs.
Still, the more I use these methodologies to build software in an agile way, the more I'm certain that following an agile methodology is not a what agile software development is about.
Back to Basics
Building software in an agile fashion will always be speedier, team members will be more motivated and overall outcomes will be better compared to the plan-months-ahead waterfall style development. As the benefits are immediate it's little wonder that a whole consulting and training industry has spurred to help teams and companies transition to agile with the use of agile methodologies and workflows.
The word "agile" has been so overused in the software industry - not the least by consultants making a living off of it - that it has now pretty much lost its original meaning. This is what Dave Thomas, one of the founders of the Agile Manifesto says in a recent post. One of the four values of the Agile Manifesto is this:
Individuals and interactions over processes and tools
So why is it that all agile methodologies introduce more processes and tools in order to achieve agility? Does this not go against the original ideas of agile? Dave - rightfully - says that it's time to ditch the methodologies and get back to the basics of agile.
The Real Meaning of Agile
Doing something in an agile way means making a small change quickly, learning from it, making adjustments to our understanding of the problem and repeating this many times. This is what doing something with agility means:
What to do:
- Find out where you are
- Take a small step towards your goal
- Adjust your understanding based on what you learned
- Repeat
How to do it:
- When faced with two or more alternatives that deliver roughly the same value, take the path that makes future change easier.
These few simple steps are really what agile is all about. Stick with these basics and you can apply them to all parts of software development:
- When writing code, do it in an agile way. Decide what you want to achieve, do a small change, test it, learn from it, adjust and repeat. Try to write code that's easy to change later.
- When building a product, do it in an agile way. Do small changes, get immediate feedback, do small iterations and make decisions that allow future changes as much as possible
- Similarly, when working as a team, solve problems using these basic principles, a small step at a time
- The tools and methodologies you use should help achieve this kind of agility. If they only add more process - ditch them.
The most successful engineers, teams and products all follow these simple steps one way or the other. Agile is not a methodology with rules and processes to follow. At its roots agile is a simple and fast way of learning and improving by taking small steps, one after the other.
Put this principle first and make sure whatever light- or heavyweight process you follow helps achieve this kind of agility.
Featured Pragmatic Engineer Jobs
- Senior Backend Engineer - C#/.NET at Straddle. £90-125K + founding team equity. Remote (UK).
- Senior Solutions Engineer at Tint. $130-195K. Remote (US).
- Product Engineer at Causal. Remote (US, UK). The team tackles interesting challenges like simplifying React state management.
- Backend Engineer - Data at Causal. Remote (US, UK).
- Senior Backend Engineer at Polarsteps. Amsterdam (Netherlands).
- Senior Data Engineer at GetHarley. £70-100K. Remote (UK) or Hybrid.
- Senior Frontend Engineer at GetHarley. £70-100K. Remote (UK) or Hybrid.
- Senior Software Engineer at Tint. $140-195K. Remote (US).
- Senior Product Engineer, Frontend at Attio. £90-125K + equity. Remote (Europe).
- Senior Data Engineer (RoR) at Terminal49. $140-200K. Berkeley, California.
- Engineering Manager - Security Product team at CAST AI. Remote (Lithuania).
- Software Engineer at Freshpaint. $130-210K + equity. Remote (US).
The above jobs score at least 10/12 on The Pragmatic Engineer Test. Browse more senior engineer and engineering leadership roles with great engineering cultures, or add your own on The Pragmatic Engineer Job board and apply to join The Pragmatic Engineer Talent Collective.
Want to get interesting opportunities from vetted tech companies? Sign up to The Pragmatic Engineer Talent Collective and get sent great opportunities - similar to the ones below without any obligation. You can be public or anonymous, and I’ll be curating the list of companies and people.
Are you hiring senior+ engineers or engineering managers? Apply to join The Pragmatic Engineer Talent Collective to contact world-class senior and above engineers and engineering managers/directors. Get vetted drops twice a month, from software engineers - full-stack, backend, mobile, frontend, data, ML - and managers currently working at Big Tech, high-growth startups, and places with strong engineering cultures. Apply here.