Agile Project Planning

ExtremePlanner: Agile Project Management for Distributed Software Teams
Click For Your Free Online Trial

Wednesday, July 26, 2006

Is Agile Development Killing Usability?

Does the agile software development mantra of "Do the simplest thing that could possibly work" lead to functional, but unremarkable software?

In this article on Wired, the author raves about Apple's attention to detail in something as small as a Date column changing its format when it's resized.

While I was adjusting the width of the columns, I noticed that the date changes format depending on the width of the column. If the column is wide, the date is displayed as "February 27, 2006." But if you narrow the column, the date changes to a shorter format: "Feb 27, 2006." If you narrow the column even further, the date format changes to the shortest format possible: "2/27/06."

In one sense, agile development approaches have nothing to say about this level of usability or "delight", as this is something the customer or "product owner" needs to specify and prioritize. So a customer that values the little details that make users squeal in delight would be wise to consider those as priorities, assuming they aren't too costly.

But in a more philosophical sense, since agile development promotes frequent delivery, and ruthless prioritization, your team will quickly be forced to make choices about what its true goals are. For commercial software, little touches can be critical to building loyal users, but it's the big features that get most of the attention. Internal software will often make do without the bells and whistles in exchange for more features, since their users are somewhat captive.

It does seem, though, that agile teams will be less likely to either prioritize or implement some of the more subtle touches of the kind that the Wired article discusses. When forced to choose between the features "Send email", and "Implement graceful date column resizing", guess which one is likely to get short shrift.

To offset this effect, I think it's important when working on a project to be very clear up front what the team values. If "user delight" is a priority, it needs to become infused into the team psyche. Developers, designers, testers, and the rest of the team need to be aware that any idea that can benefit the user experience is worth writing down for future consideration. Every decision needs to be made in the context of "How will this benefit or detract from the user experience?"

Ultimately it will be the customer/product owner that makes decisions about what should go in the software and when, but with the whole team focused on adding value to the user, many more opportunities for small wins will be uncovered.

Agile development is an ideal way to get quick feedback on these kinds of subtle features with its emphasis on frequent releases. But you may need to guard against the complacency around user experience that's often expressed as "If the user didn't ask for it, they obviously don't need it."

It's our job as software designers and developers to see beyond what is asked for to what is truly needed. And sometimes we have to go beyond need, and find joy.

There's nothing more satisfying to me in the field of software than a truly delighted user. It's hard to put a price on that.

For more on agile tools and techniques:
(Tags: , , )

Get your copy of the new book! Agile Thinking: Leading Successful Software Project and Teams

Monday, July 10, 2006

Should Agile developers test their own software?

James Bach writes here about whether programmers should test their work extensively before delivering it to testers.

His conclusion:

Many testers would advise the programmer to test the product himself, first. I have a different answer. My answer is: send me the product the moment it exists. I want avoid creating barriers between testing and programming. I worry that anything that may cause the programmers to avoid working with me is toxic to rapid, excellent testing.

He goes on to indicate that he has no problem with programmer testing, and in fact considers it to be a good thing. But that if it contributes to a wall between developer and tester, then he'd rather just have the code now, please.

A common theme has emerged recently in the Agile world, where I've seen a lot of questionable enthusiasm for doing away with dedicated testers, and having the developers write all of the tests.

I believe in unit tests, especially the automated kind, but acceptance testing is a trickier proposition. Having worked for over 15 years with both developers and testers, I can say unequivocally that a good tester can test circles around a good developer.

So why would we want to throw away the talents and viewpoint of a great tester under the guise of automation or agility?

Well, in an Agile process, fast feedback is important, and the more hoops that need to be jumped through to release software, the harder it is to get that feedback. A dedicated testing team is just another obstacle to overcome on the way to a release, right?

Or is it?

What if dedicated testers weren't a hoop to jump through, but rather a valuable feedback source? What if you could not only find and eliminate more defects, but also find under-specified areas of the software, and be able to anticipate customer needs sooner?

A good QA/testing team can help you do these things.

Does this mean that developers should stop creating unit tests? Of course not. The better the input, the cleaner the output will be. Unit testing (along with Test-driven Development) is an internal quality practice that makes code easier to maintain.

But as for the final acceptance testing and other areas that are difficult to automate, I for one welcome the opportunity to work with talented testers who can help make my software better.

For more on agile tools and techniques:
(Tags: , , )

Get your copy of the new book! Agile Thinking: Leading Successful Software Project and Teams

Sunday, July 02, 2006

Agile Independence Day?

With July 4th upon us (the American Independence Day holiday for non-US readers), I thought it might be fun to celebrate a different kind of independence.

Freedom from fear, paralyzing uncertainty, dysfunctional working conditions, and plans made without the consent of the development team. In short, freedom from software project tyranny! No estimation without representation!

Agile project management is about more than delivering the most important features as quickly as possible, it's also about sustainable human relationships.

Customers and project managers: given the choice between a hostile, surly, overworked developer who secretly wishes you harm, and a happy, friendly developer who goes the extra mile to get things done for you, which would you rather work with?

And developers, which would you rather work with? A distrustful, micro-managing, writing-checks-that-your-backside-has-to-cash project manager? Or a supportive, clear communicating, engaged customer or product owner that is on the same team as you are?

If you're leaning toward the happy and supportive side, repeat the following:

I pledge allegiance to the flag*,
Of the Agile software movement.
And to the principles for which it stands,
One Team,
With Simplicity and Feedback for all.

* The "flag" is probably just an index card. Hey, it's got stripes on it.

For more on agile tools and techniques:
(Tags: , , )

Get your copy of the new book! Agile Thinking: Leading Successful Software Project and Teams