Optimizing Marathon Training and Software Engineering by avoiding the Hobgoblins of consistency
by Allan Gross
About 65 years ago, Russian physiologist Leo Matveyev and Romanian sports scientist Tudor Bompa took the concept of adaptation to physical stimulus and created a successful prototype for training based on various cycles (macrocycle, mesocycle, and microcycle). As the marathon mania grew, many people successfully used this technique to go from “just finish a marathon” mode to advanced competitive running.
Similarly, in 2001, proponents of several “lightweight” software development paradigms came together to pen the Agile Manifesto. These founders created a framework that embraced the fundamentals of responding to change, delivering software frequently, and working closely with stakeholders. At the core of this was the “sprint”, another type of periodization, which allowed coders to react quickly to the new online business environment. It also fostered a more respected, collaborative technical and stakeholder community.
It struck me recently that there are many interesting similarities that have come from these revolutions. I certainly have benefited from the wisdom of both. I’ve gone from amateur runner to Boston Marathon qualifier, often racing for age group awards in smaller races. And I’ve managed very successful software development projects by embracing Agile (Extreme Programming) paradigms. Both have helped me “outrace my competition”.
However, I’ve also seen how a longer-term dependence on these practices tended to eventually lead to sub-optimal performance. As they say, “a foolish consistency is the hobgoblin of little minds”.
Weightlifters and other sports try to avoid this with a technique they call muscle confusion. While marathon training and Agile Software Development are certainly open to flexibility, it is easy to fall into ruts and let complacency derail progress. If you want to do better, it pays to consider changing things up. And the parallels are fascinating.
For example, in marathon training, we generally embrace periodization with a macrocycle training block (usually 12–24 weeks), broken into smaller mesocycles focusing on specifics like general endurance, lactate threshold, and VO2 max speed work. That order has become fairly well accepted. However, some have found great success flipping that around and doing speed work earlier in the macrocycle and going from a least specific to a more specific training regimen.
This can be taken to an extreme by focusing on a different goal altogether for one macrocycle — for example, training solely to set a personal best mile or 5k time. Doing this and returning to marathon training can provide a breakthrough training event for those who have plateaued with traditional schedules. Make it a challenge! No long runs for a few months won’t kill you!
In software development, I have seen similar success by embracing that sprint lengths are not sacrosanct. I feel like it is complacency on the part of the Scrum Master or team to settle on static sprint lengths. The wise practitioner aligns cycles to mission requirements, not the calendar. You can break them up in many ways focused on major engineering challenges. These can be in longer mesocycles and polishing this off with varied length micro-cycle sprints.
Sure, sprints of a month are convenient because they may align to a monthly status or metrics report. But what if that is too long? And sprints of two weeks are often enticing to management, that feels they are getting maximal return. But short sprints can create too much overhead. What if there is no need (or value) to this time frame? For example, you’re not looking for an advantage in business, and you get plenty of stakeholder feedback without doing rapid sprint releases.
My other experience is that short sprints create a subconscious mindset that avoids taking on the tough challenges, avoids necessary re-factoring, and can lead to burnout. It also leads to the avoidance of handling tasks in the proper order. It’s easier to knock off the quick fixes. Again, while the good Agilist knows they can break up tasks across sprints, is this always the most efficient practice?
In marathon training, I’ve seen similar bad habits creep in. Training programs have become so standardized that very few will question the wisdom of the traditional schedule layout. Training is generally broken down by weeks. How many people question the weekend “long-run” philosophy? The distance of the long run builds from the start of the program to the end (pre taper). But why should the mesocycle be a week? And why run long-only on the weekend? Sure, it’s convenient, but is it truly effective?
To improve this, some professional runners have adopted a nine-day schedule. This allows for key workouts to be scheduled with adequate rest, possibly every 3rd day. This can be done while increasing volume on recovery days. Instead of trying to cram three key workouts into a 7-day cycle, you optimize those workouts. You don’t go into a workout exhausted and do a sub-optimal job. This leads to a frustrating and ineffective pattern of undertraining — and then overtraining trying to make up for it. If you space workouts appropriately, not based on the calendar, you are able to work them sufficiently hard to create an effective stimulus.
Perhaps you think only professionals can do a long run during the week. But if you’re trying to optimize training, I bet you will find a way to find that extra hour or two. (Hint: Put down your phone — or stop binge-watching!) Are you aiming for success or just to check off the workouts on the generic training plan you printed off the Internet? That’s the question.
The same is true of metrics and the “points” associated with some Agile methods. They become more important than the bigger picture. Hence many Scrum Masters forget to build in time for experimentation or having multiple team members become familiar with different parts of the system. This type of change isn’t necessarily efficient at first, but it will pay dividends.
I think that the Scaled Agile Framework (SAFe) has embraced this lesson better. Since the SAFe folk are working to solve the issues of larger programs and distributed teams, they added in some practices that are often missed in vanilla Agile implementations. The SAFe Agile Release Train (ART) is much more open to Continuous Exploration (they promote/often force a continuous learning culture). They are also much more focused on Roadmaps and Milestones. This keeps them focused on the mission objectives rather than quick sprints that tend to get oriented toward the latest feature.
Without the discipline to do this and try new things we all tend to fall into repetitive patterns. We become workaholics or perfectionists, but with a narrow focus. We say we’ll try something new someday when all the work is done and there are no more stories in the backlog. We live for a day that never happens and we don’t understand why this fails.
Marathon runners have the same challenges when they become over-focused on their weekly mileage. Cross-training, stretching, weightlifting, and other supplemental techniques are just that — supplemental. They need to be considered as ways to improve performance, avoid injury and help remove limiters. They are not something you force into your regimen if you are injured as a replacement. They also can keep you mentally fresh and excited about your overall fitness.
Similarly, I have seen effective software development teams benefit greatly from dedicating at least one sprint a year solely for refactoring or documentation, or training. It actually makes these under-appreciated tasks seem like a nice break. Another good idea is using a complete sprint to change the roles of the developers. It is always tempting to assign tasks to those who know a tool or technology or a piece of code the best. Of course, this leads to a team with subject-matter experts who are single points of failure.
To conclude, periodization is great. In both marathon training and software development. But if your goals are more ambitious, or you have hit a wall — you may benefit greatly by trying to avoid some of the complacency and consistency trap doors that come with these techniques. If you step outside the accepted, and often monotonous, oversimplification that has become part of these new religions you may have a real breakthrough.
Embrace the true spirit of change and periodization. Take the time to examine if there are limiters that have infected your training or your processes. It’s a risk. But I think that you and your team will be glad you did. Your competition may not be as glad.
Especially when you are outsprinting the hobgoblins to the finish line.
Allan Gross has been involved in programs that have been involved in saving the government hundreds of millions of dollars through software reuse and acquisition recapitalization. He has also run a sub 3:05 marathon. He is not sure which was more difficult.
