Sprints, marathons and root canals

https://gojko.net/2018/08/30/sprints-marathons-root-canals.html

by adzicg • 8 years ago

34 12 8 years ago

mcgarnagle• 8 years ago

If your team isn't delivering on weekly sprints something is wrong. Perhaps you are over committing. If you are resorting to two week springs to forgo the useless double hour loss of the sprint plan / follow up demo, then sure, I get it.

In any of the two above cases it sounds like you have a weak team on your hands. When you push to treat the subject like a marathon it makes the business people nervous.

When you are on an incremental weekly delivery cycle, and things are late, it is usually only late by one or two of those weekly cycles. BUT, If things are late on a "marathon cycle" they are usually late by a "marathon length".

You sort of have to keep in mind that there's a rather large reason that there was a push by the business people to force faster cycles. You and your team are expensive. Weekly or bi-weekly goals show your accounting department that they are receiving assets.

maxxxxx3• 8 years ago

There are types of work where you may deliver nothing for months. I think the sprint idea mainly works for well understood tasks where there are no surprises. I often work on stuff where I can only report failure for weeks or months until it hopefully works.

magnusss2• 8 years ago

Can you please elaborate somewhat on the nature of these projects? I’d like to understand what it is about the work that makes it difficult to get interim results.

ianamartin2• 8 years ago

This is really what I was trying to get at below. The sprint model or even the marathon model just doesn't work for certain types of projects.

ianamartin2• 8 years ago

In my experience, I've never seen anything useful delivered in 1-week sprints. That pace generates a lot of activity and a lot of stuff that looks like work, but it's mostly just people planning stuff that can't be done in a week and having meetings about why it can't happen this week and most items being tossed out as blocked.

2-week sprints aren't a whole lot better. I could see maintenance and bug-fixing teams being workable at that pace, but new development projects I've seen have always been a total waste of time on that schedule. Yes, it does keep the business side of the company happy because they see a lot of activity and feel like real work must be happening. But the actual situation is that nothing is really happening--just very loudly and energetically.

alistairSH• 8 years ago

My company uses a mix of 2 and 3 week sprints (not on the same teams). My team uses 3 week. I mostly agree with you. Many of our tasks are done well within the 3-week period, but some take more time, and 3 weeks seems to be a happy middle ground. We could probably do 2 week sprints, but our “miss rate” would go up a bit. And at the end of the day, our clients can’t absorb changes that fast anyways.

erikstarck• 8 years ago

The hike is my favorite metaphor for sustainable product development: https://news.ycombinator.com/item?id=17880953

marsrover• 8 years ago

I’m going to read the article but first my two cents: you should refactor every story. Even if it’s just a small thing like moving a method to a new class. Even if it’s not related to the story but you just noticed it while navigating the code base.

Sprints, marathons and root canals

Related Stories