From Peloton to Programming: Adapting Power Zone Training Principles for Agile Development

In 2020, as COVID took over, we all paused for a moment to look at our health. I asked myself whether my body would be capable of surviving this disease that seemed to be spreading faster than anything we had ever seen. My answer to the question was that I wasn’t ready. My first instinct was to start a running routine, but it did not generate the results I wanted. I had heard a lot about the benefits of bike riding on the cardiovascular system – without the impact on the joints that running often has. I went out and bought a Peloton bike and jumped right into classes. 

During my first few classes, I found myself completely exhausted and defeated. Even the people doing the beginner classes seemed far beyond where I was athletically. I quickly began to worry if this approach was going to help me improve my health.   

One day, I happened upon some Power Zone classes. These classes required that I take a performance test before I began the program. To be effective, the Power Zone class required baseline data about what I could do. I took the test and then began a class that was tuned to my fitness and ability levels. I quickly found that, while these classes were challenging, the goals were achievable. I was able to do more targeted training that was based on my personal Power Zones, instead of on performance goals that were set generally for everyone taking the class. As I kept up with the classes and got better trained, I raised my output.

The Power Zone program asks you to retest every four-to-six months. I kept pushing a little more each time, raising the bar and achieving more within the 30-minute sessions. My baselines improved with each test. As they did, the test would move the incremental improvement goals out and keep the bar moving up. Even with the challenges, I discovered that improvement was not out of reach. The goals were appropriate, and I was training properly.

I share this story because it is a great analogy to how development teams manage complicated, challenging sprints without risking burnout.  ‍

What Technology Leaders Can Learn from Power Zone Training

Technology leaders can learn a lot from the Power Zone style of training as it applies to development processes. As an industry, the value of agile (or modified agile) development processes has shown to be superior to waterfall development processes. With an agile process, development teams have a targeted amount of output over a specific period. Team leaders constantly seek a sweet spot for output while materially increasing business value with each sprint. Each target is team-specific, based on many factors, including the talent and hardiness of the team.   

As I did more of the Power Zone classes, I realized that the concepts are similar, and I could use them to better predict and influence how well our team would perform during a given sprint.   

This table shows how the Power Zone training methodology applies to an agile development sprint – in particular, how to think about the impact of each zone on the team.  

A big development push puts a massive amount of pressure and work on a team. It’s critical to try to determine how much they can get done within a certain amount of time (e.g., a day, week, month, etc.) to balance what needs to happen to get results without losing code quality or distracting people from other regular business needs.

The farther people get into the Zones, the more training it takes to raise the output without risking burnout. At the start of any sprint, the development leader should ask the team how long they think it will take them to perform the assignment. The answer will help to assign a numeric value for how complex a project is. It also will help to gauge how much time the sprint will require (e.g., a 1-complexity project would take a day, whereas a 5 is more likely to take a week.)

Development team leaders play a crucial role in making sure that people can prioritize and succeed in each of these zones.

Discovering How Much Your Team Can Achieve

It’s impossible to know how much your team can achieve until you push them. By setting goals that the team members believe are in the 5-6 range will help see where the team may be. For example, if a leader believes that a developer can complete 30 points of work per sprint, setting a goal of 35-40 for a sprint may generate a perspective of the point estimation.  

Most developers will reach a limit in how much work they can get done in a sprint because the point system is an estimate of time, and there are only so many hours in a week. What we are constantly looking for is their ability to generate business value – which has the potential to have no theoretical upper limit. To increase the overall team points, a leader can always tack on additional developers. But to do that efficiently, we must first understand the limitations of our current team members.  

From a point perspective, we may get 30 + 30 = 60. But if we want to see our business value go from 30 + 30 = 200, we must ask whether we can change our processes, machines, tools, etc. to generate higher business value with the same limitations in points per developer. In other words, if we add pressure or raise the bar, does it improve how the team works and how they solve problems creatively? By pushing team members out of ‘steady state’ and out of their comfort zone, they learn to accomplish a process more creatively and efficiently. When that happens, the process delivers greater output to the end user.

It’s important to raise team members’ targeted output in a controlled environment with good training and development in place, rather than in an emergency or rush situation. Done properly, this process continually improves total team output and quality. As we layer in this thinking to groups within the team to get the collective output improved, the team works together to raise the bar for each one based on how they observe and support one another. Individuals lift one another up.  

In that way, we can return to the Peloton analogy. A solo rider absorbs all the stress of a hard ride because they are alone. But aware of their abilities and riding together with others, a rider can encourage and help someone else. They then train one another and mitigate the pressure of the challenge. Everyone involved changes for the better.

While this process is necessary for development teams, the concept applies to any team – and to its leaders. Setting achievable goals and training to reach a continually rising bar is a great way to think about the decisions we make and their impact on team members.