Agile Project Planning

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

Saturday, July 30, 2005

Can user interface design be agile?

The core principles of agile development focus on rapid feedback, frequent releases, and a close relationship with the customer. But many developers of enterprise systems spend most of their time working on back-end infrastructure and architecture that their customers will never see. Certainly non-visual functionality can work well in an agile approach where the customer specifies the "what" but not the "how", but how does this play out for user interfaces?

One of the challenges in UI development is translating a user goal into an intuitive interface that's fun to use. I say that because sometimes software that's easy to use initially, isn't particularly fun to use after you become familiar with it. All of those helpful, cheery animated paper clips and wizards that helped you get started suddenly become like fingernails on a chalkboard. SCREEEEEEECH!

So for a typical agile process, you'd work closely with the customer to develop user stories (requirements), then go off and produce something quickly, and touch base with the customer to see what they think.

Here's the problem - this assumes that they are capable of telling you how to adjust the user interface to better meet their goals. Chances are, they are just representative of the end users, and may not even understand what the best interface is for another class of user. Someone is going to have to make UI design decisions, and our customers might not be the best people to do it. Uh oh.

This problem was recognized by the proponents of Interaction Design, who advocate understanding the different types of users and their goals before producing software that tries to solve it. This flies in the face of most agile thinking, since it does suggest that there is value in designing something up front. Most agile approaches suggest that design is an incremental process, where interaction design (although it certainly can be somewhat iterative), is a bit more concerned with some due diligence and planning to best understand your users.

So who's right?

First, consider that rapid feedback with prototypes is certainly an effective way of communicating with customers, and getting them to engage with the project in a meaningful way. In my own experience, this has been fairly successful, but although you wind up with a useful system, it's not always "fun to use". When I've gone the extra mile and thought of ways to improve the experience by focusing on goals, instead of requirements, I've had delighted users instead of simply satisfied ones.

Why am going on and on about this fun to use stuff? Who cares if it's fun if the system works, meets the customers needs, and is reliable? Well, ongoing research is showing that people are happier and more productive when they use products that are pleasing to the eye and to the senses. Apple's IPod+ITunes combination is an example of a sort of end-to-end "fun to use" product experience. It makes people want to burn and rip music, and even to buy things from the integrated Apple store. It makes them happy.

But still, in a business environment with an enterprise application, do I really care about fun? Actually, yes. It's even more important for people doing repetitive tasks or tedious work to get some joy out the tools they use every day. It's not easy to do, but as developers, if we educate ourselves about what our users need, and look beyond the basic requirements, we're not only making better software, we're actually making our users' lives better.

Being agile doesn't have to mean not listening carefully, taking the time to truly understand what your customer's goals are, and then going off in a whirlwind of activity. Read more about interaction design, and see if it helps you delight your users, and maybe even yourself.

For more on agile tools and techniques:

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

Sunday, July 17, 2005

How much design is enough?

The death of design in agile development projects has been greatly exaggerated.

Although there are new and interesting schools of thought on how and when design gets done, rest assured, agile projects still do design, at least if they expect to succeed. Martin Fowler writes on this subject, and concludes that it's just complete design up front that's fallen on hard times in the agile movement.

The so called "Big Design Up Front" approach to projects is the idea that everything about a software effort can be planned and designed before any coding begins. This model compares software to building construction or electronics. The problem with this approach is that even building and electronics manufacturers run into problems well after the "perfect" design has been handed down. The reason these other industries try to get the design close in the beginning has more to do with the timing and cost structure of mass producing or working with multiple subcontractors. Changing requirements, advances in technology, and the makeup of a team can all affect your system design over the course of a project.

XP and other agile methodologies argue that software is "soft", and can benefit from this by allowing more iterations, gathering feedback, and improving the design incrementally. Why pretend to know all of the answers today, when you'll know more tomorrow?

So does this mean that we shouldn't do any design when working in an agile environment? Of course not. It just means that we can design for what we know about today, and stay disciplined enough to go back and modify the design if we learn something new tomorrow. If we rapidly iterate, then the temptation to add extra layers and extension points before they are needed is reduced, and we'll wind up with less code to maintain when we're done.

As an example of the forces involved, consider a development environment that requires a 4 hour compile before letting you test the code you've written. Developers in this environment will naturally try to do multiple things at once, and to get it right the first time to avoid a long wait. Now if the software finally starts working after several dozen of these cycles, is it more or less likely that the developer will go back to clean up minor internal problems?

Imagine also a software lifecycle that dictates 2 years between releases. Customers in this scenario become very demanding for their pet feature, since they know it will be a long time if they miss the window of opportunity. Are they more likely to be willing to wait if they know they've got another chance in 6 months? Or even in 3 months?

Design works the same way. If we as developers are expected to "get it right the first time", we're more likely to add every bell and whistle (architecturally speaking) possible, even if we probably won't need it (I can hear the discussion now: "But what if one of our beginning users wants to integrate our word processor with his dishwasher...we should add a macro language and an X10 interface just in case that ever happens"). So we want to just design the feature we're working on today, keeping the big picture of the system in mind. At any time the system design should reflect what the system actually does, not what it might need to do someday.

Now, this isn't an excuse to avoid designing at all and just hacking together a sloppy program. XP talk about merciless refactoring to keep the code as elegant as possible the entire time, but incrementally so. So that's really a way of doing incremental design once you know more about the problem. The refactoring step is absolutely critical to supporting an incremental design approach. Refactoring isn't just about code, it's also about the system design. If you decide not to use a database, but then when implementing a feature discover that it will take twice as long to build without one, it's time to take a hard look at that decision.

A simple rule of thumb: If it costs more to design a feature than the customer is willing to pay for it, you're probably doing too much design.

For more on agile development tools and techniques:

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