Avoiding Burnout, Creating Space For Downtime

The software development world never stops. There is no such thing as a finished product. Even without new features you are up against the moving targets of platform and package updates. Code that was once seen as secure gets a warning that there is a potential vulnerability. Then the business changes, new requirements, a relaunch, scale up of a platform.

Agile had a core value of people over process but the greedy nature of humanity uses some of the popular agile implementations to squeeze all of the performance out of a team.

How often is velocity used as a perpetual measurement to always go faster, do more, keep consistent. A sprint ends. the next sprint starts without taking a breath. The backlog is full of busy work and there is little celebration. The road just keeps on going before the plug is pulled or the same idea is re-imagined and we start again.

Not only is this cycle common in “Agile” places, but it also wears down everyone on a project. When we get to this place we often see full teams disband and at a huge cost of rebuilding. The language that is used when talking to people in this situation is fatigued and burnt out.

So how do we plan in time so we are not making busy work, fighting the fires and trying to deliver over the capacity of the team?

The need for down time#

Down time is under-rated and under-valued. It is not time of doing nothing. It is important space for thinking, designing, planning and recharging. For some people this is simply time to work on a side project, learn something and consolidate the understanding learnt during the delivery of the last feature/cycle. For others it is time to look ahead, make a strategic decision and design for changes. For some it is choosing to fix bugs and reduce technical debt. For others it is looking at the analytics, measuring the success of features and discovering the important points to improve on. The end of some downtime should be a coming together of all this reflection and thought to build something that matters next. So downtime is really a space to assess and regroup. The end of this time should leave the team empowered and motivated for the next iteration.

Maybe there is a better word for this as it is just focusing on all the other parts of the job that isn’t delivering a feature.

How would it work?#

Firstly the product needs an element of stability. You can’t be fire-fighting production at the same time as reflecting. As soon as you are consistently fire-fighting production then you have some more serious issues to focus on.

Secondly the value driven from this time needs to be understood by the business. They will be paying people to work on less structured, harder to define tasks. The overall value of this can be difficult to communicate.

Thirdly the rhythm of down-time needs a commitment. This could be 1 or 2 weeks after 2 sprints (if using scrum). It would also need a commitment for a number of iterations. The first time will not be as valuable as it takes people a few goes to really get to grips with it.

Structured Downtime#

Have a few threads of thought going through.

• Assess success of features
• Locate the main pain points (UX/user flow or technically)
• Attack tech issues/maintenance

For each thread have someone to facilitate the goal of downtime. Have specific areas to focus on and allow everyone to explore the options in creative ways, even build a prototype or a slide deck. However it works out. Combine disciplines with product/test and dev.

Have someone (the thread barer) over the entire time that brings all the threads together so the next 2 sprints are designed on the outcomes of this down time.

The benefits#

• Prevent chasing our tails with un-planned/last minute planned sprints
• Work of evidence and data
• Give time to the end phase of the product lifecycle where we look to see if our changes are affective
• Gives space for some innovation

But most importantly it is a regular space to take the foot of the gas and re-energise the team, have a re-focus on the product and work out the bits that will have the most positive impact on the product.