I was recently listening to a podcast that really struck a chord with me. It wasn’t that the topic was brand new or something I’d never considered, but finally, there was a name for it! The hosts were talking about the idea of a rotation for handling bugs and unplanned work items that land in a development team’s backlog. This is exactly what my teams and I had discussed in a retrospective not too long ago. The difference is, we haven’t implemented it… and now I’m wondering, “Why not?”
First off, credit where it’s due. The podcast I was listening to was Episode 40 of The Rabbit Hole: An Inside Look Into Software Development.
In this episode, they explored the concept of a “Batman/Batwoman” support role, framing it as a rotational position focused on squashing bugs and dealing with all those unexpected items that always seem to pop up mid-sprint or right after you’ve kicked off a new project. This is precisely what my team and I talked about in past retrospectives and even a production support process meeting…
Unfortunately, like many things that come up in retrospectives, it got shelved for later. Well, I think it’s time to dust it off and put it into action!
So, why is this such a good idea?
As engineering teams and tech companies continue their DevOps journeys, a role like this becomes more and more critical. The merging of development and operations brings a lot to the table, both good and bad, and it’s something we as engineers and leaders need to acknowledge and prepare for. Whether you’re using Scrum or Kanban, in a DevOps environment, there will always be unplanned work. I just don’t believe there’s such a thing as a perfect application or architecture, so yes, there will be bugs, and there will be production defects. Not doing DevOps? I’d still bet you have unplanned work in the form of missed requirements or last-minute changes, on top of regular production issues.
Engineers work best without interruptions. I get it; I used to be one. So why do we, as leaders, expect them to switch gears so abruptly? Doing so causes unnecessary churn and wastes time. Engineers have to switch context from development mode to troubleshooting mode, then remember all the details of what’s currently broken. Once they’ve fixed the issue, they need to switch back to development mode, recall where they were in their task, and carry on as if nothing happened.
One of the best examples I can give is from my own teams. At the top of our Kanban board, we have an “Expedite” swimlane where high-priority stories or bugs land when they’re added to the backlog. These items should be treated with urgency, hence the name “Expedite,” but it doesn’t always work out that way. The idea is that when anything enters that lane, one engineer (or the whole team) should drop everything and resolve it quickly. But again, nobody really wants to jump on those items, for the reasons I mentioned earlier.
This, my friends, is where the Batman (or Batwoman) support role swoops in to save the day!
Security vulnerability? Batman.
Customers reporting issues? Batman.
AWS rehydration? Batman.
Timmy fell down a well? Batman!
So then, why don’t more teams do this?
Good question. I don’t know. Maybe nobody’s thought of it, or maybe nobody’s challenged the current process. But I cananswer some other questions you might have, and hopefully convince you to give this a shot. Keep reading!
Could this person get burned out?
Yes, of course. That’s why it’s a rotational role. Often, as mentioned in the podcast, the senior folks end up pigeonholed in this role. Sure, they’re experienced and probably have the most knowledge of a particular application or feature, but that creates an unnecessary “bus factor,” and others on the team don’t get to learn and grow as engineers. Don’t you think the senior folks get burned out, too? Plus, what better way to learn an application than by fixing bugs? Trial by fire, I say!
What does this person do if nothing’s broken?
Have no fear! I’d suggest they simply pair with another engineer. Two engineers working on one story would likely complete it faster, and we’d probably see a decrease in cycle time, an increase in throughput, and increased flow efficiency. All signs of better, more efficient delivery—and who wouldn’t want that? Pairing is also a great way to build your skills, learn new approaches, mentor others, or just build rapport with the team. You know what that leads to? Higher morale. If something comes up, the “Batman” handles it, and the other engineer can continue on their way.
How do you manage all this?
If you already have production support rotations in place, use them. Whoever is on call for the week can focus solely on production support, or maybe your backup person can do it instead. It’s up to your team to decide, and for you to guide them in the right direction. After all, Agile teams are self-organizing; our job is to help them succeed and give them what they need.
With all that said, my mind is already racing with other topics to write about in the future. I should probably share this with my team and pitch the idea again, too!
Until next time,
—Sean
If you found this useful, please share it with your peers, subscribe for future updates, or leave a comment below!
Leave a Reply