3 ms·

You need to introduce firebreak sprints. Take a week off every fourth sprint (or whatever) and give devs the freedom to build whatever they think will need doin

You need to introduce firebreak sprints. Take a week off every fourth sprint (or whatever) and give devs the freedom to build whatever they think will need doing to make the system better overall. You’ll get a bunch of preventative maintenance that you knew needed doing but never found time to do, but you’ll also get the occasional mad idea that turns out to have big benefits.

danuker 4y ago
Firebreak tasks (not sprints) should be taken naturally as prioritization chooses them over other tasks. Sadly, with higher interest rates, there is a pressure to produce results in the short-term, at the expense of long-term investments.
- piva00 4y ago
  Higher interests or not the pressure to deliver value and growth every quarter has always been present. In tech especially as we're seen as a hypergrowth model and not growing quickly every quarter is a sign of failure to the expectations of the market™. I've been working in this industry for 18 years, in different countries with different central banks rates and macroeconomics conditions, it's always been the exact same.
nonethewiser 4y ago
I dont see why those ideas couldnt be identified and sprinkled into regular sprints. The idea of a forced break to do these things implies they arent important. Otherwise they should already get picked up.
- VyseofArcadia 4y ago
  I've been in orgs in which developers are considered grunts and no one listens to their feedback. It's not that they aren't important, it's that the PMs/managers/whatever know better. I see firebreak sprints as a symptom of an org not valuing engineer feedback. "Let the grunts blow off some steam or they'll get disgruntled and leave."
- micromacrofoot 4y ago
  because sprints don’t allow the idle time that’s often needed to come up with such ideas. I could probably work for a year on “oh I’ve been meaning to look into that” tasks that have no clear outcome

danuker 4y ago

Firebreak tasks (not sprints) should be taken naturally as prioritization chooses them over other tasks. Sadly, with higher interest rates, there is a pressure to produce results in the short-term, at the expense of long-term investments.

piva00 4y ago
Higher interests or not the pressure to deliver value and growth every quarter has always been present. In tech especially as we're seen as a hypergrowth model and not growing quickly every quarter is a sign of failure to the expectations of the market™. I've been working in this industry for 18 years, in different countries with different central banks rates and macroeconomics conditions, it's always been the exact same.

nonethewiser 4y ago

I dont see why those ideas couldnt be identified and sprinkled into regular sprints. The idea of a forced break to do these things implies they arent important. Otherwise they should already get picked up.

VyseofArcadia 4y ago
I've been in orgs in which developers are considered grunts and no one listens to their feedback. It's not that they aren't important, it's that the PMs/managers/whatever know better. I see firebreak sprints as a symptom of an org not valuing engineer feedback. "Let the grunts blow off some steam or they'll get disgruntled and leave."
micromacrofoot 4y ago
because sprints don’t allow the idle time that’s often needed to come up with such ideas. I could probably work for a year on “oh I’ve been meaning to look into that” tasks that have no clear outcome