The case for the Batman Support Rotation
I recently listened to a podcast that resonated with me. It wasn’t because the topic of discussion was something new, or something that I hadn’t thought of before, but simply because I finally had a name for it. The hosts of the show discussed the idea of having a rotation for focusing on bugs and handling unplanned work items that enter into a development teams backlog. This is the exact same thing my teams and I discussed in a retrospective not too long ago, however we haven’t implemented it, and now I’m questioning why.
First off, I have to give credit where credit is due so, the podcast I listened to specifically was Episode 40 of The Rabbit Hole: An Inside Look Into Software Development.
In this episode, they discussed the idea of a Batman/Batwoman support role, and pitched it as a rotational position that focuses on squashing bugs and handling all those unplanned items that always seem to come up mid-sprint or right after getting started on a new body of work. This is exactly what my team and I discussed in previous retrospectives and even a production support process meeting…
Unfortunately, and as with many things that seem to transpire in retrospectives it got shelved for later. Now, I think it’s time to take it off the shelf and put it to good use!
So, why is this such a good idea?
As engineering teams and technology companys continue with their DevOps journey’s, such a role becomes more and more important. The combination of development and operations into one role brings a lot more baggage to the table, for better or for worse, and that’s just something we as engineers and leaders in this environment need to accept and prepare for. Whether you’re doing Scrum or Kanban, in a DevOps landscape there will always be unplanned work. I don’t believe there is such a thing as a perfect application or architecture so yes, there will be bugs and there will be production defects. Not doing DevOps? Well, I’d be willing to bet you that you still 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 that as I was one once. So why do we as leaders in such an environment, expect them to switch gears so abruptly? Doing so causes unnecessary churn and wastes time. The engineers must switch context by switching from development mode to troubleshooting mode, and then recollect the intricacies of whatever is broken at the moment. Once the dust settles, they need to switch back to development mode, remember where they were in the story or task, and carry on as if nothing happened. One of the best examples I can think to highlight this is with my own teams. At the very top of our Kanban board we have an “Expedite” swimlane where any 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 that way. The theory is that once anything enters that lane, one engineer (or the entire team) should drop what they’re doing and quickly resolve this item but again, no one really wants to tackle these items for the reasons mentioned above.
This, my friends, is where the Batman (or Batwoman) support role comes into the picture.
- Security vulnerability? Batman.
- Customers reporting issues? Batman.
- AWS rehydration? Batman.
- Timmy fell in the well? Batman!
So then, why don’t more teams do this?
Good question but, I don’t know. Perhaps no one has thought about it, or maybe no one challenged the current process. I will answer some other questions you might have though, and hopefully persuade you to give this a try. Keep reading!
Now, could this person become burnt out? Yes, of course, but that’s why it’s a rotational role. Quite often, and as mentioned in the podcast, the senior folks end up pigeon-holed in this role. Sure, they’re seasoned and they likely have the most knowledge about a particular application or feature, but that creates an unnecessary “bus factor” and others on the team don’t get to learn and develop as engineers. Don’t you think they (the senior folks) get burnt out, too? Plus, what better way to learn an app than via fixing bugs? Trial by fire I say.
You’re probably also wondering what this person does if nothing is broken, right? Well have no fear, I would say that they can simply pair with another engineer. Two engineers working on one story would likely complete it faster and in this regard, we’d likely see a decrease in cycle time, an increase in throughput, and increased flow efficiency. All measures of better, more efficient, delivery and who wouldn’t want that? Pairing is also an excellent way to build your repertoire by learning a new skill, practicing different ways of thought, mentoring others, or even just build rapport with others on the team. You know what this yields? Higher morale. If something comes up, they handle it, and the other engineer can continue on their merry way.
Lastly, what about managing all this, you ask? Well, if you have production support rotations already in place, leverage them. Whoever is on call for the week can solely focus on production support, or perhaps you have your backup person do it instead. Either way, the choice is up to your team to decide, and for you to coach them in the right direction. After all, Agile teams are self-organizing, our goal is to just help them succeed and give them what they need.
Now, with all that said, my mind is churning through some other topics to write about in the future. I should also probably share this with my team and pitch the idea once more.
Until next time,
–Sean
If you found this useful, please share it with your peers, subscribe for future updates, or leave a comment below!