Posts Tagged “iteration management”

At present, I am watching a release cycle lumber into its fourth week of user acceptance testing (UAT). This release is the first tangible deliverable after five months of work by an out-sourced vendor.

The release plan – as developed by the vendor – included one week of QA (stomped) and one week of UAT (clobbered). Our project manager, to his credit, questioned those durations as inadequate the moment he saw them.

When a team codes for five months and throws that work product over the fence for testing, the team cannot efficiently field each issue that gets tossed back. Every new issue is likely to force a context-switch from what was built in month one to what was built in month four and back again.

Additionally, five months of development can result in layers of unreleased code, built one on the next, greatly increasing the number of bugs hidden behind two, three, or more other bugs. This is how big UAT transforms into a bad metaphor. It’s the repeated digging to find an issue, commission a fix, test the fix, resolve the issue, dig again, hit another issue, etc. When bugs are buried one behind the other the entire exercise becomes an exhausting and duration-consuming beast. And we’re living with that.

None of this is meant to fault the vendor (well, except for aggressive optimism on the release timeline). First, the vendor is very good at what they do – and what they do is different than what we do. Second, the nature of the work is not amenable to an agile approach (I know this from experience). While there are lessons to learn from this experience, there are no buildings being toppled nor people waiting for a two-ton-heavy-thing to drop on them. It’s not a crisis.

But it does remind me of a huge benefit that comes from agile development (in general) and short iterations (in particular). The team that releases code frequently has much greater control over the tesing, acceptance, and delivery process. Each short iteration keeps testing (and the issues that fly out of testing) to a manageable size. Finally, each small work product ensures that everyone’s head is in the same game, since the team that just completed an iteration’s functionality is immediately involved in its testing and review.

Comments No Comments »

Self-Reported Reasons for Sickness -- Eurofund Report NL0607NU04

I think I’m seeing a pattern here. For the second year in a row a blight of sick days has swept the office in the second half of February. Currently, we have multiple teams sorting through their iteration backlogs to account for and replan missed commitments.

This raises an interesting question. Next February, do I ask the project managers to account for potential sick days (basically, commit to less) in their iteration and release planning activities?

Perhaps that’s taking things too far. But I’m going to be on the lookout for this one next winter.

Comments 1 Comment »

Remember, back in grade school, when we used to get snow days? That is, when there was so much snow that they announced over the radio that school was closed for the day and — even better — we got to spend all day playing in the snow? Remember that year when we had so many snow days that we had to stay in school a couple extra days at the beginning of summer to make up for them while kids from other schools got to start vacation? That kind of sucked.

On agile teams — even experienced ones — I often seen people take snow days. Sometimes the estimates were simply too conservative, and sometimes all the remaining development tasks get blocked by external dependencies. Either way, team members find themselves with no open tasks to complete days before the end of the iteration and, instead of going to the team, the project manager, the tech lead, or the team customer to ask what they should work on next, they take a couple snow days. Of course they come to work and of course they do work, but they often spend the snow days on interesting but low priority tasks.

Read the rest of this entry »

Comments No Comments »

In my last post I mentioned the Iteration Zero technique in passing. I’m going to tackle it head-on today.

Agile teams strive to deliver functionality that can be touched or even used by the customer at the end of the first iteration. Sometimes, however, it does make sense for the team to focus on building its foundation before delivering functionality. This may be the case for larger applications, for teams new to agile development, or for projects where the the features are still extremely fuzzy. These are perfect opportunities to execute an iteration zero.

Read the rest of this entry »

Comments 9 Comments »

I’ve seen quite a few teams (and not just newbie teams) grapple with this problem. The team has come up a bit short on available effort and can’t hit the release date at the end of the iteration. Just another day will do it, really. Extending your iteration a day to hit the release is a very tempting idea, but it is the very last thing you want to do. That decision simply leads the team down a road of pain. I forgot that lessen a couple months back and allowed a team to travel that road. It went something like this:

Friday the 5th

Advocate for the extension: “We’re just a little too tight this iteration. If we move the retro and planning meeting from Tuesday morning to Tuesday afternoon then we can release in the morning and hit our iteration goal.”

Me: “Okay, is there anything we can take out of the iteration backlog so that the team can still deploy on Monday?”

Advocate for the extension: “No. Everything has to go in.”

In retrospect, that statement should have set off alarm bells Read the rest of this entry »

Comments No Comments »

The teams that I work with have two very important rules around task ownership. First, regardless of the number of people doing work on a task, each task should only have one person’s name on it. Second, regardless of who is actually doing the work, the task should always belong to an active member of the team. Read the rest of this entry »

Comments No Comments »