As discussed in part one of this series, agile is an umbrella term that encapsulates a number of frameworks, strategies, and tools. In this second installment, we dive a bit deeper into what agile is in practice by highlighting some of the most common frameworks used by agile teams. This primer on agile frameworks and methods will by no means be comprehensive (there are entire courses, websites, and certifications dedicated to each), but it can serve as a good starting point for better understanding which flavor of agile might be best suited to your teams’ needs if you are considering adopting agile in your organization. This post will cover two of the most popular types of agile in more depth: Scrum and Kanban. There are several others that are widely used as well, but these two have many components that can be flexible and adaptable for use in non-software development contexts.
Scrum is one of the most popular and widely used frameworks in agile and is centered around using a set of specific processes to achieve the team’s goals. The key components of Scrum can be broken up into three categories:
One of the defining aspects of using Scrum is dividing up work into what is called a sprint. Sprints typically last for one month or less and are meant to enable teams to break up their work into chunks that are shippable (or ready to be deployed for users) without necessarily needing to complete every piece of functionality. Several meetings are essential parts of Scrum that ensure the team is working actively towards its goals for each sprint, including Sprint Planning, Daily Scrums, Sprint Reviews, and Sprint Retrospectives.
Artifacts in Scrum are the different objects or items needed to guide the team’s processes. One of the essential artifacts is the product backlog—where a team keeps all the possible items they might want to work on. The backlog is, at its core, an organized list of every option the team has available in terms of work that could be done, but it is not a commitment to get every item done. For each sprint, the team draws items from the backlog to determine the exact work they will do in that particular timebox.
There are three key roles in Scrum: Scrum Master, Product Owner, and Team. The Scrum Master is considered the keeper of the process. They are there to help make sure the team lives agile values and is following the process they agreed to as part of Scrum. They help remove obstacles preventing the team from moving forward and they organize the critical meetings outlined above. The Product Owner is considered the keeper of the requirements and is the final say on what is a priority in the product backlog. This role was designed to help the team better understand the direction and remove any opportunity for conflicting guidance on the end goals. The Team, in the agile and Scrum context, refers to the group responsible for implementing the work and which has a shared responsibility for the goals of the project. In Scrum, it is also important to note that the team is considered “self-organizing”—meaning that it decides how to break down the work and how it is assigned amongst the group. There is no ‘lead’ who doles out work or makes unilateral decisions.
Kanban is another popular agile methodology with a primary focus on the flow and visualization of work being done. In contrast to Scrum, it is comprised of a series of practices as opposed to specific core components:
- Limit Work in Progress
- Manage Flow
- Make Policies Explicit
- Implement Feedback Loops
- Improve Collaboratively, Evolve Experimentally
A Kanban board is used to show the flow of work across the team to visualize the work being done. Kanban boards are typically made up of columns reflecting various statuses that the work can be in—it can be as simple as three columns saying, “To Do,” “Doing,” and “Done.” The use of these boards allows teams to start with what they are already doing and use the visual cues to identify bottlenecks or issues they can address as they continue their work. A Kanban board is comprised of Kanban cards that contain individual items the team is working on that can be moved through the flow of the board as work moves forward.
The Kanban board also allows teams to set clear limits around the amount of work they consider “in progress,” given the easy visual of how many cards are in columns representing active work. The goal in Kanban is never to have more work in progress than capacity so teams can have greater efficiencies in their work. To increase efficiencies on the team and maintain the flow and movement of the work, bottlenecks need to be removed when possible. Since the Kanban board provides full transparency of what the team is working on and real-time status, it is easier to flag where those blockers are and resolve them as they arise.
Like Scrum, teams using Kanban can implement their own policies as long as they are explicit and well-defined. For example, while Scrum calls for sprints, the team defines how long its sprints are in the context of what makes sense for the work. In Kanban, teams can set their work in progress limits and any other rules that help push work forward.
While important in any implementation of agile, the implementation of feedback loops is particularly central to Kanban. There are specific cadences at which feedback loops are designed to occur, focusing on various levels of granularity—from quarterly Strategy Reviews down to daily Kanban Meetings.
The final practice of Kanban is all about how the team works together over time. Since Kanban is based on the idea that the team starts with what it is already doing, the practices outlined above help nudge the team into incremental change. It allows for continuous improvement and evolution of how the team is achieving its goals so that getting work done keeps getting better as the team uses the Kanban methodology.
Photo credit: Atlassian Agile Coach.
This is just the tip of the iceberg of all the agile frameworks and tools that are out there. Scrum and Kanban also have so much more to them than is covered here, but this should give you the basics to better understand how teams use these two types of agile. In the next post of this series, we will discuss how these agile concepts can (and are) being applied to international development.