Deep in the agile software development landscape, there lives the Batman. No, not the billionaire in body armor with lots of gadgets and a gruff voice. The ‘Batman’, in software development, is typically a role on the development team that ignores the planned iteration scope and focuses solely on “emergency” requests, bugs, or anything requested of the development team that isn’t part of the planned iteration. By taking on those tasks, a development team’s Batman keeps the rest of the team’s developers from being distracted and pulled off of the iteration work.
There is a wealth of writing on the batman role out there but start with the Iteration chapter of James Shore’s ‘The Art of Agile’.
Rather than going deep on the concept of the Batman role, I want to focus on how Batman can help one type of team in a common situation, especially in smaller development organizations.
Using Batman for continuous development on a live product
In this case, our team is the sole team working on a live product, such as a production website. In this situation, there are many, many ways our team can be taken off course. But that also makes the Batman role very valuable when we’re in this context.
Let’s say our team is responsible for developing new features, taking care of any production bugs that come up, as well as performing our own dev-ops and keeping the production and development servers running. In that environment, our planned iteration is usually going to be focused on the new feature development and maybe some priority bugs that have worked their way into the backlog. However, every other responsibility mentioned above can and will take immediate priority over new feature development if it is allowed to, distracting the development team from the new feature and dragging out the feature development thereby forcing planned launches, marketing rollouts, etc… to be delayed.
So, how can our team use Batman?
- Assign a developer to be Batman at the beginning of an iteration. The developer filling the Batman role performs no work on the planned iteration. They are there to take care of “organizational emergencies and support requests so the other programmers can focus on programmering”, as James Shore puts it.
- When the team plans our iteration, in 2 week sprints, for example, we plan for one less developer being available for work on the planned iteration. That may sound like our team is losing the velocity that that one developer produces, however, that developer is going to shield the rest of our team from distractions. Without those distractions, the rest of the team will likely produce more than if they still had that developer in place but everyone was partially distracted.
- Shift the role to a new developer each week or each iteration in order to prevent burnout among the developers. This rotation provides the additional benefit of exposing different developers to different parts of the system so that the entire team gains more understanding of the codebase.
- Any “emergency” requests coming into the development team should already be flowing through a single point of contact (ideally the Product Owner in the case of Scrum). The point person should work directly with Batman to handle the incoming requests deemed to be critical and need immediate resolution.
Note: I would not recommend having Batman work on the planned iteration at all. That avoids the temptation for the team to plan in the extra capacity when we really have no idea if we will have that capacity or not. If Batman does have spare capacity, they can focus on other bugs and technical debt.
Who should be Batman?
Any and all of the developers should take a turn as Batman. Senior to junior, the brand new to the ‘been here from the start’. Many teams find that being Batman helps to onboard your new developers faster than just having them work on the simple element of new development.
Your junior developers will always need a little guidance and oversight from your senior developers and that goes for when either party is Batman. You still mentor and guide developers the same way regardless of which role they are playing today.
Do we really need Batman?
So, what if our team doesn’t get enough mid-iteration “emergencies” to justify a dedicated developer?
In this case, let’s take a look at how much external request volume we are getting and then consider the following questions:
- How much extra capacity would a single developer have if solely focused on those external requests?
- What could we gain by removing those requests from our team?
- Without the context switching would our team actually go faster?
- Do we have small, less-than-urgent bugs or technical debt that we would really like to clear one of these days?
Maybe after considering the questions above our analysis still points to no. And maybe that’s the right answer for our team.
Implementing the Batman role in your development team can be a highly effective way to handle new features while also being tasked with urgent outside requests. What I have presented is only one situation in which Batman can help a development team focus and perform. There are many other situations where the Batman role can help and many other ways to implement this role.