Scrum For Hybrid Teams
Hudl’s support team sets ambitious goals to be among the industry leaders in efficiency and quality. In my position as a Tech Lead in our support department, I work with seven others as conduits of information between our Product and Support teams and creators of tools and resources for our support team. We’ve always done our best to provide our support reps with the tools and resources to allow them to do their jobs at an elite level.
A few months ago, though, we realized that we were missing the boat in big ways. Each of us was becoming siloed in our areas of expertise and would do projects on our own. The net result is that we generally still delivered value to our team, but left a lot on the table because we were not collaborating on bigger high-impact projects. We made the call to learn and implement Scrum to increase our effectiveness. I use the term hybrid to describe our Tech Lead team because we do a combination of software development, data retrieval/reporting, and resource creation so we need a way to make Scrum work for all of these purposes. This article will examine a few of our areas of focus regarding Scrum for our team.
Clear Separation of Time
One of the first tasks a team works through during Planning for a sprint is budgeting time they will have available to work on projects. This will be all the days they aren’t out of the office plus some time here and there subtracted for things like management work.
For our crew we start with going through time we’re taking off that sprint, but the tricky part is that we all have at least two days of a sprint dedicated to being an escalated tech resource for support interactions, plus we have time we need to devote to working with our regular product squad (my squad, for instance, works on our Assisted Breakdown product that provides stats for teams across the world in American football, basketball, volleyball, soccer, and lacrosse.)
Our rule is to try and draw a line between work for the Support department vs work that directly benefits our coaches. For instance, if I write a SQL query that grabs support interactions from coaches who had issues with submitting a game to be analyzed by us, is that data helping support reduce interactions in the future or is it helping our product team by steering them to create a software solution to fix the problem?
We settled on a question that helps to define this separation: “If I’m not a Tech Lead on my own particular squad do I care about this work?” We consider this question in Planning and if a story doesn’t fit this criterion, we will close it and move it off our board.
Selecting the correct Product Owner
Traditionally a Product Owner of a Scrum team is responsible for picking the problems a team tries to solve and ultimately decides if the solutions a team creates actually solve the problems they set out to solve. It’s important that the Product Owner, even for a squad like ours, is separated from the day-to-day work.
This allows our PO (our Support manager) to more objectively look at problems through the lens of “Is this a real problem?” “Would it be valuable for us to fix it?” vs “Do we have the engineering/training/data ability to do this?” Having this separation has forced us outside of our comfort zones and allowed us to develop skills we wouldn’t have had to develop otherwise. In particular, our whole team has gotten much more comfortable with our company data and SQL to be able to pull relevant data for our Support Quality and Training team. This has helped us raise our approval rating from our users in the past month.
Focus on Problems
Since we aren’t focusing on one big problem (or a few big problems) like a traditional product team would, it’s tempting to try to solve a big number of problems in a sprint to demonstrate how much value we’re bringing to the table with our work. This mindset hurt us early on as we were implementing Scrum. We would throw a lot of tickets into a sprint and knock them all out. In our Review meeting it was sometimes hard to pinpoint the direct value some of the work created.
Recently we had a meeting to decide how to more intelligently serve internal knowledge base articles to our Support team based on the time of year. The first 15 minutes we were working toward a solution that would pull our most used articles using a query of our support tickets from past years. It was going to be a time-consuming effort. During the meeting, though, we shifted the conversation to ask what the real problem was.
We realized that just posting these links every week wouldn’t help our team that much because we weren’t getting them resources when they needed them. We realized that the core problem was that our search function in our internal KB wasn’t getting articles to our team quickly and easily. We realized that we needed to focus more on making better-labeled resources and cleaning up non-relevant articles so they wouldn’t show up in a search.
Because of this scrutiny, we saved days of work that wouldn’t have been nearly as valuable to the team overall. Whenever you get stuck (and no matter how much time you’ve spent on the solution you’re discussing) always be brave enough to stop and ask if you’re truly addressing the correct problem the correct way.
Above All Else: Trust the Process™
When you first learn Scrum, it’s reinforced often how important it is to commit fully to the meetings and processes. If your squad’s full time isn’t devoted to your Jira board, though, it can get easy to slough and feel like you’re doing as well as you can do with the time you have. It’s very important to fight this urge, though. Scrum only works when you buy in completely.
There are times when standup or Planning will come at less than opportune times that leaves our department short-staffed in areas. We are accepting of that because we timebox our meetings well and know for exactly how long we’ll be short-staffed. Instead of postponing or rescheduling that meeting, we will examine in Retro if there’s a better time to do it in the future to avoid issues. You basically need to follow the idea of “act now and ask questions (of your team) later.” Take the long view and understand that some growing pains with timeboxing meetings will pay off in the long run when your team’s productivity improves over time, and projects increase in relevance as you get better at honing in on the core issues you need to solve.
I hope for this to be just the first in a series of posts on this issue. In just two months, I’ve become a real proponent of Scrum (hopefully that comes through in the article) and am looking forward to finding and sharing more growing pain and lessons we learn along the way!
