Winging It

Iterations Are Not a Deadline

I have worked in iteration based systems for years. I have worked in one week and two week iterations. (I have heard tell of people doing iterations measured in months or quarters, which scares the bejeesus out of me.) I have also worked on teams where we have gotten rid of iterations all together because they did not make sense for our situation. Those teams were Kanban teams and we valued continuous flow over the choppy stop, start, "slam QA on Thursday" that iterations can sometimes become.

At a recent conference I overheard a conversation between a colleague and an attendee. The colleague in this case had just given a seminar on Kanban that this particular person had attended and had a few follow up questions. The first few questions were pretty mild, then it happened...

"How do you make Kanban work without the pressure of the iteration to make your developers finish their work?"

That one fired me up. I did not dive in the middle of the conversation red faced and shaking my finger in this way-too-obvious-project-manager's face. Instead, I did the next best thing, I unleashed a strongly worded tweet.

"We need that by, um, Friday"

The first issue here is we have no proof that a deadline forces a team to deliver anything. It might give the illusion that the team beats a deadline, but under the covers somewhere there is an issue. Think back before the salad days of agile when were waterfalling ourselves against massive deadlines, ever move a deadline?

I was on a team doing two week iterations and the second Friday was the end of our iteration. On normal days the team room was emptying out by 4:30 every afternoon, by 5:30 there might be one or two people there. But on every other Thursday it was full until 6:30 or 7 with the last person leaving closer to 9. Why? They had a deadline to beat. Did they get their work in? Usually, yes, but they were hiding the real problem. They were beating their deadline, but they were working hidden OT to do it, taking time away from home, and hiding the real issue from their Product Owner.

I am sure a few people are thinking, "Hey, Tim, they got their work done! Every iteration! They were heros to company!" Those of you thinking that, I say for shame. OK, I do not say for shame, but I do say that they stretched their time box in an effort to appear successful.

An iteration at its core is a time box. It is a fixed amount of time in which we will try to get as much high quality, well tested work done as we can. As a team, this group had agreed to do two week iterations with an iteration day for retrospective and planning. They had agreed to do 72 hours of development and testing, and every other Thursday they were stretching that to 75 or 80 hours. So maybe they did get the work done, but they had broken their agreement - with their Product Owner, and worse, with themselves - to get that work done.

We have all heard of the iron triangle of software development, there are three points of the triangle of time, scope, and quality and only two of those points can be fixed. We like to operate on quality as a fixed point, so pick time or scope and make it variable. An iteration says time is fixed, but all too often it becomes variable because of fixed scope by the end of the iteration.

Use the Time Box

As noted above, the iteration is meant to be a time box. A start and an end to some amount of work. At the end of that time box we hold a retrospective to learn from the previous block of work.

What went well?

What did not go so well?

What went great?

What does the team never want to do again? Ever.

This is the time to learn about your team and make adjustments. If all the work got done with a whole day left in the iteration find out why. Yes be thrilled that all the work got done and your team is awesome, but we still need to learn WHY it happened and WHAT we can do to leverage that in the next iteration.

Now let's say the team did not get their work done a day early. Instead a couple features did not get completed. I am sure we will be asking WHY in this case. Maybe this is the third or fourth iteration in a row some features did not make it to completion. We could say that our team is terrible and they should type faster, but we are seeing a pattern here. Two things jump out at me right away in this situation: Are our stories too large? And are we taking on too many stories per iteration?

If we are taking on too many stories or a few stories that are sized, shall we say, aggressively then start trimming them down a little. Take on less work at the beginning of the iteration in an effort to be successful at the end of the iteration. A team that knocks out its work by the end of the iteration - WITHOUT working until midnight the day before the end of the iteration - will be all smiles at the retrospective.

One bonus to not crushing the team, aside from the obvious good team morale, is you will build some slack in for the team. Any dev team needs a little slack, and not just to shoot nerf darts at each other. Slack allows the team to refactor. Something that was trouble two iterations ago probably needs some attention to keep it malleable for future features.

Slack allows for innovation. Giving the team time to step back and look at features together allows them to find better ways to solve the problem.

Slack allows the team to breath and it keeps them from rushing through problems. The old adage "Haste makes waste" is not more true than in software development. Rush through a solution and you can expect bugs to be opened, leading to more rushing, then bugs, then rushing...wash, rinse, repeat.

I've Read This Somewhere Before...

Agile is about continuously learning, no matter what process you are using. You should be learning more about your team, your product, and your problems every iteration. Every day.

Agile Manifesto line four: "We value responding to change over following a plan."

Iteration deadline: plan or time box?