Running software projects as marathons

As a runner of distance events, I get quite a lot of time to ponder and after reading this interesting blog post from Mark Ridley, on what technology can learn from sports, it got me thinking about running and software.

It's not uncommon to hear people refer to projects as marathons and this is typically in relation to the gruelling nature of the event itself and while I understand this, I think there are actually more parallels to be drawn from the training required to complete the marathon distance.

Now, let's start with some important differences between a software development project and a marathon. I often hear people say they could never run a marathon. I rarely hear people say that they couldn't complete a project. Also, software development is rarely an individual pursuit, whereas a running and training for a marathon is often a solitary affair. But that's enough about the differences, bear with me and let me explain where the similarities lie.

My current training plan for the Chicago Marathon is about 16 weeks (4 months) which is certainly inline with many software projects I've been involved with. And if you think of your product as your race fitness, then you define your race up front and then construct a plan to build to that level and then "release" your product on race day. Your plan will be dictated to by how much time you can dedicate to it in much the same way that a software project will be constrained by how much resource you can commit. And also, chances are you will be building your software incrementally which fits with training plans which are typically constructed into weekly chunks with each block building your fitness further. Still, with me? Great. So if we can all agree that projects are marathon training plans, then what methodology are they using? Are they agile? Well on the face of it, training plans could be considered very waterfall. A big design up front and an immovable release date. I know I've written out my entire 16 week training plan weeks before starting and so I know exactly what training session i'll be doing on the Tuesday in week 8. You'll be “shipping” on race day, with whatever “product” you have built during the training plan.

However, it's worth mentioning that the goal can be flexible depending on your progress throughout the plan. So, although you wanted your product to be a 4 hour marathon, injury may mean you have to ship a 4:30 marathon. This is a really important point with software projects in that the value of shipping is often underestimated. Projects can run over and late as teams try to polish and cram in extra features/bug fixes but in reality, more value would typically be generated by having a slightly less feature rich product out in the market. In saying that, psychologically, shipping a product which is less than what was hoped for is tough to accept. When I ran my first marathon, I had set out with an A, B and C goals (3.30, 3.45 and 4.00) with my C goal essentially being my MVP. I found it difficult to adjust my expectations from a 3.30 to a 4 hour marathon despite the stark reality that a 3;30 was just not possible given the time and resources available to me. So, in the interests of stretching the analogy further, what other similarities are there to be drawn with software projects. When it comes to testing, some of the better training plans have frequent tests scheduled in. These come in the form of races to gauge your fitness at regular intervals across the plan which will provide feedback as to whether you need to adjust your plan. The weekly training blocks are just like an iteration or sprint. At the end of your sprint, you should have completed the training runs which you have committed to. A definition of done? How does, all training runs completed and you are not "broken" i.e. injury free and able to start the next training block.

While the analogy isn't bomb proof, as someone who spends a significant amount of my time training for marathons or working with software development projects, I can certainly appreciate the similarities between them. One of the big differences I guess is that as an amateur runner, I'm pretty much my own stakeholder, my own product owner and my own developer of my "product" and so I can be in control of what training plan and how much I do in any given week. Still, I choose to try and stick to the commitment and deliver the best product (race time) I can which opens up a whole conversation about what motivates us. But that's for another day.