Holey shoes and jam-packed schedules

I bought new running shoes yesterday and went for a run today. I'm either inspired or deranged, you decide for yourself.

What do running shoes have to do with software development? More than you think, actually. I can make parallels between running and deploying software — but that's for another blog post. Today I'm going to talk about holes.

My new running shoes are a pair of On Cloudsurfer 7 (On only lists Cloudsurfer 2 and Cloudsurfer Next on their site, both of which seem to be newer models than my 7's, so I guess whoever is in charge of their version numbering came from Microsoft). The main differentiator for these shoes is that their soles have holes in them. When walking in them, you get a distinct bounciness to your step. When running, this means each landing is cushioned, reducing the harshness of the foot impacting the ground as well as providing some energy recovery since they bounce back — in theory at least. I'm not a good enough runner to determine if they actually recover energy, but I can say that these are probably the most comfortable running shoes I've owned. Good stuff.

Now, over to Software development.

When I was at Sony Mobile, I was part of the backend team for an application. We also had a web team and an (Android) app team. All teams were following Scrum and doing 2-week sprints.

This meant that every 2 weeks we would sit down together and plan all the work that should be done in the next 2 weeks. Planning poker, velocity charts, a scrum master, all of the things you associate with Scrum.

This worked well for both the web team and the app team. But for us in the backend team it didn't really work that well. We had a lot of unplanned work come our way: bugs related to backend data-processing, unforeseen requirements from the app team, and spur-of-the-moment adjustments from the product manager that had to be implemented now.

We almost never finished everything we planned in our sprints. Not a disaster since we kept moving forward and, most importantly, provided the solutions the client teams needed from us. But it still never felt right to leave work that we had commited to for the next sprint — even if everyone agreed that was the right thing to do given that what we did instead was more important.

So we ended up making holes in the planning. This is a long time ago, but I think we started with only planning 80% and ended up around 50%, leaving the rest for unplanned work. And if we ever finished everything we could always pull in extra stuff from the backlog.

Do you see where I'm going with this now? What do my new running shoes have to do with software development? Holes. Holes make both running shoes and software development better.

In shoes, it means recovered energy and less stress on your knees. In software development it means more room for unplanned work, less stress on the developers, and allows tasks to take the time they should instead of rushing them, which in turn allows creativity to flourish. I have also heard at least two people say that it improves predictability too.

You could argue that we sucked at both planning and quality control, and you might have a point. We could definitely have been better at both of those, but I'm still sold on holes in both shoes and planning.