How I became an ultrarunner with the help of Scrum
Mixing business with “pleasure.”
Oh cool, you’re a runner! How fast can you run ten kilometers?
Ten kilometers seems an ideal distance to determine how physically fit someone is quick. When I tell people I’m an ultrarunner, most respond in disbelief, saying it’s impossible to run such distances.
But the cool thing is that it is possible. The human body is built for running. You don’t need to be an elite athlete, and training for an ultramarathon is surprisingly a lot like working with agile software development.
The agile runner
If you don’t know what an ultramarathon is, it’s a race that’s longer than the marathon distance (42,2 km/26.2 miles). If you’re not familiar with Scrum, it’s a framework for developing, delivering, and sustaining complex products.
If you don’t know how Scrum can help you to become an ultrarunner, I’m going to tell you a story about how I used this approach.
Crafting a vision
Just like a product needs to have a good vision, a future state to strive for, so did my plan for running an ultramarathon race. My vision was to break through my mental barriers about what it was possible for my body to endure and achieve.. The plan was to finish an ultra-marathon of ninety kilometers through the deep forests of Dalarna in Sweden.
Given I had limited experience running ultramarathons, I quickly realized I couldn’t do this by myself. So I contacted and hired a personal trainer with significant experience in the field of ultrarunning.
Forming the Scrum team
We quickly established working agreements, how we were going to interact, communicate, plan, set goals, inspect, and adapt. The Scrum team was shaped like this:
- I owned the vision, the desired future state of myself, the product. Therefore I represented the product owner.
- My body was going to bring my vision to life. Therefore my body represented the development team.
- My personal trainer, who was going to coach me, represented the Scrum master.
Together as a Scrum team, step by step, we were going to move close to reaching the vision.
The workout plan — our product backlog
The product backlog represented the work that needed to be done to bring the vision to life. The Scrum team met and started to break down the vision into epics. We identified the big things that represented the vision in a more graspable way:
- We needed to make sure that I could run for a very long time at a steady pace.
- Energy intake had to be practiced to make sure that I could replenish the energy loss that occurs during long-distance running.
- My muscles needed to be stronger to prevent injuries that can be caused by long-distance running.
- We needed to focus on making my mind sharp to cope with the mental pressure that comes with forcing your body to endure the pain that an ultramarathon involves.
- Recovery and active rest needed to be incorporated to make sure that I didn’t become overtrained.
By identifying the big essential things, we could start breaking down the epics to different workouts that we then would base our sprints on.
Sprint planning and backlog refinement
Training for an ultramarathon takes a long time. This is because you need to slowly adapt your body to the strains of long-distance running to prevent injuries.
The work on this product spanned between August 2016 and 2017. Each sprint consisted of four weeks and was shaped like this:
- Continuous backlog refinement when needed.
- Sprint planning at the beginning of each sprint.
- Daily Scrum every day.
- Sprint review at the end of each sprint.
- Sprint retrospective at the end of each sprint.
This structure helped us to make sure that we always worked on the most relevant things based on the latest feedback. We crafted sprint goals that helped us to plan the sprints and made sure our sprints and product increments took us closer to the vision. Adjustments to workouts that didn’t risk jeopardizing the sprint goal were made during sprints if needed.
Some goals were for example “Change from evening workouts to morning workouts” or “Run a total of 70 km per week this sprint”. Four weeks is a really long time for a sprint in Scrum. We chose this length because of the time it takes for muscles to build and for the body to adapt to different types of workouts.
Daily Scrum
Each morning, the development team synced the focus for the day’s workout. Bottlenecks and impediments such as a cold, lack of time, or aching muscles that could lead to injuries were discussed. We could let nothing jeopardize the Sprint Goal.
The feet could say things like “we’re quite sore today, it might not be possible to workout” or the brain could sometimes have trouble with the motivation for the project. The Scrum master’s job was to talk to the product owner and the development team about these issues. He helped with how we all could solve the problems together, making sure communication and collaboration were in focus.
Sprint review
At the end of each sprint, we inspected the work I had done and talked about the completed workouts. Based on that and any changes to the product backlog during the sprint, we talked about the next things that could be done to make me more prepared for the race to come.
The most important thing was that the product backlog was adjusted so that the workout plan was ready for the next sprint planning and new possibilities!
Sprint retrospective
After each sprint review and before the next sprint planning, we had a sprint retrospective. This session was where I got the most value for my money from my trainer, the Scrum Master. It was also, by far, the most critical meeting we ever had during our collaboration.
The Scrum Master ensured the meeting was both positive and productive. He encouraged me to improve making my training more effective and enjoyable for the next sprint. We inspected how the last sprint went with regards to how my body felt, how workouts went, how testing energy, food, and equipment went. By doing this, we could identify what had worked well and potential improvements to work with in the next sprint.
As time went, we could see how our improvements made me more durable and more reliable handling long-distance running. By reflecting on our progress, we started to see the vision coming to life, and it was super awesome to experience.
Product incrementation
From August 2016 to August 2017, the sprint goals were reached, the Scrum team had its ups and downs, but for each sprint, the product was incremented. Or rather, my brain and entire body became more and more prepared for the ultramarathon race.
The deadline came, and on August 19th at 5 am, the product was released. This basically meant that I ran for ninety kilometers, in the pouring rain, through the deep forests of Dalarna in Sweden for twelve and a half hours.
The Scrum team had performed admirably, incrementally making my body more durable for each sprint. With the help of an amazing Scrum master, the development team and the product owner brought the vision to life. I finished the race and fulfilled my vision. I broke my mental barriers and proved to myself that nothing is impossible if you put your heart and soul into it.
Don’t forget to challenge yourself
Each day at work, I learn new things about agile ways of working, frameworks, processes, tools, and teams. I’ve discovered that much of what I’ve learned can be applied outside of my work. Just like in this example, I used what I’ve learned from working with Scrum when coaching teams to develop software products and applied that knowledge to something completely different.
So don’t be afraid to embrace change and try out new things even if it seems impossible at first. Run 100 meters, run 250 kilometers, try Scrum to see if you can help your team, company, or organization to become awesome. Nothing is impossible, and it’s never too late to continuously improve!
