Agile Project Planning

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

Sunday, September 25, 2005

Agile Interaction Design?

In the book About Face 2.0, authors Alan Cooper and Robert Reimann detail the role of the Interaction Designer on a software project. The authors promote the idea that this new role is not something that a software developer would typically do, but requires a new breed of professional.

At the risk of oversimplifying, an interaction designer is essentially responsible for user-centered design, which consists of discovering user goals, and trying to design solutions that meet as many of them as possible. One of the primary tools for this is developing "personas", with unique needs, likes and dislike, and of course, goals. The authors believe that this work should occur before any software is built.

While I strongly agree with much of the material in the book, it did make me wonder about how this might work in an agile setting. Agile methods tend to avoid Big Design Up Front, but that tends to mean overly complex design documents that guess about the architecture and implementation of the system. Some agile proponents also avoid documentation other than index cards with story descriptions, and transient whiteboard sketches.

So can an agile team incorporate Interaction Design (I'm going to call it ID from now on) ? Well, to paraphrase Cooper in an interview with Kent Beck, father of XP, yes, as long as the ID team can do their work first, before the programmers get a crack at it.

I'd compare this to the recent Joel Spolsky article where Joel takes a shot at XP for not encouraging up front functional specifications. He argues (and I agree) that functional specs done right, and done first, save a lot of time in the development process. I think Cooper and Reimann are less concerned with the time involved, but certainly believe that ID produces dramatically improved solutions that make users happy. And, like Joel, they believe it should be done up front.

An ID team probably becomes the voice of the customer in Agile methods, and as such should be working closely with the development team as well as the users. In that sense, the ID role may be more of a liaison between customer and developer.

So is ID compatible with Agile? I think it is, just as functional specifications, formal testing, documentation, and other traditional software disciplines are. The danger would be if the work of an ID team turned out to be inaccurate or ineffective, but I think this can be mitigated by following what I believe is the Golden Rule of Agile: Deliver Early and Often.

For more on agile tools and techniques:

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

Sunday, September 18, 2005

Why User Errors Are Your Fault

It's just another day at the office. Joe User has accidentally erased his work again using your software. As he curses your name for the third time this week, you rest comfortably in the knowledge that your software works as designed.

Of course, the fact that he's just one of dozens of your users who made an offensive remark about your anatomy this week might give you pause. Complaints are a bit like New York City rats (pardon the metaphor) - for every one you see, there are 10 more lurking about that you don't see.

"But wait!", you say, "The software is working perfectly, it's the stupid users that keep losing their work by hitting the erase key."

This is a too common story in the world of software. As developers, we strive to create software that we think meets our users needs, is easy to use, and gets the job done. But the users keep finding ways to hurt themselves. The temptation is strong to blame the users, but when you notice a trend in "misuse", there's no better place to point the finger than at yourself.

When multiple users keep having the same kind of accident using your software, there's a good chance that you have a design problem. Resisting the urge to ignore this valuable input can help you improve your product. Think of it as just in time usability research (although certainly it might be better and cheaper to do this up front).

So the next time you hear a user complain about a perfectly working feature in your software, listen closely, you might learn something that will help you improve your design. And the next words you hear might be rave reviews.

For more on agile tools and techniques:

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

Sunday, September 11, 2005

How Man-Eating Turtles Can Save Your Software Project

Imagine you're on a safari, and your guide tells you that there are hungry man-eating turtles all over the place. The good news is that you can outrun them as long as you see them coming. The bad news is that it's nighttime. Don't you wish you had a flashlight?

OK, there aren't too many man-eating turtles I'm aware of, but this is a metaphor, so bear with me. The same kind of dangers await any software project, just in the (non-man-eating) form of shifting business needs and priorities, technology obstacles, personnel issues, and politics.

The main advantage you have, either on safari, or as a stakeholder in a software project, is to get rapid feedback about where you are, and where the lurking dangers are. Sure, it's possible to get to your destination without it, but it's more likely you'll wind up as turtle food.

In software projects, there are 2 dangers that rapid feedback helps you avoid: failing to deliver the right functionality, and failing to build the right technical infrastructure. You might say these are the man-eating turtles and malaria of software projects.

Much has been said about involving customers in the development of a project, but the point I'd emphasize is that delivering working features that can be used is the most meaningful way to involve them. It's great to get early input, have them review specifications, sign off on technical documents, and so on, but until you get something into their hot little hands, you won't know how you're doing.

Similarly for technical infrastructure (a.k.a system architecture), it's important to know whether you've got a clean, flexible design that can accommodate changes. Here, keeping things as simple as you can is a step in the right direction. If the software you build is more complex to explain to a new developer than for them to write it from scratch in a simpler way, guess what's going to happen in a year or so? Another valuable practice is what XP calls "merciless refactoring" - which means clean up after yourself. Don't make a delicious chocolate cake and leave the kitchen too messy to make anything else. And make sure your customers like chocolate!

So the next time you think about about spending more than a couple of months working on a new feature without delivering it to a customer somewhere (internally or otherwise), think about those turtles that could be nipping at your heels. They may be slow, but they're cunning, and have tremendous closing speed.

For more on agile tools and techniques:

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