A not-so-secret secret about me is that I’m a huge nerd. From my favorite classes in high school (AP Calculus and Latin), to my college choice, to my ratio of hours spent studying / hours spent drinking in college, to my lifelong tendency to have my nose in a book, this is hardly breaking news to anyone who knows me well.
These days, my nerdiness is manifesting itself in a growing interest in software development – not just the practice itself (I don’t know how to code …. yet), but in the process – how the inputs both from a technical and a business perspective affect the outcome, which in turn affects the success of the product and the business as well as the morale of the team and the company as a whole. It’s fascinating to me how it’s all tied together, and how difficult it is to get it right.
I currently work at an early stage healthcare technology company and am in the process of transitioning from a hybrid account/product management role (you do whatever’s necessary in the beginning, not just what your job is) to a full time product management role, as we’ve grown and matured enough to actually need a product manager (yay growth! Sometimes startups are scary …..). The question of how to manage this cycle properly is squarely in the middle of my thoughts day in and day out, and I’m fascinated by the science and psychology of it. As a company, we’ve chosen to follow agile development principles and use the (InVivoLink – interpreted) scrum methodology to dictate our development cycle.
So what the heck does all of this software development mumbo-jumbo have to do with running? About a week ago, I realized that I’ve started applying agile/scrum methodology to my training plans and running philosophy.
It’s a little different, but it’s working for me, and I love a good “tie it all back together” realization.
So, what are agile and scrum?
Agile is an idea that was defined in 2001 in the agile manifesto that describes 4 important values that drive the software development process for an agile team:
“Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.”
Scrum is defined as an iterative agile framework, with the focus on “a flexible, holistic product development strategy where a development team works as a unit to reach a common goal” as opposed to a “traditional, sequential approach.” (Source – “New New Product Development Game”. Harvard Business Review 86116:137–146, 1986. January 1, 1986. Retrieved March 12, 2013.” Is sourcing something relevant on a blog? Don’t want to get points off for incorrect structure 😉 Their philosophy was that the team works toward the broader goal in short, defined bursts (in our case, 2 weeks) and that at the end of each one of those bursts (sprints, ironically) you re-evaluate what’s been accomplished and plan for the next sprint. You always keep the sprints the same amount of time, and both the time spent reflecting on the last sprint and planning for the next sprint are incredibly important to the process.
I could go into all kinds of crazy detail about the ins and outs of the philosophy, the details of scrum and how we’ve adapted it to fit out team’s needs, but that would bore you to tears. What’s actually relevant here is how I’ve applied it to my half marathon training – and how that’s really working.
In terms of overall principles, the agile philosophy is remarkably reflective of how I’ve realized I need to train – I have a broad goal (for now – Country Music Half. Later this year – Chicago Marathon), and while I have a general plan to get there, I know it needs to be flexible (responding to change over following a plan) according to my schedule and how I feel (working software over comprehensive documentation). I’m using advice from running friends and blogs (individual interactions over processes and tools) and really trying to listen to what my body is telling me is good and bad (customer collaboration over contract negotiation).
Now, that doesn’t mean I’m not following a plan. That, after all, is why we use scrum – to bring some order and accountability to the process. Instead of a big, long, 18 week plan though, I’m planning in two-week spurts. Every other Sunday, I’m planning out the next two weeks. This works well, because I’m more likely to know what my schedule for two weeks will look like than two months (though honestly two weeks is stretching it, but that’s where the flexibility comes in – it’s not set in stone, it’s just more likely followed).
I write the plan in this cute journal I found on etsy – the plan is on the top line in black, then actual gets written in color below (and the day crossed out when it’s done) – shoe mileage and paces for different types of runs are in empty space at the bottom. I also log it electronically in mapmyrun so I can upload specific garmin stats and spit out all sorts of nerdy graphs that make me happy.
In case you’re wondering, we use a tool called Trello to manage a slightly more complicated process at work. It’s been (and still is) a work in progress, but if any fellow nerds are reading this and interested – here’s a great summary one of our all-star developers put together about the process of building a process at our company http://rileystrong.com/post/43378669576/how-invivolink-simplifies-software-development-using#_=_.
Lord have mercy, if anyone is still here – thanks for reading. Sincerely. This is mostly a gut check of how I’m thinking about things, and a personal commitment to stick to this “planning plan” that seems to be working for me. After all, though, gotta respond to change, so I’ll keep my loyal readers (all 5 of you …) posted on any changes to the methodology.







