When you start your first dev job, you'll almost certainly enter into an environment that uses at least some agile development practices. You'll be asked to join meetings where you estimate tickets and plan sprints. You'll hear words like "stakeholder" and "retro" thrown around. Unless you came to software engineering from a programming-adjacent background like product management, this will probably all be pretty new to you. That's why we've developed this beginner's guide to Agile Development practices. Armed with this guide, you'll build the context you need to hit the ground running at your first dev job.
Why Do we Need Agile?
Wherever you are in your journey to learn to code, you've probably felt that planning a project or assignment can be just as difficult as actually writing the code for it. The difficulty of organizing your project just gets harder with every additional person you add to the project. Who should work on what part of the code base? What is the most important thing to build first? How will you decide what to work on next? What happens if you get overwhelmed by the scope of a feature or a really big bug?
Now, imagine you're working on a code base that isn't a personal project or school assignment. Who will decide what features are most important to the business or company you're working for? Who will decide how a user should interact with a feature or what it should look like in the browser? Who will decide when something needs to be built or what bugs are most important to fix?
This exactly where Agile practices come in!
What is Agile?
Agile development practices are not a hard-and-fast set of rules and how-to's for software development. They are a set of guiding principles and common practices that emphasize collaborative and flexible development. There's a lot of content out there on Agile principles, but you can read the original Agile Manifesto here.
There are also a lot of different ways to apply Agile practices. This post won't focus on a specific discipline. Instead, we'll break down some common terms and practices that you are likely to come across as you go out interviewing or start your first dev job.
Some Common Practices
Agile practices describe a set of tools for planning development projects, collaborating with non-developers (product managers, designers, end-users, etc.) and delivering code that works. We'll take a look as some common practices that you're likely to encounter, and we'll do it by walking through an example of a real application.
Let's use the example of a team responsible for building a dog walking web app. The company we work for needs us to build a brand-new web app that matches dog owners to walkers, allows them to schedule dog walks, allows owners to pay walkers, and allows dog walkers to share pictures of adorable dogs with the dogs' owners, you get the idea. That's a lot of work! Luckily we have Agile practices to guide us towards delivering the finished product :)
Sprints
Development projects are often organized into "sprints". A sprint is a set time-frame within which a team will work to deliver an agreed upon feature or set of features. Sprints usually run for one to two weeks and then conclude before the next sprint kicks off.
Who decides what work goes into a sprint? This is where a product manager comes in. A product manager is responsible for understanding the requirements of the business owners and deciding what portion of the project should get worked on first. For example, the business owners understand that its more important for users to be able to find dog walkers and schedule walks than it is for dog walkers to be able to share pictures of dogs. So, the product managers will suggest starting with that work.
Product managers will use their understanding of the business requirements to write up the tickets (more on that soon!) that describe the work in a sprint. Then product managers and developers will meet together to review the tickets for a sprint.
Tickets
A ticket describes a discrete unit of work within a sprint. Tickets are small documents that tell the developer what functionality they need to build, along with any context or background info they need to build it. There are lots of different ticketing softwares out there--I recommend checking out Trello or Notion, which both have free options you can use.
Sprint Planning and Ticket Estimation
Once product managers have written up the tickets that describe some features that need to be built, those tickets often sit in a backlog. A ticket backlog is a list of tickets that haven't been reviewed by engineers yet and haven't been put into a specific sprint. In order to kick off a sprint, product managers and developers will meet together and review the set of tickets from the backlog that need to go into the sprint. Each ticket will be briefly discussed until each developer understands enough to estimate the ticket.
Ticket estimation involves assigning a number to a ticket that represents the assumed time and complexity of the work described. Different teams use different numbered scales. In our dog walking example, let's say we have the following ticket:
Title: Dog walker can sign up for the app
Description: As a dog walker, I can register for the app and indicate my location and available schedule
Technical details:
We'll need to build
* Dog walkers table in the database
* Registration routes and views
* Ability for dog walker to indicate location and scheduleThis is actually a pretty big ticket! You could even break it into two discrete units of work: dog walker registration and dog walker location/schedule tracking. At a ticket estimation meeting, engineers reading this ticket might point this out, and suggest that this one big ticket be broken up into two smaller tickets. Then, the group of engineers might estimate each. ticket, on a scale of 1-4, at a 2.
Ticket estimations helps product managers and developers decide how long a given sprint should take and helps them evaluate productivity at the end of a sprint. For example, if a given sprint only contains 4 tickets, but another sprint contains 10, looking at the estimates of each ticket helps us understand that amount of work that gets done.
Estimating tickets also helps everyone on the team build the context they need to tackle any piece of work. Estimating tickets is a great time to ask questions about the product and technical requirements, or anything else you don't understand or want more info about. That way, any dev can handle any ticket, regardless of whether they participated in planning the sprint or researching the background needed to write that ticket.
Sprints in the Day-to-Day
There are a few practices that help guide us through a successful sprint.
Daily Stand Ups
Once a sprint begins, participants usually start each day with a brief "stand up" meeting. Every member of the sprint--developers, product managers and anyone else involved--will meet and give a brief progress report on their current ticket. This is one time to raise questions or concerns about your ticket to the group. These meetings are short, and usually conducted while everyone is literally standing up in order to keep it that way. If you have a question that requires further discussion, you might raise it here and plan a time after the meeting to go deeper with whoever can help.
Daily stand ups keep the sprint moving forward smoothly and present an opportunity for team members to stay in the loop on the overall progress, as well as share awareness of any obstacles that may arise.
Pair Programming
As a developer working in an Agile environment, you are very likely to pair program with your teammates. This ensures that we write clean, well-tested, functioning code that meets the feature requirements of the ticket. It helps us spread the knowledge of what we are building around to other team members and makes it easier to solve complex problems. Learn more about pairing here!
Sprint Retros
At the end of the agreed-upon sprint timeframe (usually 1-2 weeks), every member of the team will engage in a retrospective meeting. There are a number of different ways to conduct these meetings but one common approach is to ask each member to contribute items that went well, items that were confusing to them or items that went poorly. Then, the group will spend a short time discussing each confusing/negative item and identifying actionable steps that can be taken to address the issues in the next sprint.
This ensures that each sprint iterates and improves upon the last!
Agile And You
There are many different ways to apply Agile practices--there's no "one size fits all" approach. However, the terms and practices outlined here are common to a number of different Agile approaches and are all helpful ways of structuring complex development projects. These practices help us get the information we need to write code that works and delivers values to our team members and users.
As you interview for your first dev jobs, it could be helpful to ask your interviewer about their working practices. What Agile practices do they use, if any? Do they plan and engage in sprints? Write tickets, pair program, conduct retros? Finding out more will help you decide if a certain company is the right fit for you.
Once you start your very fist dev job, having some familiarity with these concepts will help you navigate your new working environment and build the context you need to start contributing. If you want to learn more about Agile, you can check out some of the resources listed below.