The Iteration is Too Long

I've been meeting teams who complain to me the iteration is too long. "But, JR," they say, "we can't get anything done in four weeks. We have to move to six week iterations. We can't possibly commit to anything in four weeks. We need at least six weeks to finish anything."

They sit there, with their sincere faces. They look at me, expecting me to go along with them. I take a deep breath, and say, in my most sympathetic and sincere voice, "Oh boy. This is really hard. Ok, you've convinced me. The iteration is now two weeks long."

At first, they turn to each other congratulating each other that they've pulled something over on me. Then they turn back to me, and look at me like I've grown at least one more head. Or maybe that my head is turned around backwards. Inevitably, the tallest man stands up and tried to intimidate me physically. He doesn't realize that my stature is the smallest part of me, that I've been shorter than everyone else for so long that his attempt at intimidation is pitiful to me.

"Johanna, what do you mean, two weeks. Did you not hear us?"

"I heard you just fine. Do you really want to wait six weeks to discover why you can't release anything in six weeks either?'

That usually stops them in their tracks. "What do you mean?"

"If you don't think you can finish anything in four weeks, the chances are quite good you can't finish anything in six weeks either. If we make your iterations two weeks, you have to reduce the size of the work you take into your iterations. You will be more able to estimate the work. You will have less to test. You will have less opportunity to create technical debt. You have a shot at releasing what you created.

"But if you expand the timebox to six weeks, you won't get the feedback you need. You will never understand why you can't do anything in four weeks. You will never learn why you can't finish anything in four weeks. You will have a self-fullfilling prophecy: your four-week iteration will be too long."

At this point, they generally want to go back to a four-week iteration, because it looks better than a two-week iteration. But no, a four-week iteration is an excuse to do a waterfall iteration: one week of design, one to two weeks of development, one week of testing (which will get crunched into less than a week because the development will expand) and then quick, end the iteration. Some smart person will want a Gantt chart of the iteration, and another smart person will want a test plan. Their self-inflicted overhead will kill their agile efforts.

Now, maybe your agile pilot did succeed with four-week iterations. Good for you! But I'm meeting more and more teams whose pilots are not succeeding. They don't change what they are doing--they fit their silo'd teams into a four-week timebox and call it agile. They certainly get some value from the timebox. But they are not living the agile values and they are not transitioning to agile.

When you make the iterations shorter than you can imagine, you force yourself to change your practices. You force the team to consider continuous integration. You force the team to integrate the testers with the developers. You force the team to limit the number of stories in progress at one time. You force the team to reduce the number of stories under consideration for a timebox, so the team has a better idea of what they can commit to for an iteration.

Maybe each of these changes is not so big as a single change, but taken all together, they are a huge change for a given team. For the team who thought they could pull one over on me, each change was a big change, and all the changes together was a monumental shift in the way they worked. And, when I suggest we start the iteration on a Wednesday, I thought they were going to revolt, especially since it was Tuesday afternoon.

"Can't we start on Monday?" one of the developers plaintively asked.

"What do we gain by waiting?" I asked.

"We get accustomed to the ideas," he replied.

"You get to research and discover more ways you can push back and tell me why things won't work here," I answered."

Everyone laughed, nervously. I said, "Look, I'm asking you for two weeks. Starting tomorrow morning. The worst thing that happens is that you get through tomorrow morning and you hate me. Right? That's about me, not you. What do you have to lose? All you do is take it one step at a time. And I'm with you each step of the way. Ok?"

They agreed. I was concerned they would all be sick the next morning, but they all came into work on time. We did plan the next morning. And they did get through the next afternoon. They almost finished a small feature, which blew them away. By Friday afternoon, they had finished two stories off the backlog. And, they discovered what prevented them from making their integration continuous. And, they learned what the testers needed for an automated test system, and created a just-enough test automation system.

By the end of the iteration, they had finished eight of the ten stories on the backlog, discovered they had mis-estimated two of the stories, and had discovered five new stories. They had never worked like that before. When they provided a demo to the product owner, the PO was thrilled.

Not all teams have such great results. As with all changes, your mileage will vary. But when your team says, "the iteration is too long," consider shortening the duration, not lengthening it. The more opportunities the team has for feedback, the faster the team can learn.