Homepage ->  Individual Weblogs -> Jeffrey Fredrick  -> Cockburn, Goal Displacement, and Running Tested Features

September 10, 2005 - Cockburn, Goal Displacement, and Running Tested Features

On Friday Alistair Cockburn posted an article with the provocative title "Are Iterations Hazardous to Your Project?"...

If you aren't turned off by the provocation you'll find a nice article that challenges you to keep your eye on the ball when it comes to iterations, user stories and velocity. Are you choosing your iteration length and story sizes because that's really effective for your project, or is this some sort of Agilista machismo? The example he gives of the homework project is an excellent illustration about how it can be easy to be led astray. It is all to easy to suffer goal displacement, to think the point is to rack up maximum velocity when really the goal should be to maximize the delivery of value.

Also worth reading is the reply by Ron Jeffries who reminds of us his metric of Running Tested Features. To my mind the reply shows how close the top people in the agile community are to each other, though there may be some disagreement around the edges on terminology or the finer points of running an agile project.


Posted by Jeffrey Fredrick at September 10, 2005 10:14 AM


Trackback Pings

TrackBack URL for this entry:
http://www.developertesting.com/mt/mt-tb.cgi/168


Comments

Alistair has some extremely valid points. I've personally experienced agile teams that ran iterations that were too short and/or stories with overly small granularity.

"Deadlocking story development"
A consulting team of my colleagues, entirely technical, was helping one of our clients adopt XP / TDD practices on a project. The Customer, who had no background in agile, had been given guidance to craft stories as small as possible. Problems ensued, somewhat along these lines:

Story A: Display first name in first cell of table after performing search for a person

Story B: Display middle name in second cell of table after performing search for a person

Story C: Display last name in third cell of table after performing search for a person

Story D: Display next bit of information on the person object.

Given that most agile teams never set the points on something lower than a certain threshold, there were alot of "points" to get done. Yay! Yet no one questioned the story granularity.

Four iterations later, very little velocity was observed. Developers could not work in independent pairs on separate stories easily without managing code ownership issues.


"Starting on monday, finishing on friday"
If a team insists on running 1 week iterations, please dont do this. Start mid week. Something about the weekend can give people time for fresh ideas to problems.

Better yet, try and avoid 1 week iterations. Be flexible and set the iteration length where it enhances the trust relationship between the customer and developers. This means the team needs to accomplish something meaningful to the customer, and in too short a time frame it will not happen. The customers involvement in the agile process, knowledge of development, and interest in the domain will influence this of course.

Posted by: Matthew Short on January 25, 2006 03:45 PM

I'm guilty of writing stories like that myself (along w/the rest of the team), a problem we sovled through retrospectives.

I agree the weekend gives people fresh ideas, which is why I like to have the iteration planning sessions on Monday. :)

I've never done mid-week interations starts... thinking about it, it just feels unnatural. I should probably try it sometime just to have the experience.

Posted by: Jeffrey Fredrick [TypeKey Profile Page] on January 26, 2006 01:39 PM

Post a comment




Remember Me?