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.
 Author:Peter Schuh
Comments 
Write comment
 |
Show/hide comment form