It took me just shy of 48 years, but I finally ran my first half-marathon on February 7, 2016 (Super Bowl Sunday – Go Broncos). I had extra “Lifetime Bucks” from Lifetime Fitness that were about to expire, so I used them to buy a run plan. The coach sat me down, told me to pick a race as a goal, and suggested a 10k as a starting point. I’ve run that distance in under an hour several times, so I picked the half-marathon to really challenge me. I had never run more than 8 miles in a single session previously, but I wanted to learn more about endurance running.

I had plenty of time to think while pounding out 300+ miles on my run plan, and that gave me the idea: Agile Project Management is Like Running a Marathon! Consider these five comparisons:

1. Run training is like Agile transformation

Marathon: I would have never made it to the starting line – much less the finish line – without a proven run plan established by a certified run coach. The run plan told me exactly what distances to run and what days I should run. That meant my body got the appropriate rest periods while building endurance over time.

Agile: Organizations do not typically wake up and realize they became Agile overnight. At a minimum, key employees should pursue further education on agile principles. Organizations can ensure a higher rate of success by pursuing agile coaching through an actual agile business transformation. ProKarma has taken several clients through this transformation process from waterfall to agile.

2. Run clubs are like paired programming

Marathon: During my half-marathon training, I ran a couple times with run clubs. These generally have the advantages of (1) breaking up into similar run paces to stay together as a group through the entire run, and (2) having seasoned runners come alongside new runners to offer tips. It makes for a fun, productive experience with camaraderie as an added benefit.

Agile: One concept used on some agile projects is paired programming (also known as extreme programming or “XP”). This concept increases team coordination, rapidly matures junior developers as senior developers mentor them, and improves code quality because you have two sets of eyes looking at the developed code as it is written. And guess what…camaraderie can be an added benefit! I’ve seen this practice work on projects for software development, datawarehouse development, and data profiling exercises.

3. Run speed and cadence is like Agile sprints

Marathon: If you want to hit a target finish time, a lot of your marathon training focuses on maintaining a steady cadence and speed. In fact, to achieve the target time over the target distance, one program works on three weekly runs: (1) track repeats to learn how to run faster, (2) tempo runs to continue building distance at your target speed, and (3) long distance runs to keep building the endurance necessary to achieve the target distance. In addition to speed training, run mechanics are also important…and that includes stride length and cadence. If a runner takes strides that are too long, they may cause a heel strike that can lead to damage in the ankle/knee/hip joints and plantar fasciitis. Rather than take long strides, runners may need to learn how to run at a faster cadence to achieve their target times.

Agile: If a new runner went out and tried to run their target distance, like 13.1 or 26.2 miles, they would make it a few miles…and then limp home injured and frustrated. Many seasoned runners look to certain “milestone distances” on their runs to keep them motivated to complete the race. Agile sprints accomplish the same purpose. Rather than a waterfall approach that may focus on a single production release “way out in the future”, sprints allow teams to deliver solutions more frequently. This leads to a tighter feedback loop, to the ability to make agile adjustments between sprints, and to a better sense of accomplishment by the development team, executive sponsors, and end users. And just like a runner adjusts stride length and cadence, agile teams can change the length of the sprint to fit the environment. I’ve seen sprint durations vary from as long as 4-weeks for software or star-schema and ETL development to 1-week for data visualization development.

4. Running analytics like sprint analytics

Marathon: A lot more technology goes into sports nowadays! From the technology in the shoes and clothing, to chest straps and new wearable technology that measure heart rate and provide GPS, analytics drive sports. I use an Apple Watch to track my running distance, time, splits, calories, and heart rate to ensure I’m staying in the right training zone. I can then compare performance between workouts or trend performance over time. I’m a “BI guy”, so I love analytics…and how wearable tech makes IoT that much more fun and compelling! And I always want to beat my prior times while maintaining a lower average heart rate.

Simple Burndown Chart (described by Scrum Institute)

Agile: One of the most prevalent data visualizations on an agile project is the Sprint Burndown Chart. It measures the “velocity” of a Scrum team’s rate of progress by comparing the estimated vs actual burndown using story points as a basis. A second analytics example, especially during an organization’s agile transformation, is to do both cost comparisons and time-to-market/time-to-production comparisons between the prior waterfall approach and the new agile approach. There is also a Feature Value Analysis where you can judge the “value” of a user story to an organization by measuring the time interval between when it appeared on the product backlog…and when it was implemented into production. Higher value features will have a smaller time interval as organizations give them a higher development priority. Organizations can then compare that Feature Value to a “cost to delay” for a user story. For example, if a user story addresses a customer experience issue, and you are potentially losing customers because of a bad user experience, you can measure the costs of lost customers to the costs of re-prioritizing the user story in the product backlog.

5. Run pace discipline like “no heroes” concept in Agile

Marathon: I read all about it – and then I still got caught up in the adrenaline rush of running my first half-marathon. Rather than stay disciplined, I ran my first couple of miles much faster than my target splits. I was feeling great, my nagging injury wasn’t bugging me, and I was going to far exceed my expectations!! Well, just like every running blogger who made the same mistake lamented, I almost “bonked”. When I hit that 11th mile, it became a struggle to just get across that finish line. I lost my discipline, and I almost did not finish the race.

Agile: It is great when organizations have heroes. These are the top performers willing to make Herculean-efforts to get a production release across the finish line. They embody the work ethic we all want, and we should acknowledge their commitment. However, heroism is rarely sustainable if it entails long hours, personal sacrifices, and continued unrealistic delivery expectations. The Twelve Principles of Agile Software states: Agile processes promote sustainable development. Agile teams should focus on team collaboration, realistic estimates and client expectations, reduced/zero scope creep, and a consistent delivery cadence. Well-run agile projects will NOT rely on heroes to meet their delivery goals.

Training for the half-marathon did get my adrenaline flowing. I never thought I could run that distance, and the experience prompted me to consider both a full marathon and a triathlon (I already purchased a bike and took my first triathlon swim lesson). I’m also slated to run another half-marathon to simply improve upon my first performance.