Jade Meskill, Derek Neighbors, Chris Coneybeer and Roy van de Water discuss an article by Todd Landry titled “What is the Right Iteration Length”

• Is it better to have a shorter iteration and close the feedback loop
• Is it better to have a longer iteration to decrease the overhead of the Scrum Ceremonies?
• Sprint Review seems to be the only ceremony not proportionally decreased with sprint length
• Retrospectives do not have to occur every week, or perhaps have an extended retro every other sprint
• The cost of deploying is sometimes an argument for longer sprints
• Deployments and releases should be unhinged from sprints
• The team agrees that shorter sprints are generally better

Transcript

Jade Meskill:  Hi. Welcome to another episode of the Scrumcast. I’m Jade Meskill.

Roy van de Water:  I’m Roy van de Water.

Chris Conagher:  I’m Chris Conagher.

Derek Neighbors:  I’m Derek Neighbors.

Chris:  I was reading an article this morning by Todd Landry, called “What is the right duration length?” He was bringing up some experiences that he had in trying to discover what the correct duration length is. He says that when they first started forming an agile team, they were new to the concept. They figured they’d do one week iterations. They’d have a really quick feedback loop and be able to adjust as quickly as possible.

He says they did that for a little bit. They felt that the overhead of all of the scrum ceremonies for one iteration, got out of hand, so they increased it to two week iterations. He felt that that worked a lot better for him. He says around the holidays they started an iteration where they said, “Well, we can’t really do a real iteration, so we’re going to start now, and we’re going to end when the last person leaves the building.”

It ended up being about a four week iteration, and he says that that was a complete nightmare.

Roy:  Yeah, it sounds that way. I was about to unleash on that one, but…

[laughter]

Roy:  At Integrum we have done a lot of one‑week sprints, and you guys have all been a part of those one‑week sprints. What do you think, what was the positives from doing one‑week sprint?

Chris:  I think some of the positives were that the ceremonies were very targeted. We had to learn how to keep them under control. I think that’s something the teams go through is that they don’t do a good job of making sure they keep those ceremonies under control, and that’s why they get so much overhead from them.

Derek:  Yeah, I tend to agree. The number one thing that I hear from people is that the overhead on one week sprints is too high. The only ceremony that I believe has that amount of overhead is, really, the sprint review including the retrospective. The main reason that I say that is planning should be a rough estimate of a percentage of time in your sprint.

If you’re doing a four‑week sprint, you might spend an entire day. If you’re doing a two‑week sprint, you might spend a half‑day. If you’re doing a one‑week sprint, maybe you’re doing two hours. I think that what happens is a lot of teams doing one‑week sprint spend a whole day planning, and that’s where they feel the overhead is. I think they’re just being inefficient in how they plan. I, actually, think it’s poor planning that hurts one‑week sprints, not that there’s too much overhead.

We’ve played with this on and off. On the retrospective side of the fence, say, we’ll only do the retrospective every other week, or do a light version of the retrospective, where we at least catalog real quickly some high level frustrations, but don’t dig too deep. Then, on the opposite week, dig a little bit deeper, and spend a little bit more time during that.

From a demo perspective, which is really the other element of it, you should be demoing your work pretty much as you complete it. You shouldn’t be building up a whole lot of sprint demo time to begin with, so…

Roy:  I think there’s a lot of teams that don’t follow that particular piece of advice, where they’re demoing constantly.

Jade:  But even if they’re not demoing constantly, if they are only demoing one week’s worth of stuff, then their demo shouldn’t take the same length of time.

Derek:  I think another thing that kills people too is there’s this really bad stigmatism that you have to deploy when you have an end of a sprint. A lot of teams, deploying is very painful, and so that eats up a lot of time. It’s actually getting things deployed so that they can actually demo. It’s why I find, when there’s a poor build environment that, generally speaking, teams are less likely to want to do one week sprints, because the deployment for demoing takes up half a sprint.

Roy:  I always tell people that they need to unhinge deployment and releases from their sprints.

Jade:  However, I kind of feel like, if you’re doing the deployment every two sprints, then that kind of builds up a cadence. It does almost feel like it would make sense to…

Roy:  I think it’s nice, and it’s good if you can get there. But I don’t think they should be solely dependent on each other.

Jade:  I think in an ideal situation, you’re deploying as often as you’re demoing, which is daily, and you don’t have to worry about it.

Roy:  I think that’s a pretty highly evolved product or organization that can live in that continuous deployment world.

Derek:  I guess where I get really concerned is, I’m even OK, as much as I might bag on it, on a 30 day sprint, or a four week sprint, as long as a team understands that that’s a segment of where they’re at, not where they should be going.

I get concerned when somebody starts with a one week sprint and then pulls back to a two week sprint, and says, “For us, just a two week sprint works better.” Because what they’re really not acknowledging is all the problems that are keeping them from being able to do a one week sprint. I see teams do one week sprints all the time, really, really effectively, which means it’s doable.

If it’s not doable for your team, there’s probably other symptoms that are happening. Either you’ve got poor deployment practices. You have bad product ownership. You have poor planning meetings. A myriad of different things can be coming up that are preventing it from it.

Sometimes when people kind of roll back to this less‑than‑ideal state, if they don’t do it with a, “We’re only doing this for right now until we can get better at the other things,” then I think that that’s dangerous.

Jade:  I think that there’s some huge downsides, too, to doing one‑week sprints. I’m sorry. Downsides to not doing a one‑week sprint, specifically when it comes to regards to research tasks. If I’m doing commitment during planning and during my planning meeting, I find out that I don’t have enough information and I need to write research tasks.

If have a one‑week sprint, then it’s relatively low‑cost. I spend one‑week doing the research. In the following week, I can immediately do that task. If I have a four‑week sprint, that means I do the research task. That even means it’s four weeks until I do the research task. Then I don’t commit to getting it done until four weeks after that.

It’s going to be eight‑weeks until that story gets done. Or I do the research task immediately, but then it would be four weeks before I, actually, address the story. Then it’s four‑weeks between research tasks.

Derek:  But, if it takes you nine weeks to deploy, that’s all OK.

[laughter]

Chris:  Something that we’re talking about is that some of these teams that we hear when they’re doing one‑week and then they go to two‑week, how many times do we hear it’s right in the very beginning? You’re talking about retrospecting, realizing, “What do we need to change,” where they’re getting used to this, so it’s probably talking them longer than it would.

Are they really retrospecting, going, “Are we getting better at this? Can we stay at one week?” I have some questions in regards of what did the team think of and why did they go to two weeks?

Derek:  Too much overhead.

Roy:  I think it’s reduces that pressure like Derek’s saying. Doing a one‑week sprint requires a lot of discipline, and a lot of willingness to introspect and really pay attention to yourself. When you see people getting really uncomfortable with that, it’s because they’re trying to get a little bit more of a buffer to feel a little bit safer.

I think that’s OK in the early adoption phase. But like Derek said, if you just get stuck in that rut because, “Well, that’s just what we do,” I think that’s a bad place to be. You should really be trying to challenge yourself, but I think that’s reserved for teams that are a little bit more mature.

Jade:  With longer sprint‑sizes, you’re increasing the risk in a self‑organizing team. Because when a self‑organizing team comes up into retrospect, and comes up with an idea and they try it, in a one‑week sprint, they can cancel out that new thing to try within one week. But if you have a four‑week sprint, you’re stuck with that for four weeks. That can be devastating to the company.

Roy:  You could also do retrospectives disconnected from your sprint.

Chris:  That’s true.

Derek:  I think, as an industry, most people are doing two‑week sprints. I don’t know many people that are really on a 30‑day or four‑week cycle, but one thing I’ll say that I noticed with almost every team I encounter. The teams that like two weeks sprints only can pull in two or three stories, generally, per sprint. When they task out to do their commitments, it’s usually in terms of days.

I don’t mean ideal days. I mean, “Well, I’m going to work on this task today. Tomorrow, I’m going to work on that task.” When I see teams that are OK with one week sprints, and actually prefer one week sprints, I usually seeing them pulling in three or four stories, at least per sprint. They’re pulling in tasks down to a 15 minute, nothing bigger than hour or two.

I think that that gives them a lot more fine grain control over, are they ahead or behind schedule. It really helps to pick up pace. That’s not to say that people doing one‑week sprints complete more stories. That’s not the goal of bringing in more stories.

But, they have a habit of decomposing things to a smaller level which gets them a better accuracy from a standpoint of when something’s going wrong, they know that’s it’s going wrong a lot sooner. It’s not because they’re in a one week sprint. It’s because they’re not having to wait until the end of the day to figure out, “Oh, I’m kind of behind schedule.” They know that by lunchtime of the first day.

“I’m an hour behind. Or the team’s three hours behind.” It allows kind of those course corrections to happen within an hour of a sprint opposed at the end of a week, or at the end of two weeks.

Jade:  I think that we all agree that it seems like the shorter the sprint length or, at least in our case, we feel that a one‑week sprint provides the greatest ability to react to change to minimize the risk and offers a lot more advantages. Oftentimes, a desire to go for longer term sprints are a result of other pains on the team. Or other malfunctions within the team that cause them to shy away from that.

Roy:  I think you need to take the rest of the organization into account as well. I see a lot of challenges, sometimes, for development teams that are willing, and able, to go to one week sprints, but there’s some impediment at the organizational level that’s preventing them from doing that. I think…

Jade:  Product Managers.

Roy:  [laughs] . I wasn’t going to name names, but I think that does factor into that as well. It’s important for teams to be cognizant of that. Also, I think, try to work towards solving that. What’s wrong, or what’s happening inside the organization that’s preventing the other part of the team, the product donor, from being as responsive as the development team.

Derek:  It’s not just product donors, design too.

Roy:  That’s a whole other Podcast.

[laughter]

Jade:  I think that’s it. Thank you for joining us.

Chris:  See you next time.

[music]

Mark Graban:  Hi, this is Mark Graban, from leanblog.org. I am looking forward to being a future guest, on Scrumcast. You can also listen to my Podcast, if you go to leanpodcast.org. I cover “lean” from a pretty broad perspective, including manufacturing, healthcare, startups, and software. You can listen to Podcasts that I’ve done with Eric Ries, with Brant Cooper, and Patrick Vlaskovits, on customer development.

You can find all of these on iTunes, if you search for leanblog, or go to leanpodcast.org.