Agile is the modern way of making software
You will see this term a lot on job specs, to clarify it isn’t agile the adjective with a lowercase 'a', it is Agile the noun, the name of a specific way of working that is very common in software development. If you see a job that doesn’t mention it, it may instead mention Scrum. This is a more opinionated derivative of Agile with a few extra rules and specifics.
Agile is a whole industry, there are conferences, books and qualifications and you can make a whole career as an Agile Coach or in one of the specific roles laid out in Scrum. While being an expert in the topic isn't vital to an early career software developer having un understanding of the rough process and terminology is important. This is one of those scenarios where a bit of knowledge can go a long way and allow you to talk with more confidence in interviews and set you apart from other junior developers.
The Agile Manifesto
The Agile manifesto is short enough that I’m just going to note it down below:
We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:
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 is, while there is value in the items on the right, we value the items on the left more.
What does the Agile Manifesto mean to a developer?
The simplest way I can summarize this is that teams of developers should aim to make the smallest amount of useful, functional software that provides value to a user, show it to them, get feedback and then improve or expand what they have made.
Rather than getting an enormous shopping list of features and then spending 18 months building it only to find that it’s not really what the user/customer wanted, we instead build little and often and get feedback so we can course correct as we go.
Scrum
Scrum goes further than this and defines:
- working in short blocks of time called sprints (often two weeks, but sometimes delightfully 3)
- that will tackle a fixed iteration of work
- having a review of the work at the end of the sprint to show users what was made
- regularly looking over a backlog of tasks
- and planning which ones to bring into the next sprint based on user needs and how much capacity the team has.
- Each piece of work is called a user story and a number is assigned to it during the planning sessions to indicate how complex the work will be to complete
- the numbers are called story points and follow the fibonacci sequence (1, 2, 3, 5, 8, 13, 21, ...). They follow the fibonacci sequence to limit the options that can be chosen and stop team members squabbling over whether something is a 6 or 7, pick 8 and move on.
That’s more than you’ll be expected to know in your first job, if you want to really get it then I suggest you read the Scrum guide, it’s delightfully short and quite interesting.
You will also often hear people say "as defined in the Scrum guide", if you've read it you will find realise that many of these people haven't read the guide. In fact much of what is in the bullets above isn't in the Scrum guide, it's just how people have taken the concepts and developed them over the years to become the industry norm.