Esther Derby 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
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.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)