June 3, 2022

The paradox of Sprinting at a Sustainable Pace

Building a product sometimes feels like an endless race, head down, pedal to the metal, let's build it! We all run after something and as a team incrementing our product to be the best possible set of functionalities our users ever wanted, at some point we get out of breath Sprinting. As Scrum Master and Coach I often have to remind people that our goal is not to run but build a pace we can be confortable with for a long period of time, a sustainable pace.

Definition of Sprint

To run as fast as you can over a short distance, either in a race or because you are in a great hurry to get somewhere

Cambridge Dictionary

What could go wrong "running" as fast as we can? A lot! From this dictionary definition what could we keep? Probably only the short distance. The only race we want to win is the one on quality, usability and all attributes that define a great product.

Being heads down to wrap a Product Backlog Item is sometimes a good thing as it create a bond between team members, a little adrenalin for the team, and then we get the satisfaction of delivering something together. Only sometimes. If it happens every iteration, it is an issue you need to inspect together.

Could we choose another term instead of Sprint? Marathon is not sounding better as the story tells that it didn't end well for the messenger after running for more than 40 kilometers.

To be clear, building pace is the key take away, it is an endurance race. As long as we want to develop our product we should be able to sustain our pace indefinitely. And I'm not saying running is bad, not the point. But continuously inspecting our rhythm to preserve our capacity to increment our product without neglecting quality and exhaust our people is essential. So yes, we Sprint but the "race" is not won by being the fastest.

Why building a sustainable pace

A lot of benefits can be extracted from a pace we can sustain for a long period. First, as said before, you don't burn yourselves out and we all know those days that this is important. Keeping people motivated is a key factor to be successful as a team and if you are in a rush every day, people will leave. High performance teams don't have a high turnover and I don't believe these teams to be working 16 hours a day to be the best.

You become more predictable, it helps to better forecast and plan. You know your capacity better, it is less stressful and if you need to maintain a plan, it is easier. Reaching your goals regularly is great for you and your stakeholders.

You now have the time to inspect, adapt, continuously improve. So many teams don't consider continuous improvement as the key element of a sprint, it then becomes a march to death with the only goal of delivering without meaning. Improving your practices, ways of working, expand your knowledge will make your team better and so your product.

How to reach it?

If you are forming a team. Start small, inspect, experiment and closely monitor the "smells" of an unsustainable pace such as: overtime, bad quality delivered, goals missed regularly, stressed people, you don't have the time to prepare for the next sprints, constantly in a rush.... The good news for you is that forming a team takes time and finding the ideal pace together is part of the process.

Your team has quite a few sprints done, no worries here, you can still find it. Spot the difficulties listed above to see if your team has not found its pace. If you are in a corner, you can have few ways of addressing the issue. My best advice would be to reduce drastically the number of items to plan for your next sprint, reach your goal, then increase slowly your engagement the following sprints while making sure you have room to deliver the highest quality and have room to take actions for continuous improvement. Once you start compromising continuous improvement, quality and fail reaching your sprint goal, go back. You could also slowly decrease your engagement until you find it, but it may be disappointing for the team to not reach their goal yet , while your stakeholders get less.

Should you stop sprinting? In my opinion, don't. If you can't sprint anymore, what is the point? Maintain your sprint and your events but move your focus. Nothing stops you from spending more time in retrospective, more time in refinement, take more continuous improvement actions for a sprint. If your stakeholders can't support you, maybe it is time to discuss.