Firebreak!

So when you’re doing Scrum (or another iterative process) the constant pressure to deliver business value can be a bit relentless and a side effect of this is that you do not get time to investigate new/alternative technologies, unless it is for a genuine business need, you may also find that often technical debt can build up due to lack of time in a sprint to fix it.

So to remedy this situation you can implement a firebreak week/sprint where the team is not tasked with delivering business value rather they are given the time to be able to investigate new technologies, clean up technical debt, etc.

The team can utilise this time in any way they see fit, it should still align in some way with what the business needs so that the business is still getting value from what the team does, but it is the team that gets to decide what they do and how they organise themselves to do it.

For the business the hardest part of allowing a firebreak is often the lack of control over what the team does and the concern that they’ll sit there all day doing nothing but in reality most teams grab the opportunity to do things that will benefit them in their work either now or in the future e.g. clean up technical debt, investigate a technology that could be used.

During the firebreak there does not have to be any daily stand-ups and you don’t necessarily create stories and tasks relating to what you are doing but as with all things agile you customise it your way so if the team still wants to stand up and tell everybody what they are doing then let them.

If the team are investigating many different things then it can be valuable for them to put together grok talks to give to the whole team to share any knowledge has been gained during the firebreak to ensure that the knowledge doesn’t remain silo’d with any individual(s) .

The value to the business of allowing a firebreak is that it helps to reenergise and motivate the team and provides an easy way to allow for R & D without impacting on normal delivery of business value. 

The firebreak can also be used to align development and business cycles, if you follow 2 week iterations then you find that the developers will have a sprint/iteration that finishes a week before the end of a quarter so what do you do - simply not worry about it and allow another sprint to start so that it overlaps, or would you rather have the next sprint start at the beginning of the next business quarter?  If you need to align the sprint cycles with business quarters then a regular firebreak at the end of each quarter allows the cycles to be aligned and keeps the team happy for the reasons outlined above.

So if you are doing scrum and finding the experience a bit like a hamster wheel perhaps you need a firebreak.