This spring I had weeks where I was in complete overdrive mode. The attention I needed to give to work and personal life peaked simultaneously, and I was all in all pretty much constantly stressed out. This was not sustainable in the long term. Fortunately I managed to deal with the issues and cut down on work load and after a while things settled down. But I still wanted to take something useful out of the experience, and I’ll talk about it here!
Within Extreme Programming, Sustainable Pace is an important practice.
It’s a principle arguing that when developing software, having a consistent workload in each iteration increases measurability, predictability as well as code quality and employee well being. I find this principle to grow more and more worthy of recognition, and not solely out of a software perpsective.
For me, “sustainable pace” can be applied in a broader sense. So let’s first look at how it applies to one of my hobbies: jogging! I think anyone knows that if you sprint, you can’t go very far before you need to stop and catch your breath. Whereas if you jog along in a pace suited to your condition, you can run quite far! Sprinting increases the risk of injury and makes you unfit to handle surprises. Let’s say you’re running in a 10km race, and you believe that you have only 500m left, so you start sprinting. After a while you reach a sign post, indicating that you’ve got 2km left! Since you’ve pushed your body into running near its maximum capacity, how are you going to cope with the extra 20% of track to cover? Another point regarding jogging as a means of keeping fit, is that if you push yourself to your limit in a run, you might simply not enjoy it that much. Maybe you won’t notice the beautiful sights, the good weather or the nice, fresh air, that you would have done if you kept your pace. Thus, at the next scheduled time for a jog, you might decide not to run at all because your previous experience was just too rough.
To complete the jogging analogy we need to include the quality aspect somehow… is it there? Well, as Pheidippides should know, you can run far quickly and and make it in time
to your preset goal, but it always comes at a cost. For the ancient Greek runner who, according to myth, completed a Marathon distance to deliver news of the Greek victory over Persia, it meant his death.
I believe that you can also draw parallels to our daily life. If you’ve managed to fully pack your schedule of working overtime six days a week while taking an evening Spanish course and going to the gym four times a week trying to lose weight, you might just make it. But any unforseen event is much more likely to cause big trouble for your scheme than with a less dense plan, and such an event may actually cause all of your activities to suffer. Had you had more unscheduled time available, that could have been used for crisis management, you could possibly have continued with most of your planned tasks. When looking at it like this, I find that the value of allowing enough slack in your schedule is fairly obvious, and I think most people would agree. Yet very often we overestimate our capabilities and try to achieve too much.
Sustainable pace does not apply only to jogging, obviously, but practically to all practices where there is some finite resource involved (such as stamina, time or money); it is about managing the resource and making sure that supply matches consumption and that there is enough in reserve to handle extremes.
Let’s now focus on software development and why this topic is so important there. Unfortunately many projects are running way too fast for their own good. This includes many Scrum teams that take the ‘Sprint’ concept in the wrong way; they literally sprint, blind folded, during the whole iteration and usually end up crashing into the Sprint Demo Wall at the end! Near deadlines, many teams crunch hours and management demands overtime. Corners are cut, and features dropped. When you’re sprinting in software development, you’re not only risking burning out your core resource: the developers; you are also creating a greater and greater need for a ‘recovery’ period, when the team and code can settle. This recovery period would typically be the time when the built up technical debt is dealt with. However if the team is not allowed such recovery, the time needed for recovery will increase. Further risks that are induced on the project include the incapability to handle unplanned events. If the team is already running at maximum speed, how will you manage a crashed build server or several team members falling ill?
You may wonder how one determines that one’s running at an optimal pace. It’s easy to imagine situations where you are running much too slow, or where you have an abundance of slack. This would cause your competitors not only to overtake you, but to stay ahead of you! Hm, what about setting out at a reasonable pace and adjust your pace as you go? After a couple of complete races, sprints or releases, you’d probably have adjusted your pace several times and be very near optimal pace. E.g. you noticed that during the last Scrum Sprint, the team was feeling quite some pressure to finish the last tasks in time, and there was a test server that crashed that no one had time to fix. So when planning the next Sprint the team’d make sure to commit to less work.
As a summary I argue that for any activity, by keeping a pace where there are margins, you’re more likely to:
- increase the quality of the activity,
- increase the length of time that the activity can be performed,
- increase the predictability of the activity being performed (on time and in time),
- increase the capability to handle extreme situations that directly, or indirectly affects the activity,
- increase participant satisfaction in the activity.
Now it’s time for all of us, I hope, to go and spoil ourselves with a Christmas spent doing things at an unsustainably low pace with an unsustainable intake of fat and liquids!
Merry Christmas and see you all in the Happy New Sustainable 2014!