# What my personal trainer taught me about sustainable pace.

In both agile delivery and XP, we talk a lot (although still not as much as we should) about sustainable pace. Software delivery projects are prone to tight deadlines and developers are often found working long hours either due to work pressure or a culture of presenteeism or both. Burn-out in the developer community is worryingly common, not to mention the mistakes that are introduced when developers are tired and over-worked. On the flip side, developers are an expensive resource and it's important to use that investment effectively. Slow-moving deliveries easily result in disengagement or demotivation. Hitting the sweet spot in delivery pacing is important from both a business and human perspective. "Sustainable pace" seeks to address this by finding a pace that a team can keep up indefinitely.

# Stop racing

Scrum splits delivery into sprints, often two weeks long. But the name sprint is misleading, in that we shouldn't be asking teams to be hitting a pace which they can't sustain for longer periods. "It's a marathon, not a sprint" goes the quip - you don't run a marathon by starting out fast, you instead put effort into understanding what pace you should be aiming for and then hitting it consistently for the whole race.

But I'm still uneasy about the analogy of our careers as races of any sort. Watching the runners hobble over the finish line of the London Marathon, this is not how I want to hit retirement. And a race suggests competition, an option of finishing well but still losing.

Moreover, I'm increasingly of the opinion that sustainable pace doesn't have to mean steady pace - in fact, we should be actively avoiding having a steady pace.

# A bit of backstory...

I turn 40 next year, and am determined to hit that milestone with an acceptable base level of fitness. The combination of a full-time desk job, two pregnancies and general self-neglect has not been particularly kind on my body or my fitness.

Occasional stints of gym membership made minor improvements, but did not achieve the level of impact that I really needed - and invariably dropped off after time. I'm a firm believer in bringing in the experts when things aren't working, so at the end of last year I was both desperate enough and fortunate enough to employ a personal trainer.

I lucked out, and got a great personal trainer. With his expertise, my workouts are much more effective than they ever have been in the past and have had much more impact. Not only has he corrected technique, but he's tailored the workout to the things I really needed to work on, like my terrible posture from hunching over a desk.

However, one of the biggest thing's he's helped with is getting me to understand how to use pacing and recovery time in order to maximise growth. Guess what - simply working out as hard as possible for as long as possible isn't the best way to build fitness.

# The impact of recovery time.

One session we were doing squats with a kettlebell, and during the second set of reps he asked me how the weight was. Easy, I said, feeling slightly smug - it was the same weight as last week but I was finding it much easier this time round, and mentioned as much.

He lets me in on the secret - "It's just because I increased the recovery time between reps from 45 seconds to 60 seconds". For the third set and I was only given 30 seconds recovery time - the kettlebell suddenly felt twice as heavy and it was a struggle to finish the reps. Something as small as an extra 30 seconds was the difference between easy success and near failure.

Another example of this is how he varies the workout depending on how long it's been between trips to the gym. A longer break, and we go for a more intense workout.

# Focus on improvement and growth

My trips to the gym have much more in common with my job than a race does:

  • I need to hit a gym habit that is sustainable long-term. Like the delivery I'm working on, there's no "finish line" that I need to race towards.
  • I want to achieve improvement and growth in both my physical fitness and my career. In both physical fitness and technology, pushing yourself to your limits for short periods of time can be a really rapid way to get results, but in those cases recovery time is an essential part of the process.
  • My gym schedule - like my job - is subject to the same interruptions, disruptions and fluctuations of normal life; holidays, illness, competing priorities. I need to be able to dial back my gym sessions when life gets in the way, just as I might need to dial back my work focus. Similarly, I actually enjoy being able to put a bit of extra effort in at times in order to see more rapid progress, or to get through a blocker that's been holding me back.

# How has that impacted my teams?

I've found the concept of recovery time a really helpful one in pacing the team and achieving real sustainable pace without just aiming for steady pace. Here's my thoughts on how that's worked:

# Make sure the basics are in place first.

The first rule is, always work within your own personal limits. Muscle or ligament damage in the gym is really going to be counter-productive to what you want to achieve; so is burn-out or dangerous bugs and errors introduced by tired, over-worked developers. When you're looking at a team, each team member is going to have their own personal limits and constraints, so blanket rules are difficult. "Don't work out of hours" didn't work for me for example, because my family commitments sometimes meant that it was better for me to go home a bit earlier, get the kids and then finish things up once they were settled.

Instead, I focused on creating an environment where everyone was encouraged to get proper downtime and ensuring that the team had real impact to influence the scope and deadlines of the work they were taking on without undue pressure to have to get it done. Failure to meet commitments were not punished or berated but taken as a learning opportunity, and incremental value delivery helped create visible progress to aid constructive scope/prioritisation conversations rather than pressure to do it all. Also: lunch breaks - they are important, make sure you take one! (confession - this is probably the most hypocritical thing it's possible for me to say). This is sustainable pace 101.

# Think about pacing over a longer period

As well as thinking about sprint-by-sprint objectives, the team had a strong focus on bigger milestones and stage-gates in the product evolution; usually these would incorporate a range of functional and non-functional objectives. Each milestone incorporated a range of objectives across functional, infrastructure and architectural concerns and represented an overarching business delivery proposition (while each individual part also delivering independent value). These pieces stretch over anything between 8 and 16 weeks. This is great for motivation and engagement, as the feeling of meaningful progress over time can easily get lost in the week-by-week mini victories that scrum ceremonies provide (particularly if you're running one-week sprints).

After our first big delivery, I built in two weeks downtime for the team. It was a chance for us to take some time to work on the things that interested us or we felt we wanted to add a little more polish to, while also working shorter days and taking longer lunch breaks. A big part of it was to maintain engagement and motivation after a stretch of hard work and from that perspective it was a bit of a disaster. People ended up demotivated after the end of it, the feeling of wasted time and directionless work left the team struggling to feel pride in their achievement. After this, we ran milestone deliveries back-to-back.

My personal trainer advocated for "active recovery" between gym sessions where we really pushed it. Don't just slob out on the sofa eating ice cream and playing video games, but instead focus on lower-impact and simpler exercises. Active recovery isn't just about making your body work less hard, but your brain as well; focus and determination are limited mental resources that need to be managed too. Complicated or whole-body exercises are more mentally draining as well as physically draining so my active recovery involved reverting to some of the simpler things we'd been working on a few weeks previously. So I started to think about what "active recovery" might look like for the team after they'd been through a stretch of demanding or challenging work.

Across each period, we had a natural flurry of excitement and enthusiasm in the first couple of weeks and I knew there would be a bit of a dash to finish off towards the end of the period. It was important to let the team have a natural dip in pace at around 3-4 weeks in (keeping in mind that milestones run back-to-back, so the first few weeks are straight after the previous delivery).

Scrum can make this difficult - dropping below your "average" velocity can feel like failure even if the mathematics suggests you have to end up there not infrequently! But to worry about it can be counter-productive - examining low velocity in retros is just another way for teams to put themselves and others under pressure to work harder even if the stakeholders aren't worried, and can easily lead to cycles of demotivation.

For my team, this meant sequencing the work so that the team had a chance to work on areas which were less technically or intellectually challenging, but also less emotionally pressured too. Making decisions about architecture, for example, requires some pretty energetic thought and debate - but also is emotionally draining as the individuals have to choose an option and commit to it, even though they know they don't have all the answers. It's a perfect piece to pick up early on, when enthusiasm is high and people are excited about getting stuck into something new. After a few weeks, lull or dip in the middle of the wider delivery is a perfect time to pick up technical debt tickets, put a bit of polish on the areas of test automation that have started to atrophy, and fix up those things that have been niggling for a few weeks but have never quite been urgent enough to get done. The feelings of delivering value are still there, but they're easier and feel less critical. There was a knock-on benefit of really helping quality stay high and contributed to some of the things we did to guard against the common agile anti-pattern of never focusing on technical debt - but that's another blog post.

# In Summary

Having stretches of particularly demanding work doesn't have to be a bad thing, and in fact for many people this is essential for their motivation and own professional growth. However, in these cases it's essential to be mindful of what sustainable pace means over a longer time frame.