You know what? Scrum is amazing until it's not. For some teams, I find that Scrum can feel like the villain, not the hero. Scrum promises agility, but for some teams it just delivers a bunch of chaos. Scrum can feel like a micromanager more than a framework. And when your work is predictable or best done just on your own, Scrum doesn't just feel useless. It feels like overhead. Scrum gets all the hype, but what if it's the wrong tool for the job?
I hear it a lot. I was just with a team this week, which spawned this video, that they have a lot of different types of work that they do within their Scrum team. The organization has mandated Scrum. I don't necessarily disagree with that. An organization having a common way for people to work might be a good thing, might not.
Obviously it depends on how it's done, but when you have multiple teams kind of forced to use Scrum and a lot of their work doesn't fit the model of Scrum, it can actually be a disaster. So that's what I want to tackle right now: what can we do if your team works on a lot of different types of work that may not be suited for Scrum in all instances?
The Problem: When Scrum Becomes Overhead
I had a team that was working on data and infrastructure, and I would call them more of a networking team, not necessarily a data development team. So they managed the data center. They did support across all the network in the corporate headquarters, but they also had these jobs for setting up corporate events, like setting up a ballroom for audio visual and all this kind of stuff. And they were forced to use Scrum and they found it really difficult to try to use and actually felt like it was micromanaging and overhead for them.
Understanding What Scrum Is Really Built For
So let's first start. Scrum is amazing for complex work that is unpredictable, unrepeatable, and imperfectly defined. That's how we usually set the stage with Scrum. Now, on top of that, when you have that situation, collective intelligence is the winner. So none of us are smarter than all of us together on a cross-functional team. Hence the reason we have a cross-functional team.
What that means is we need to have all skills required to build an increment of the product that somebody can inspect and tell us if we're on the right path or not. But we also need to inspect it as the builders of the product and say, is it engineered in a way that we're happy with? But some of our work doesn't necessarily either require a cross-functional team or require the collective intelligence of all of us trying to sit around and figure out the best way to approach something.
Scrum's Origins in Software Development
Now, Scrum was actually invented for software product development teams. So I would say in their world, a large percentage of the work that we work on should be a collaborative feature set, some business automation that we're trying to solve for the business, requires us to collaborate with the business, understand their process, and then us as a team making sure we understand what it is. And we have programmers and testers and database people that all have to come together to build an increment of that feature together.
I liken it to working in a kitchen where everybody has different skills, trying to serve the customer all at one time requires a great deal of collaboration. In fact, if you watch those cooking shows like Hell's Kitchen or Master Chef, you'll hear them say "four minutes left on shrimp, two minutes on rice," and they're highly collaborative. But if you're telling me that I need to go to two conference rooms today and set up a TV and connect it to the network, I don't need a large degree of collaboration for that.
The Hybrid Solution: Combining Scrum with Kanban
So I want to point out how we can likely handle some of that work. I don't want to necessarily say that Scrum's a bad fit for that. It just may be that we narrow our focus on what we use Scrum for and have somewhat of, I hate to use the word hybrid, but it's more of a hybrid approach to doing that.
How Traditional Scrum Works for Complex Features
I've got an example here. This is just a Scrum board that I've drawn out. And basically if we were to have, let's say a search feature on the product backlog, a payment with MasterCard, forgot password workflow, and maybe some kind of systems notification, just a garden variety software team, product backlog, well then we would go into sprint planning and say, okay, based on the acceptance criteria of the search feature, what are the different things that we have to do to build that out?
And so we might have to write some HTML to get a page together. If you're using Ajax or something similar, there's got to be something on the backend that is surfacing some data. We've got to create some test cases. You might use an MVC style framework or whatever you're using where you've got to do an active record implementation with the controller model, whatever it is that you're using. And we would try to articulate that in sprint planning and you would require programmers and testers and database people to kind of work together.
And then throughout the sprint, we would basically be checking in every day, Hey, how are we looking on this? The chefs in the kitchen that are trying to collaborate on those things. And of course as we go through the sprint, there's going to be some things we forgot about and we need to add some things in based on what we find. But that's where the sprint backlog is going to help us coordinate and collaborate that on each and every day.
Handling Unplanned Work
The problem is what if we have some work that comes in like a support issue? We don't know about that. How can we plan a sprint for that? Well, Scrum's not saying you've got to plan 100% of your team's capacity. We definitely want to reserve capacity for unplanned work to come in. And when I say unplanned work, it's going to happen. We just don't know what it is. So all I'm saying is let's squeeze our capacity down and not plan a hundred percent of our capacity.
So we would say, yeah, on average we get X amount percent of our time gets dedicated to unplanned work, and I like to classify those more like emergencies. So there's going to be some things that come in that the server's down and the customers can't use the product. We're not going to say, sorry, we've already stopped or started our sprint. We're not going to stop it and do that. No, we would leave some room in and probably take those in without a fair degree of conversation at all.
The "Disturbed" Role
If somebody would come in and say, we're having this issue, and the team kind of decides how to handle that, I typically like to have somebody called a "disturbed" that would be the one who kind of picks up all the unplanned work. And then of course if they need help, they go ask the team. But that way we're only interrupting one person maybe. So we reduce their capacity in the sprintable work and leave them reserved for the times for the unplanned work. And then of course if they don't have any of that, they go help the team. If the team's going faster than we thought, we'd bring in more work from the backlog. It's easy peasy that way.
But emergencies are part of our unplanned work, but there's also things that got bigger than we thought. So most engineers can't think of every single thing they have to do in sprint planning. So along the way, we tend to uncover some work or some things got bigger than we thought or there's some things we didn't think about at all. That is all just handled in the natural course of the sprint and is part of our Scrum capacity.
Creating an Expedite Lane for Non-Collaborative Work
However, there's some work that may come on this network infrastructure team that also did audio visual work where they're like, I don't need to collaborate with a bunch of people. We just got a help desk ticket to roll a TV down the hall. Do I need to get the team together and figure out how to do that?
So if you're looking at a Scrum board, sometimes what I'll say is you can take somewhat of what we would call the hybrid approach to this where we might draw a line down here and have what you would think of more like a Kanban type activity where work just comes on the board. We limit the work in progress based on the issue types and the swim lanes. We can follow all that as much as we want, but that way it could also be like an expedite lane. Anything that shows up here, just anybody can take on and then move it to the course of done. But it wasn't necessarily part of our sprint. It's not part of our velocity. We may not even track the work or estimate it or anything like that.
Application for Software Teams
So that's one option even for software teams to have something below the board. If you have a database person—I grew up being a database person, I say they're people too—well, there's a lot of work we do that's just completely unrelated to the stuff we're doing in the sprint. So we may get something from our data manager that says, Hey, we need to upgrade this core index. We need to do this, we need to do that. They need to have a place to show that work and make it visible and we can just pick it up. And that's a good way to do that as well with minimal overhead.
Practical Application for Infrastructure and Support Teams
But going back to our infrastructure team that also supports setup for AV rooms or remodeling of conference rooms and things like that, if you think of an operational support team, when I get a ticket to create a new account on our, let's say, Active Directory or Microsoft Teams or whatever, I don't need to collaborate a bunch of people to figure that out. But there are times where we still are working on projects.
Identifying Project-Level Work vs. Ad Hoc Work
So what I tend to think of with those teams is we will sit and think of different situations. What are the different styles of projects that we get? And so I might say, well, what are the projects we would tend to work on? And they would say, well, setting up a ballroom for a big event that would require a cross-functional team, right? We'd have audio visual team, we'd have networking, we'd have lighting, and that would probably be something that your stakeholders would want to know. How are we progressing on?
So my litmus test for all of this is if we are trying to report back on how things are going, when are they going to be done, and their larger projects that span a lot of time, then you can somewhat divide your capacity by project level work and ad hoc level work. And I could say, well, let's just put the ad hoc level work on a Scrum board down here, and then our project level work can go on the top here.
Structuring the Board for Mixed Work Types
So we might have a project that says, get the ballroom completed. We might have another project that says we need to build out the data center in Phoenix, and that's going to require a lot of different skills and ability to do that. So if we have the ballroom and the data center work and all these other things, those are projects that would require cross collaboration. Well, we could use Scrum for those.
We could estimate these and say, this is 20 story points and this is 10 story points, whatever it might be. And then they go on to a product backlog, and we would say, maybe the user story is to get the ballroom done, or if it's large enough, it might be an epic. And then we would break it down into the smaller stories. But those could go through a Scrum process that requires us to plan the work, execute the work, look at it every day, and finally report back that it's done.
But all along through the sprint, we also have little things that come up: create an account for this person or respond to this user as having a problem setting up their Mac. Those kinds of things can just come on the board, and we would reserve some percent of our capacity to go through that.
Balancing Sprint Capacity Between Project and Ad Hoc Work
And so when you look at it with the Scrum team, you might say, okay, of a sprint, two week sprint, one week sprint, whatever we're doing, it may just be a small 10% of our team's time is going to go to the Scrum projects. And then the rest of the work is going to be the more ad hoc stuff that we just do on our own based on our skillset.
And so all I'm trying to say is minimize the overhead to that, right? So if I don't require a lot of collaboration, I just need to sit there and help somebody with their help desk ticket, it is overhead to sit there and try to plan that in a sprint and figure out how we're going to do it. And I think a lot of teams get frustrated by that.
Reducing Ceremony Overhead
And so maybe a good exercise would be for the work that requires timelines and complexity and has a lot of people involved, you just reserve some percent of your overall team capacity for those activities. And then that way you're going to spend a lot less overhead in those activities. So if you do a one week sprint and are only planning 10% of your capacity, sprint planning will go like that. Sprint review will go like that. So it doesn't feel like a whole lot of overhead, but it's also serving as an indicator to your customers who are writing checks. When am I going to get my stuff?
And then the stuff that we have to do for ongoing operational support, like a denial of service attack comes up. Well, I don't need to sit around and plan that for a sprint. I don't know when it's going to happen, but I know something like that is going to happen. And you have a technique to just put that more on an expedite lane and maybe people assigned to the expedite lane, but then we may have a network swim lane. If you're a network person and somebody says, we need something with this, the network, and it's not a project, somebody from the network team takes it or someone from a server administration team does.
Infrastructure Teams Can Practice Scrum
I hear it a lot from infrastructure teams that they can't practice Scrum. I don't think that's true. I think there are projects that they need to get done that require collaboration, like moving to a new data center that would be perfect to use for Scrum. And they may say, well, it's still not complicated. I know what to do. Well, I get that, but it still requires some coordination across our team, and the longer term goal needs to be visible to somebody who's writing the check for us.
So not everything we do is for the team. I got to keep that in mind as well. There's sometimes the people that are paying for the team want to see transparency and be able to make better decisions. And Scrum was built just for that.
The Power of Visualization
But so we can use Kanban to visualize the work as well, or use a blend. And I'm not really saying something like Scrumban or anything like that. I'm saying use Scrum for the projects that require degree of collaboration and shorten your capacity for those, and then maybe use a Kanban board for the other things, really lightweight, trying to help the team coordinate and collaborate, but more importantly, visualizing the work. And that's what it's really all about in any kind of agile practice. Because of the goal of empiricism: inspect, adapt, and make visible. Make visible is where we typically need to start.
Key Takeaways and Next Steps
So use your best judgment. Collaborate as a team, and try to figure out what is the best way to visualize this work so the people that are requesting it know how it's progressing. So next time your team feels like they're strapped with overhead, they don't need to use Scrum. Perhaps this would be a technique that you could use. Shorten your team's capacity for the Scrum work, do everything else however you see fit.
Learn More with Big Agile
Hope to see you at another time in one of our videos. Check us out on our blog. Feel free to subscribe to our newsletter, and I'd love to see you in an upcoming class in the near future. If you're ready to take your team's agile practices to the next level and learn how to apply these techniques in your specific context, explore the classes that Big Agile offers and find the right training for your team's needs.