(This was originally published on Playwell, Alan's personal blog.)

Elisabeth Hendrickson has recently opened a new test-and-development training facility in Pleasanton CA called Agilistry. It’s bright and airy, well-lit and well-stocked, and it feels like home the minute you walk in. In order to publicize her new facility, she very generously hosted a week-long intensive learning exercise.

She invited eleven different people with widely varied skill sets, backgrounds, and interests. She challenged them to build a website in five days using the best practices of interaction design, agile programming, and test-driven-development. We christened it “AgileUpToHere” (#au2h) and it exceeded everyone’s expectations (you can see our results here).

Since it was my 15-year-old homophone web site that was being rebuilt, I nominally played the role of product owner, but I was an observer, an instigator, a goad, and a participant. It’s hard to remember when I had so much fun or learned so much. If you want to learn to be great, I strongly recommend Elisabeth and Agilistry.

Things I learned:

1. After 25 years, it’s time to lose the Windows computer and get a Mac.


2. Good agile developers are self confident; confident enough to trust interaction designers to do interaction design without distrustful oversight.


3. There are lots of programmers who understand that relational databases are not the only approach to solving problems.


4. It is time to build software.


5. Test-driven-development isn’t fully understood. In fact, software testing isn’t fully understood.


6. When even the leanest developer in the room sees really high quality BDUF (big design up front) for the first time, they get all woo-woo and want some for themselves.


7. Getting good software built demands the contributions of many different personalities, competencies, and roles, most of which are new and as-yet ill-defined.


8. Two programmers pairing can create more and better code in less time than one programmer can (I already knew this, but it’s always good to see it in action).


9. Even this jaded old fart can still get excited about changing the world.


10. There are many undiscovered and unfilled product niches on the Web, and one of them is “quality”.


11. People want a leader with a vision.


12. Elisabeth Hendrickson (@testobsessed) is a magical woman. To paraphrase Tom Robbins, “she’s been around the world eight times and met everybody twice.” Like a great chef or symphony conductor, Elisabeth knows how to combine the unexpected to create the sublime. She brought together a dozen people from all over the country, each with different skills, background, desires, and expectations, and then she blended them together into a cohesive, happy, effective team.


13. The pre-written code I arrived with was called “legacy” with a grimace, and was quarantined until discarded. Moral: Non-TDD (test-driven development) code is properly regarded like a ticking time bomb.


14. For interaction design, you can’t have too many white boards, made from porcelain-coated steel, firmly mounted to the wall. For agile development, that isn’t such a big deal.


15. Story-mapping is a major component of the bridge between interaction design and agile development.


16. Story-tracking software isn’t quite there yet.

In a perfect world, interaction design would begin when a product was still just a twinkle in a venture capitalist’s eye. In reality, many software products make it all the way through the development cycle with little thought to the users’ experience, and when executives, sales people, or QA testers finally get their hands on the functioning product and start sounding the alarm bells, interaction designers are brought in to clean up the mess. With increasing demand for design “swat teams” to rescue fully developed but flawed software that is scheduled to ship within months or even weeks, the critical question becomes: how can you avoid getting caught up in the chaos that frequently permeates “crisis-mode” engagements?

What’s a feature?

Features are often the currency of software development and marketing, yet few people can agree on what exactly defines a feature. The term can be used to describe a particular piece of functionality, an entire set of functionality, a capability, or sometimes even a possibility. The experts are no help. Typical is webopedia.com, which goes out on a limb by stating that a feature is, “a notable property of a device or software application.”

In other words, a feature is a feature of something.

What is telling, though, is that the vast majority of definitions refer to featuritis or feature creep, the seemingly endless proliferation of features that glom onto what was once, perhaps, a product with a clear vision. Everyone knows that features pop up during the product cycle like mushrooms after a rain.

In his newsletter article last month, Ryan Olshavsky outlined an overall process for defining new products and services, taking a look at the start of that process. But how do you get from understanding your users to a vision for an innovative product which will appeal to them?

Developing a new product or service is tricky. When everything goes well, the product can redefine a market or even create an entirely new one, to the benefit of its manufacturer and its consumers. When the product doesn't click with its audience, though, the costs—development, employee, manufacturing—can be staggering. How do you ensure that your new product doesn't flop? One effective method is to conduct a requirements definition phase before developing a new product.

Requirements definition simply means "figuring out what to make before you make it." This process is not unique to software products. Architects, for instance, go through a requirements definition phase before they start construction on a home. They talk to the future home owner and determine how many floors and rooms will be in the house, where the bedroom should be, if there's a deck, and so on. Similarly, in the product development world, requirements definition enables you to make appropriate decisions about the functionality and design of a product before you invest time and money developing it. By bridging the gap between the needs of the market and those of your organization, requirements definition significantly reduces guesswork in technology product planning, and helps ensure that business and engineering are working on the same product.

All other things being equal, the more complex your product is, the harder it will be to use. And the harder your product is to use, the more your customers will rely on your technical support department, which tends to increase your costs and decrease your customers' overall satisfaction with the product. The good news is that one of the most simple and effective ways to reduce complexity is to cut unnecessary features from your product. But how do you know which features to cut?

Well, it's not easy. Marketing wants a feature that one of your competitors has so they can cook up one of those bulleted feature comparison charts. The engineers have an idea for a feature that they think is really interesting, and one of them spent the entire weekend coding it. And then there's the "squeaky wheel" customer in Arizona that wants a particular esoteric feature that no one else seems to care about…

We talk to a lot of technology companies here at Cooper, and over the years we've seen some clear patterns emerge. On the positive side, more and more companies are realizing the importance of a good user experience and of the overall usability of their products. Unfortunately, we also continue to see companies falling into the same product development traps, to the detriment of their products, their customers, and their business.

These traps can be hard to spot, because they often appear to be standard business practices (especially when the company has never done it any other way), but when you take a step back you see that those practices really don't make much sense. If you have the nagging feeling that there's something not quite right with your product development initiative, it may be because you're falling into one of these traps. To help you recognize bad practices and work to avoid them, here are three common development pitfalls.