22
A Primer on Agile for Web Development
Many of you will likely work in some type of Agile environment in your career. While there are many methodologies, it's important to understand a few of the key concepts that are shared across them. This article will serve as a brief primer on Agile.
This can be a loaded question, so I'm not going to dive into the Agile manifesto. Instead, I'll give you my best explanation of what's important.
At a high level, it's about organizing around work to meet the ever-changing needs of your customers. Whether you are in an established space or you are working on something novel, you need to be able to adapt to your customers' feedback. If you don't, someone else will.
When working on an Agile team, you will likely be working on smaller features that are delivered more frequently. Instead of planning months of work ahead of time, you will define and prioritize near-term features based on continuous customer feedback. These priorities will often change frequently and rapidly. This often leads to better products that are more suited to what the customer actually needs, because the customers are involved in the process from start to finish.
This is counter to the traditional approach known as "waterfall" where large scopes of high-budget work are planned months ahead of time and delivered all at once or in just a few large chunks. With this strategy, the customer usually spends a lot of time involved in the beginning (to attempt) to scope out the entire project. This leads to shifted launch dates, budget-breaking invoices, and a final product that is not actually what they needed.
There are two main frameworks for implementing the Agile methodologies: Scrum and Kanban.
Kanban is meant to provide the greatest amount of flexibility when it comes to changing priorities.
Instead of working on a 1 or 2-week cadence, Kanban is a continuous stream of work. When you finish something, you immediately move on to the next thing. Kanban utilizes a Kanban Board to organize the flow of work into columns. A typical Kanban board (see an example below) might have columns such as (from left to right):
- To do
- In progress
- Done
The "To do" column contains all work that is ready to be picked up. As you carry a card across the finish line, it will transition into these other columns to represent a specific phase of your team's workflow. The "In progress" column would let others know that you are currently working on a given card. Transitioning to "Done" represents the work being shipped to production.
To help alleviate bottlenecks in each of these columns, Kanban has a concept of WIP (work in progress) limits. These are applied to each column individually based on your team size. Let's say you have a team size of 10 people. If you make an "In progress" WIP limit of 8, then only 8 cards can be in the "In progress" column at any given time.
Kanban also states that the further right a column is on the board, the more important or urgent that column is. Maintaining some capacity on your team is a good idea so that things like code reviews, individual challenges, and other unexpected tasks can be taken care of quickly.
Scrum is focused on fixed-length cycles called Sprints. Typical Sprint lengths are 1-2 weeks, although it can vary by organization or team. During a Sprint, teams will take on a fixed amount of work based on the current priorities and overall capacity.
Each Sprint consists of 4 "ceremonies" that provide structure and room for near-term planning.
- Daily Standup
- Spring Planning
- Sprint Demo
- Retrospective
A short meeting to sync up with your team. While these can often turn into "status updates" without many purposes, they are better served as a place to ask questions and inform your team of potential problems or blockers.
This is where you decide what you will work on for the next Sprint. Teams will talk about and select specific pieces of work from a prioritized backlog.
This is where you will show off all of the completed (and potentially deployed) features that your team worked on during the previous Sprint.
A review of what went well and what could be improved from the last Sprint. You want to come out of these with at least one Action Item that you can work on during your next sprint to improve something in your process or team dynamic.
The ideas of Kanban apply to other frameworks too. Many of them, Scrum included, have a concept of a board to represent the flow of work from "To do" to "Done" like this. Understanding the importance of finishing work before starting something new, whether it's yours or someone else's, is incredibly important and often overlooked. It's easy to fall into the fallacy that having more items in progress leads to more work getting done, but we often see that is not the case. Instead, this causes bottlenecks at other stages of the process, and we become less Agile as a team.
I hope this brief overview gives you a better idea of what it's like to work on an Agile team! I'd love your feedback, and I'm happy to go into more depth on these topics in the comments below.
Thanks, everyone, and happy coding! ✌️
22