Developers love to feel themselves “important” and often they gets excited and prance when they are awarded with the role of firefighter and they are called to solve an emergency.
From different sources I read that the “firefighter practice” is “supported” by Scrum and Agile, if it is provided for a limited time and if it only takes a small percentage time of an iteration.
Well, this is absolutely false! Agile doesn’t contemplate the “firefighter” role. On the contrary, this role goes in the opposite direction of the first Agile Manifesto Value:
Individuals and interactions over processes and tools
In addition, the strong reference to timing and percentages should reflect you.
A Development Team (not only an Agile Team) is a complex and alive reality, with its own roles, on which the company has spent a lot of resources to transform it in an ecosystem that creates Value. Thinking that someone can be a “firefighter”, undermine the Team foundation and create members of class A and members of class B, generating physiological internal frictions and undoing the hard work done for the establishment and maturation of the Team itself.
Furthermore, this approach limits the know-how and the growth to a single Team member (or a subset), creating inequalities and demolishing the idea of cross-functional Team.
Also, who decides who is a “firefighter”? The Scrum Master, the Team or the Team Member himself? If the “firefighter” is chosen, we return to the command-and-control pattern, the antithesis of the Agile core, if the “firefighter” is (self) appointed, the Team is far from being a real High Performance Team.
In short, it is evident that this practice is a real Anti-Pattern that only gives the illusion of resolving a problem in a fast way, but it creates big problems in perspective, going to degrade the Team and, consequently, its ability to create Value.
