Posts Tagged “agile development”

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 »

This blog is the result of a great question asked in the comments of my last blog entry. Quinn asks:

“Of course we get side-lined by an occasional production support task or an overly optimistic lead developer that bites off more than we can chew…. I feel that it’s a huge slap in the face when you are programming like a ferret and don’t get to 1 or 2 stories out of 25-30 in a 2 week iteration and the PM or IT Director is “disappointed” that you have carry over…. And thus I bring the question to you–what is the TRUE measure of success?”

Great question! Read the rest of this entry »

Comments No Comments »

Sometimes agile teams have to draft and deliver scope, discovery, requirements or high-level design documentation. I don’t want to get into the how or why in this blog entry. Rather, I want to spend the entry discussing how these documents can be shaped as features and broken into discrete, estimated tasks so they can be prioritized, managed and tracked like any other development work in an agile process. Read the rest of this entry »

Comments No Comments »

One could argue that Traditional Management arose from a concerted attempt by executives and directors to get reliable budget forecasts, staffing requirements, delivery date forecasts and quality commitments from development teams. They need this information to manage the company’s budget, growth, strategic direction and overall product delivery. When they don’t get this information–or don’t trust what they get– executives and directors institute rigid and often uncompromising processes on their development staff to wrest this data from their teams and to approve and steer projects. Read the rest of this entry »

Comments No Comments »

I get a variety of reactions from both doers and managers when I tell them that the average individual contributor on a project team only completes three effort days of delivery-related work in a week. Usually the reaction is surprise. Surprise the number is so low. Surprise I’m willing to admit the number is so low. And surprise that this is a perfectly acceptable amount of work to complete each week. Read the rest of this entry »

Comments No Comments »