Featured Bloggers
By: Milissa Tarquini
Filed under: conferences and events, culture of design, process, product design, UI IA
Last week a few of us headed to the IxDA conference in Savannah. It was a great time and now that I'm back, I will be sharing some of the happenings with you. The first session we attended was a pre-conference workshop on Agile methods, given by Jeff Patton (at AgileProductDesign.com) and Josh Evnin of ThoughtWorks.
It was a very basic primer on Agile, and included information on other methods of process, such as the waterfall method and the snowman method. You can read about all things agile at Jeff's site (link above). Much emphasis was on speed to market, and how Agile methods can support a faster turnaround on product completion.
We did a "real" agile project, where teams had to work with a "User" to define and develop a product end to end, splitting up tasks appropriately. The products were cars, and they were drawn on a puzzle board so each person could take a piece and then put it together at the end. We were of course terrified of the Homer Simpson factor, an incredibly accurate depiction of what you may end up with if you rely completely on what users think they "want" without reality checks.
The Homer Car:
After a meeting with our "user" (confession, it was me), the team went to work and the "user" got to sit around and wait for the finished product...
I chose to annoy them by snapping pics with my iPhone. Look at how fast they are working together:
The team: Mike Costantino, Russell Medeiros, Sarah Allen, Russell Wilson.
Our team came in first with the most number of features completed, and our totally gorgeous car had all the required features except for a trunk (not bad, considering we all got cut off on time). Check out the huge low-profile wheels and fancy rims. (As the "user" I had to make sure my car had style, right?) ;)
And the "user" rated it an A- overall. We rocked!
But the most compelling example of why Agile methods can be much faster to execute was an exercise the group performed with dice in the beginning of the session. Here's how it went:
Six people in a team. Each team got 6 dice. For the first round, the first person turned each die so one dot was face up, then handed them to the second person who then turned them so that 2 dots were face up, and so on until the 6th person had turned them all to 6. Each team was timed.
Then each team was given the instruction that the first person should turn three of the dice to 1, hand them off to the second person and then work on the last three (and turn them over tot he second person again). Each team was again timed, and there was an amazing time difference. Our team came in around 58 seconds for the first round and 32 seconds for the second round. We did it again, this time with only exchanging 2 dice at a time, and the times improved again, but to a lesser extent. (Our team got 29 seconds on the third round, I think.)
So to sum up, smaller tasks in succession is faster than the larger tasks all at once. Makes sense, no?
It was a very basic primer on Agile, and included information on other methods of process, such as the waterfall method and the snowman method. You can read about all things agile at Jeff's site (link above). Much emphasis was on speed to market, and how Agile methods can support a faster turnaround on product completion.
We did a "real" agile project, where teams had to work with a "User" to define and develop a product end to end, splitting up tasks appropriately. The products were cars, and they were drawn on a puzzle board so each person could take a piece and then put it together at the end. We were of course terrified of the Homer Simpson factor, an incredibly accurate depiction of what you may end up with if you rely completely on what users think they "want" without reality checks.
The Homer Car:
I chose to annoy them by snapping pics with my iPhone. Look at how fast they are working together:
The team: Mike Costantino, Russell Medeiros, Sarah Allen, Russell Wilson.
Our team came in first with the most number of features completed, and our totally gorgeous car had all the required features except for a trunk (not bad, considering we all got cut off on time). Check out the huge low-profile wheels and fancy rims. (As the "user" I had to make sure my car had style, right?) ;)
And the "user" rated it an A- overall. We rocked!
But the most compelling example of why Agile methods can be much faster to execute was an exercise the group performed with dice in the beginning of the session. Here's how it went:
Six people in a team. Each team got 6 dice. For the first round, the first person turned each die so one dot was face up, then handed them to the second person who then turned them so that 2 dots were face up, and so on until the 6th person had turned them all to 6. Each team was timed.
Then each team was given the instruction that the first person should turn three of the dice to 1, hand them off to the second person and then work on the last three (and turn them over tot he second person again). Each team was again timed, and there was an amazing time difference. Our team came in around 58 seconds for the first round and 32 seconds for the second round. We did it again, this time with only exchanging 2 dice at a time, and the times improved again, but to a lesser extent. (Our team got 29 seconds on the third round, I think.)
So to sum up, smaller tasks in succession is faster than the larger tasks all at once. Makes sense, no?
Related Links:
© Copyright 2008 AOL, LLC All Rights Reserved
Reader Comments (Page 1 of 1)
As a note to add to Milissa's about how iteration can improve speed., there is a point of diminishing returns. Each system and project is different. Based on the incredibly simple 6 dice experiment: initial scope (6 dice) - 58 seconds; iteration of half size (3 dice) - 32 seconds, almost half the 6-dice time; BUT iteration of third size (2 dice) - 28 seconds, barely any time benefit over the half size iteration.
Also, key to note was that Agile methods are designed to bring products to market quickly, but NOT NECESSARILY cheaply, as numerous concurrent iterations tax the resource base differently. I'd have to read more on how to properly interpret that for our environment.
”
Posted at 9:24AM on Feb 14th 2008 by Michael Costantino