Is Agile Right for Customer Support Teams?
If you’ve worked in the tech industry over the last 10 or so years, chances are you’ve heard of the agile working method. Most probably associate it with software development (that’s where it got its start), but these days it’s not uncommon to hear non-technical teams — everyone from folks in HR to contractors remodeling bathrooms — talk about working in sprints and doing retros.
Though using agile certainly has merit outside of tech settings, it does have its limitations. In this article we share what agile is, how it works, and explore whether it’s a good fit for customer support teams.
Read on if you’re curious to see how (or if) the framework could be right for you.
What is agile?
Agile methodology is a project management framework that breaks work down into smaller iterative cycles. Instead of trying to plan out an entire project from start to finish (this is often called a waterfall method), you’re encouraged to take on bite-sized tasks, complete them, and continue on or pivot if things change.
A lot of those ideas are codified into the agile manifesto. The manifesto has twelve core principles which support four main values:
Individuals and interactions over processes and tools.
Working software over comprehensive documentation.
Customer collaboration over contract negotiation.
Responding to change over following a plan.
In general, the purpose of agile is to create momentum, to allow space for change, and to complete work more efficiently.
Before we dig in
It’s important to understand that there is no one, specific way to be an agile team. Every team has its own specific needs, and what makes them “agile” is the act of agreeing to a set of practices and sticking to them.
Although I’m going to describe a typical setup for software development orgs below, remember that it doesn’t work like this in every team, and how you choose to approach agile may also be different.
Agile workflow
As mentioned earlier, work by agile teams is done in sprints. A sprint can vary from one to four weeks, though from my experience I’d say that two weeks is probably most common. At the beginning of each sprint, the team decides on what work they’ll complete and creates a sprint backlog.
The sprint backlog is essentially a list of all of the individual tasks that team members will complete during the sprint. The tasks themselves are known as product backlog items or PBIs. In addition to the list of PBIs, the sprint backlog will also include a basic plan for how the team aims to complete them.
Teams operating using the agile framework have several recurring meetings, which are referred to as agile ceremonies. They include:
Sprint planning: This is when the team decides what work they’re going to complete in the upcoming sprint, and it’s when the sprint backlog is created. While every sprint planning session involves creating a backlog, the first one for a project is sometimes referred to as a “sprint zero.” This is where the team creates the initial backlog by detailing all the work they expect to do during the scope of the entire project.
Product backlog refinement: This meeting happens one time per sprint and is when the team takes a look at the planned work and decides if it’s still relevant or needs to be updated or removed from the backlog.
Daily scrum (or daily standup): As the name suggests, this meeting happens daily. It’s a quick huddle where team members give status updates, surface any blockers, and ask for help if they’re stuck.
Sprint review: This meeting happens on the last day of the sprint and is where the team shows stakeholders what they’ve completed and gives them the opportunity to provide feedback.
Sprint retro: This is the final meeting of each sprint and is a chance for the team to talk through what went well and what could be improved during the next sprint.
Agile roles
As agile teams work through a sprint, they each have a specific role to play in the process.
Product owner: The product owner is like the CEO of the team. They set priorities and work with the customer to gather requirements. Who the customer is depends on your specific circumstance. Sometimes it’s the end user, and sometimes it’s an internal stakeholder. They also create sprint goals and manage the team backlog.
Scrum master: The scrum master is essentially a facilitator. They help with running the different agile ceremonies, remove blockers for developers if any arise, and play a supporting role to the product owner.
Developers: These are the “hands on keyboards” people. Developers own the PBIs for a given sprint, and the other team members exist to support them and limit distractions so they can be as productive as possible.
Agile teams are self-organizing, so the members decide what work they’ll take on individually. This is a little different from non-agile workflows where work is assigned by a leader or manager. The pitch for this working method is that it gives the team agency and flexibility to work on the things they want and then to pivot if they need to. Then, at the end of each sprint, the team takes time to reflect and to talk about what went well and what could be improved moving forward.
Now that you have a baseline understanding of what agile is, we can tackle the bigger question.
Recommended Reading
Is agile right for customer support teams?
The answer is complicated, so let me explain.
As mentioned before, most proponents of agile believe that it is the best method ever and that it will improve everyone’s existence. They tend to evangelize to the non-believers as much as possible. You know … like Phish fans.
(But, seriously, have you heard the 1997 November 17th “Ghost” jam? It. Will. Change. Your. Life.)
Though agile is certainly very useful in a lot of different work scenarios, it’s not right for all types of work. Thinking about my own time spent working in customer support, I believe it’s fair to say there are two distinct work buckets: queue work and project work.
With that in mind, I think it’s best to address each of those buckets separately.
Side bar: If you’re a support leader, please, for the love of all that’s good, consider giving your team the opportunity to do some sort of project work. As a former support agent. I can tell you firsthand that only doing queue work is arduous and can make it very easy to burn out.
We are Sisyphus and support tickets are our rock.
Is agile right for queue work?
The short answer is no. There are a few specific reasons why not.
Queue work is reactive
When I worked as a support agent, much of the job was responding to customers. Advances in AI are certainly changing that to some degree, but it’s still a core function of most support teams. Since you don’t know what the next request will be or what it will concern, you can’t plan for it. Agile relies, to some degree, on knowing what work needs to be done. For queue work, that’s not a luxury you typically have.
Queue work requires immediacy
Along with being reactive, a big part of customer support work is speed. You can’t take time to map out what you’re going to do; you need to dive in as soon as a request hits your inbox. If you were to wait until a new sprint to start on a request, that would mean the customer would also have to wait longer for a resolution. This, as research very clearly shows, is not a good thing.
Queue work is continuous
Following a similar thread as above, the queue is essentially a living thing that keeps growing and changing. One could argue the goal is to get to inbox zero, but customer support doesn’t stop. There’s no end point, and because of that, there aren’t any individual items to deliver and an overall project to manage.
Agile is a tool to manage work that has an end, and while each ticket and request certainly has one, the queue itself does not. The act of planning out incoming messages in a sprint would just add more work for teams that tend to already be overburdened, and it would likely slow down how quickly customers get help. It’s what the youths call a “lose-lose” situation. Or a 6-7? A skibidi?
(Let’s face it, I have no idea what the youths are saying.)
Is agile right for non-queue work?
In this case, the answer is an emphatic yes!
Agile is purposely built for project-based work. Things like building or updating a knowledge base, creating a voice of the customer report, or even training AI agents are all things that could benefit from using agile methodology. It can help give structure to those projects, improve transparency, and increase efficiency.
Using agile could also be a great way to make room for more members of your team to work on those projects. Since things are broken down into bite-sized chunks, it makes it easier to let everyone interested in a project take part. These smaller tasks also help reduce the burden of a project, as no individual team member has to shoulder the weight alone.
Finally, the experience of everyone pitching into a project can help the team form a closer bond. Working together toward a common goal is a great way to build rapport; it’s something I’ve seen many times since I made the switch over to being a product owner.
Recommended Reading
Other agile benefits to consider
Even if your support team isn’t using agile in their daily work, there are still benefits to introducing them to the methodology.
To start, it’s possible that your staff may already be interacting with a team that operates this way. If that’s the case, knowing the agile framework can give them the necessary vocabulary to help communicate more effectively with those teams. It could also set agents up for future success if they’re interested in switching into a more technical role in the future. Having that exposure could help smooth the transition and give them an advantage when making that change.
For team members sticking with a career in support, a deeper understanding of agile can provide insight into why your company’s dev team is working on a project or explain why a certain bug fix or product feature isn’t at the top of their priority list. Some companies even allow for a support team member to join in on some of their dev team’s agile ceremonies to get a deeper look (and potentially have a voice) into what they’re working on.
If you’re interested in starting small, it’s easy to add a bit of an agile flavor to the way your team works by instituting a bi-weekly support retro where you go over how everyone is feeling, what’s been working well, and what can be improved.
Creating opportunities for team members to interact and share knowledge is a great way to help them feel more connected to one another, and it has the potential to give team members new ideas and tools to empower them to do their best work.
Recommended Reading
Seeing it in practice
If your interest is piqued, here’s an example of how you could use agile to manage building a knowledge base.
Create your sprint team
When creating a sprint team, the goal is to have all the skillsets to complete a given project without needing outside help. For building a knowledge base, that might include a couple of support folks to write the articles, a designer and developer to actually build the pages, and a support lead to select the knowledge base software you’re planning to use. Having the necessary talent helps you be self-reliant and reduces bottlenecks.
You also need to decide who the “product owner” and “ scrum master” are for the team. Usually these would be people who aren’t doing the work themselves, but in a support scenario, maybe the support lead could own the product and lead the scrum. It just depends on what would work best for your team.
Decide on sprint length
Though two weeks is most common, sprints can be as short as a week and as long as four weeks. Decide what length makes the most sense for your project, as it will dictate when your team meets and how much work you bring into a given sprint.
Create an initial backlog
The point here is to get as granular as possible. No single task should take longer than a single sprint to complete. Some even say tasks should be broken down so they take no more than a day to complete.
Since we’re using the knowledge base build as an example, this could mean tasks like doing research, creating individual article pages, creating visuals, etc. These items create your project’s initial backlog, but as the backlog is dynamic, you can always add and remove tasks as needed.
Do sprint planning
This is where the team decides what work they’ll take on. An early sprint goal for your project might be “Create an initial list of 20 articles to include in the knowledge base.”
Using that goal, the dev team (or in this example, the support pros writing the articles) can pull in different PBIs to that sprint. Remember, teams self-organize so there’s no assigning work. The team members themselves choose.
The PBIs could include things like checking your help desk’s reporting feature, reading through support tickets, or talking to customers to understand what content would be most beneficial.
Hold daily scrums
Once the team begins to work, they need to meet daily to raise any issues or blockers they’re running into. In this scenario, someone might realize they don’t have the right permissions to check your help desk’s reports. The “scrum master” would then prioritize getting that team member unblocked.
Do a sprint review
When the sprint ends, it’s time to review how the team did. Were they able to get their initial article topics selected? Were there any roadblocks? Did stakeholders feel they were the right topics to prioritize? Using those learnings you’ll be able to refine your approach and become more efficient in the project’s future sprints.
Remember, there is no right way to handle this process. The agile method is, well, agile. The example above is just a suggestion on how you might go about this project, but you’re free to modify as needed. Want to meet every other day instead of daily? Go for it. As long as the team is in agreement, you’ll be in good shape.
Recommended Reading
What are some good resources to learn more about agile?
There are many wonderful resources to learn more about the agile methodology. Below are some options to get you started.
Websites
Scrum Alliance: The Scrum Alliance has a number of free resources as well as paid classes if you’re looking to get certified in different areas. For support teams, certifications are probably a bit overboard, but it’s still a good site to visit to learn.
Agile manifesto: The agile manifesto is a good starting point. It outlines the main agile principles and gives context for some of the practices in the framework.
Bringing agile to customer care: This is an article specifically about using agile in a customer service team and could be a useful guide if you’re looking to implement the practices.
Books
Scrum: The Art of Doing Twice the Work in Half the Time by Jeff Sutherland — This is an in-depth book about the agile framework written by one of its co-creators. If you’re serious about diving in deep, it’s a good thing to read.
Essential Scrum: A Practical Guide to the Most Popular Agile Process by Kenneth Rubin — This is more a practical guide of how to implement the agile framework in a number of different scenarios. It’s a good, pragmatic look at how you can actually utilize agile for your benefit.
Videos
There are tons of YouTube videos, like this one, that can help you and your team get familiar with the basics of agile.
While I think all of the resources above are great jumping off points, I actually recommend finding time to talk to a team — preferably at your own organization — that is currently using the method. Agile is just a framework, and the way teams use it can vary. Seeing how it’s already being incorporated in your specific environment can give you a head start in figuring out how to introduce it to your team.
Agile (when useful) forever!
Agile might not be the best thing for daily queue-based support work, but that doesn’t mean learning about the framework isn’t useful to a support team. Knowing the basics and applying some of the principles could help improve team cohesion and set your support pros up for success in their current work and even in future roles.
While agile is pretty ubiquitous and might not be the biggest game-changer for every team, it’s worth learning about, as having another tool to use to your advantage is never a bad thing.
Jesse Short
After spending a few years working as a support agent, Jesse made the switch to writing full-time. He is a Help Scout alum, where he worked to help improve the agent and customer experience.
