The Definitive Introduction to Agile Work Management (Including Scrum and Kanban)
If you’re looking to understand the basics of agile work management and how to get started, you’ve come to the right place.
In this post, we’ll explore these six foundational topics:
What Is Agile Work Management?
Agile work management means getting work done using an agile methodology. It’s a way to complete work in the complex, fast-moving, ever-changing product world that we live in.
Originally created for software development, the agile methodology is quickly being adapted by more than just IT teams. Marketers, universities, the military, and even the automotive industry are also looking at agile methodologies or agile variants to deliver innovative products in uncertain environments.
At a very basic level, agile allows your company and teams to work in short bursts on very particular deliverables. At the end of the short burst of time — called an “iteration” — teams are expected to have those specific deliverables completed. This allows teams to adjust their focus, pivot when a customer changes their mind in the middle of a product build, and change priorities as expectations and feature requirements change.
In the software world, when a decision to build or further develop an existing technology is made, the end product may be hard to define. Agile allows for that ambiguity because of its flexibility to change direction on a project as work moves into the future.
Who Can Benefit from Using Agile?
Agile will not be the solution for all teams, but will definitely thrive in adaptive cultures where team members are quick to change if the outcome is a more productive work experience.
This methodology also works well with teams that get to work with minimal rules due to their high level of self-discipline. Teams must also be comfortable with collaboration due to the speed and focus needed to deliver product increments and quickly deal with issues that arise.
Comparison to Traditional Work Management
The waterfall methodology is a work management process with which we are most commonly familiar. Being very linear and sequential in design, progress on projects largely flows in one direction through certain phases, i.e. “downward” like a waterfall.
Originally developed in manufacturing and construction industries, the waterfall methodology allowed for a process like this:
The customer requests a product.
An entire plan to complete that product is designed.
The team follows the design to develop and eventually deliver the final product.
It is a much less iterative and flexible approach when compared to the agile work management methodology. With waterfall, random scope changes and requests are not easily accommodated when the end product is so highly reliant on the plan built off of the originally negotiated request or deliverable. When issues or unplanned work does occur, this often leads to firefighting and sometimes chaos to adjust the plan to meet new needs or expectations.
Traditional work management still reigns supreme for certain work environments, such as construction, where a well thought out plan for product completion is best met in this progressive, linear fashion.
Ability to adjust and pivot quickly
As the name suggests, the agile methodology allows teams to be better equipped to quickly change direction and focus. Software and marketing companies are especially aware of the tendency for changes in demand to happen from week to week.
Agile allows teams to re-evaluate the work they are doing and adjust in given increments to make sure that as the work and customer landscape changes, the focus also changes for the team.
Transparency into a team’s work
To accomplish this, agile teams use daily meetings called “stand-ups” to make sure the team is staying focused on the prioritized list of features or products to develop.
No longer do they experience the confusion of not knowing what everyone else on their team is working on. They keep regular tabs on what the team has accomplished from the day before, any issues/roadblocks they may have that need to be addressed, and what they plan to work on that day.
Having this transparency and unified direction allows everyone to move forward faster.
The final major benefit of adopting agile would be the feedback loop that is incorporated at the end of each iteration (remember — an iteration is a set amount of time in which the team has to work toward completing specific deliverables).
The feedback loop allows a team to look back at the last couple of weeks to determine what issues came up, how the plan may be changing moving forward, what the customer now needs if previous needs have changed, and lessons learned as a team.
Agile has several variants, but we’re going to focus on two of the main tenets: scrum and kanban. Let’s look at scrum first.
When you’re deciding whether or not to switch to scrum, you’ll need to look at the structure of your teams to see if they can easily transfer to the new methodology. A scrum team has three types of members: a product owner, a scrum master, and team members.
Product owners own the product and have the vision for what the product is or will be. They are a voice for the customer and the primary driver of business decisions and the prioritization of product features.
Scrum masters help the team get work done by finding needed resources and creating consensus among the team to be as productive and efficient as possible. They also facilitate communication throughout the process.
A team is usually cross functional and has members with lots of different job roles and skill sets. Members are in charge of planning, executing, and delivering product increments. They will benefit from being physically located in the same place or having access to tools that will allow for quick and easy collaboration, both with each other throughout the day and in their daily team stand-up meetings.
Working as a scrum team
Once you’ve assembled these key players, they will follow a new style of workflow for getting their work done and delivering a product to the customer. Again, in comparison to traditional or waterfall methodology, they will no longer follow a linear process of coming up with a plan for a final product, then going through the steps or phases needed to deliver that product. Instead, scrum teams will first build a backlog.
Building a backlog
The scrum team will look at a list of priority features and the desired functionality, which are referred to as “stories.” They need to ask the customer and discuss as a team what they want and need out of the system or product they are going to build.
Once they’ve created their major stories, they need to groom their backlog. As a team, they need to go through four major steps:
Break down big stories into smaller increments by discussing what needs to be done for each story.
Prioritize their stories and decide which features should be developed first.
Clarify the requirements and acceptance criteria for a story to be considered done.
Estimate the amount of effort they’ll need to expend to complete each story and the backlog. This can be done in hours or in points. Points allow you to tell how hard or complex the story is instead of planning out time required for each component of the story.
After the backlog is groomed and prioritized, it’s time to plan the iteration. Note that many organizations use the words “sprint” and “iteration” interchangeably.
The team decides on which stories to complete based off of stories that are considered ready to go. The team makes assignments and decides on the duration of the iteration.
Executing the iteration
Now, it’s time to execute the iteration. Team members begin to do their work like a traditional team would, but they now incorporate a quick, daily meeting called a stand-up meeting. Members of the team will literally stand-up for this short meeting and answer three questions:
What did I get done yesterday?
What will I get done today?
What roadblocks am I running into that are preventing progression of my assignments?
These meetings keep everyone on the same page and moving forward quickly.
Using a Burndown Chart and Storyboard to Track Progress
As team members answer these three primary questions during stand-ups, it’s important that they monitor and track their progress toward iteration completion. Doing so will allow them to determine if they are moving quickly enough through their stories to deliver all features on time at the end of the iteration. There are two components to do this in the scrum process.
Using a storyboard, teams will move their stories through status columns to show when work items are new, in progress, or complete.
A burndown chart can be used to monitor if the team is completing stories at a fast enough rate, or velocity. Burndown charts can be used on individual iterations or an entire product release.
At the end of an iteration, the team holds a product demo for the customer or stakeholders. This step allows the team to get feedback on the product delivered and where to head next in the upcoming iteration. If team members need to change direction, they would definitely figure that out during this step.
Finally, one of the most important steps in the agile process is the iteration retrospective. In this stage, the team gets together to look at what went well and what didn’t go well in the last iteration.
Another round of backlog grooming is done here. Look at the remaining stories. Do any of these need to be changed or broken down further? What is the team’s capacity for the next iteration? Discussion here allows the team to adjust moving forward into the next iteration.
Putting this all together, what does the process look like from beginning to end?
Create your team, consisting of a product owner, scrum master, and team members.
Build the initial backlog of stories (parent tasks).
Groom the backlog, refining the original stories into appropriately-sized chunks of work while clarifying what is to be done for each story (sub tasks).
Plan your iteration and establish your goals, including how much work you can complete with the resources you have and what your deliverable is.
Iteration execution. (Don’t forget about the daily stand-ups!)
Product demo — what was completed?
Iteration retrospective meeting — what did we learn? What went right? What went wrong? Do we need to add or change out any team members? Do we need to update any process or change deliverable expectations?
Backlog grooming meeting — how are the current stories? Do we need to break any stories down? What is our capacity for the next iteration?
Back to iteration execution.
Unlike other agile methodologies that focus on a cyclical process, the kanban methodology focuses on an optimized workflow. Kanban looks to improve the flow of work by visualizing it with a kanban board, setting a limit on the amount of work that can be in progress, and analyzing the flow to make continuous improvements. Let’s take a look at some of the key elements of kanban.
The key players in a kanban team are similar to those in a scrum team, except there is no scrum master. It may still make sense for someone to act as a project manager or supervisor, but theoretically this role should occur naturally as the need arises.
Visualization: kanban board
There are many ways to format your kanban board. Teams operate off of a board that have any number of columns. Each column represents the status of work being done.
In the most simplistic board, the first column might be “to do,” the second “in progress,” and the third “complete.” Many companies have their own terminology for the column names, or they may even list out each step in a process, but the intent is the same. Team members move their stories from column to column depending on what state the work is in.
Team members work with a product or project manager to make sure the stories in the backlog and other status columns are prioritized and that work continues to move forward toward completion. The product manager is still responsible for working to ensure that the customer’s voice is heard and the product moves in the correct direction.
Limit work in process
One unique aspect of kanban is that teams have a limit on their capacity for the amount of stories they can handle at any given time. Teams choose a certain amount of stories that they are willing to have in their “to do” and “in progress” columns and they don’t go over that number in order to prevent burnout. Once a story is moved to “complete,” a story from the backlog takes its place in the “to do” column.
Kanban allows for continuous improvement by providing a system for teams to measure their effectiveness. They can clearly see how their workflows operate, how long every piece of the workflow takes, and how often they are getting their deliverables out the door on time. This makes it easier to experiment with different ways of doing things to optimize output.
Questions to Ask Before Making the Switch
Before you jump into adopting agile, let’s look at a few questions that will help you determine whether or not it will be the right fit.
The first question to ask is whether delivering product or feature increments will be allowed at your company. Do you need to be able to change the focus or direction of that product in the middle of the process? In other words, are you starting a project without knowing all of the details of what the final product will look like based on the environment, future technological advances, or future wants and needs that aren’t apparent right now?
If you’re able to answer “yes” to the above questions, then so far, a transition to agile is looking good. Here is the second set of questions, focused on the infrastructure of your team and team members:
Are they located near each other?
Can they have daily stand-ups in person?
If the team is not geographically close, do you have technology in place that allows them to quickly collaborate?
Can you get everyone on a similar daily stand-up schedule?
Will they be able to work in iterations?
Are they commonly getting assigned work as a team or is everyone getting assigned work from random places?
Are the members of your group open to change?
Are they willing and able to collaborate and constructively discuss issues as they come up?
Do you have individuals that can take on the role of product manager or scrum master if using that style of agile?
These types of questions should be asked and addressed if you feel that certain aspects of a team may raise red flags as barriers to agile adoption. Although not all encompassing, this should get the conversation going before diving in.
Transitioning to Agile
Educate your team
Once you feel comfortable moving forward with agile, you’ll want to start by educating your agile teams on how they will transition into their new roles, when they will begin having daily stand-ups, and how they will transition their current work into their new storyboard setup.
What to watch for once you begin agile
After you establish transition steps and make sure everyone is comfortable with the new style of work, you’ll want monitor and track their progress and success.
If they are struggling to run at the same velocity as before, what may be causing those issues? If the team isn’t updating stories with their current status, have those statuses been clearly defined?
Tracking a new agile team’s progress or success will be very beneficial to giving it confidence in the changes. In addition, having these metrics will help justify the benefits of transitioning a team to agile when in higher-level meetings.
Finally, it’s important to provide your team and new scrum masters with a form that outlines helpful questions to ask during daily stand-ups and the iteration retrospectives. This provides some excellent documentation for future reviews of processes. It will also allow for the team to identify areas that need improvement and help it answer questions it may not think to talk about if it is new to agile.
Agile work management isn’t for everyone, but teams who use it correctly will experience enormous benefits, including streamlined work processes and rapid innovation. Use the information in this post as well as agile project management software from Workfront to get started.