A decade ago, the war room model was a popular approach for problem solving in computer software development. Sometimes called extreme collaboration, the basic approach of the war room is to round up a group of people who don't always work together, put them in one place, and set them to finding a solution to a critical problem. The premise is that in-person interaction and a singular goal will lead to new thinking and a quicker, more effective solution.
When nations had conflicts, they often resolved them by engaging in war. But many nations have moved away from that type of solution and found alternative ways to solve the conflict, in the same manner that many organizations also moved away from war rooms to smooth and stabilize software release models. DevOps is one of the best replacements for the software release war room.
Using the war room model for software release is not a good idea because:
- The war room requires effort from valued associates in an organization. Instead of working on new features for tomorrow, they are fixing yesterday’s problem.
- Fixing an issue in production is way more expensive than fixing it in the development cycle.
- They lead to protecting and bouncing discussions rather than a productive resolution.
- "If all you have is a hammer, everything looks like a nail." Give a small boy a hammer, and he will find that everything he encounters needs pounding. War room participants often approach problems from their own narrow perspectives, leading to a lack of coherence.
- War rooms are reactive and not proactive, which leads to poor decision making.
Can we avoid war rooms? Yes, we can avoid them by adopting the following Agile and DevOps best practices:
- Instead of testers finding 10 defects a day, educate developers on common mistakes so that they are avoided from the start.
- Plan for smaller sprints, and deliver value in every sprint.
- Deliver priority features first.
- Continuous delivery works, but it can’t be done halfway. Continuous delivery must be the priority of sprint 0, not sprint n.
- Automation is the key; implement automation to monitor tests, analyze results, and also ensure quality of the build tool.
In today’s competitive market, organizations are considering Agile not only to reduce ready-to-market time but also to reduce waste, and software release war rooms are a key waste. So, next time your software release is in crisis and you have the option to set up a war room call, I would recommend that you lose the war, because the quickest way to end a war is to lose it. And if you claim that your program/project is already adopting Agile or DevOps and you're still planning to schedule a war room call, then you need to answer this question first: Where did my release train derail?