Agile Zone is brought to you in partnership with:

Michael Norton (doc) is Director of Engineering for Groupon in Chicago, IL. Michael's experience covers a wide range of development topics. Michael declares expertise in no single language or methodology and is immediately suspicious of anyone who declares such expertise. Michael is a DZone MVB and is not an employee of DZone and has posted 41 posts at DZone. You can read more from them at their website. View Full User Profile

Esther Derby asks: Are we aiming too low?

11.03.2010
| 1327 views |
  • submit to reddit
Esther Derby put together a nice post on the importance of design for a web site in which she asks, "Are we aiming too low?"


Agile methods manage business risk. They can bring back enjoyment and pride in work for development teams. For the people who use our software, they make work life maybe less frustrating, because the software isn’t buggy, and maybe a little easier because the software does what it’s supposed to do. But I think we are aiming too low. Can we also make software a pleasure to use?


Makes me wonder

Story Composition

I've been working with teams lately on story composition. We've been discussing how we could break stories down based on value to the business rather than based on how we technically execute. Our objective is to be able to deliver value to the business as quickly as possible. So we want to avoid chunking larger stories out into smaller stories that are then dependent upon one another for delivery. We've really achieved nothing other than creating bottlenecks in our flow. We still have to build the whole thing in order to deliver.
So a common technique we've been using is to break out aspects of the story that are must have from nice to have. Often, this ends up being along the seam between functional and sexy. With functional clearly being must and sexy riding shotgun at best.
Executing on this strategy, we are able to deliver functionality faster and we haven't any dependencies between the stories other than the must have need to come first. But this is perfectly acceptable to the team. Must have should come first.

Are we missing something important?I think we are. I think by consistently breaking the stories down in this manner, we are cheating the customer. We keep putting features that make the application nice to use on the back burner. Frequently they don't get implemented because the next "must haves" bubble to the top of the queue as the "nice to haves" slowly drop.

But by executing in this manner, we are consistently missing the opportunity to make the user experience truly pleasurable. We are focusing too much on utility and not enough on what makes the application truly desirable.
References
Published at DZone with permission of Michael Norton, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags:

Comments

Emma Watson replied on Fri, 2012/03/30 - 5:00am

I've definitely seen this happen. One way we've tried to combat it is to define "quality" more strictly, to encompass quality of the user experience. We've also emphasized that the product owner should refuse to sign off a story if the implementation is not polished, and the UX is not up to scratch.

JDBC

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.