I spent the past week at the Agile 2005 software conference. What an amazing conference and inspiring group of people! I spent some time with Lynn Miller from Alias who presented a report about how her companysuccessfully integrated User Centered Design (or UCD) with agile XP (Extreme Programming) practices. Lynn is the lead interaction designer on an innovative product called AliasSketchBook Pro. As an interaction designer, Lynn gathers customer information and defines and refines user features through prototyping and customer feedback. Lynn then feeds her designs to the development team who develop production quality code in month long â€œsprintsâ€. At Alias, interaction designers work in tight collaboration with the development team, feeding them just-in-time interaction designs. According to Lynn, this is pretty unusual. Most companies do interaction design in all in one big lump before doing any software development. At Alias, interaction design is done monthly increments, just like the code. Each coding sprint is fed by features defined by the interaction designers who worked on them during the previous month. Skeptics in Lynn’s field don’t believe that usability design can be done this way without sacrificing quality. Alias’ success story challenges these assumptions.
As an interaction designer Lynn isn’t up on the latest agile jargon. So for the first couple of days at the conference she was puzzled when she heard stories about how other agile teams had trouble identifying and working with the “customer” who defined “user stories” that the team implements. To Lynn’s and most people outside the agile community, customers are people who purchase products or services. How could you co-locate the “customer” with a development team? Don’t companies have many customers? What exactly was the problem some XPers were having? Only after a Lynn realized that XP defines customer as “an informed expert who clarifies requirements for an XP team” did her confusion evaporate. An XP customer isn’t necessarily an end user or purchaser of a product. Lynn plays the role of “customer” for her XP development team when she designs features. I agree with Lynn, the definition of an XP customer is confusing.
Lesson learned: Agilists who communicate with others outside their own community need to be aware that jargon is confusing. When someone looks puzzled it may be because they don’t share your context. Bridge this gap by asking a newcomer what’s unclear. Then take the time to decode insider jargon for them. You’ll learn something about what they do and how they think in the process.
I discussed with Lynn and Jeff Patton (another talented user-centered designer)what we each mean by “design”. To me, a software designer, design means creating a model of interacting software objects that are implemented in code. Interaction designers use a raft of techniques ranging from contextual inquiry (to understand the users’ work environment), to user-centered design (to cluster tasks and identify user categories), to interaction and user interface design. All these activities to an interaction designer are “design”. It was pretty easy to understand our different views and see how they dovetailed into an overall system design process. I don’t think we should come up with an unambiguous definitios for our various activities. Besides being unrealistic, we’d all have to start speaking design Esperanto which wouldn’t be a good thing. But I learned something. When you don’t understand what I mean, it is my problem not yours. As a good communicator I should try to bridge my ideas into your context. And when you don’t understand what I’m saying, please ask, “What do you mean by that?”
As a mental exercise, two colleagues and I have been spending time uncovering and documenting the problem frames in internet email. It is nice to frame a complex, concrete example that has architecture descriptions readily available. We can compare what we come up with against the machinery that’s already been built. Initially, I didn’t want to know too much about how things really worked so I could stack up our frames against the architectural solutions that already exist. Lately I’ve discovered that by examining technical architecture descriptions, I can quickly frame new parts of the problem which I can then use to loop back and try to understand the reasoning behind existing architecture.
Based on the problem we’re framing, we can also conveniently draw parallels between email and the physical world of postal mail. Today, Jim explained to Nathan the difference between local and internet based dispatching of mail by drawing an analogy to delivering mail within your house. If you address a letter to another family member, there’s no need to put it in mailbox, just hand deliver it. While the physical analog of postal mail is interesting, there’s a point where it is critical to drop it and focus on the problem at hand. Analogies only take you so far. But this got me thinking. How did the original architects of email find their inspiration? Did they create their solution based on perceptions of how the postal mail was handled? And if they did, when did they break away from that mental model and do the really heavy mental lifting needed to finish their design?
To me, an important aspect of framing is the questions it leads you to ask. Answering those questions helps you make design decisions. But even when looking at an existing technical design, framing has value. You can question why things are as they are and what problems were being solved. For example, in Qmail why are there two mail delivery strategies—one for local and one for non-local email? Presumably, because local messages can be processed faster and cheaper. Which leads to asking whether this is really necessary or a holdover from earlier computing days? Thinking for a bit, we enumerated a number of reasons why local mail can and should be handled differently than remote mail. (No need to check for spam, no need to go to a domain name service to get the host to transfer to, processing can continue when the parts of the internet are down). In short, local email can be processed much more efficiently and outgoing mail should be processed much more reliably; they are two different concerns that shouldn’t be lumped together into the same solution. Problem frames can help you focus and subdivide a problem into smaller ones. I want to continue to wade deep into software machinery and critically examine whether framing helps me understand the nature of problems. I’m concluding it does. So far I’m not inventing anything, just exploring known territory. But even there I find value in framing and then asking why. Makes me feel like a two-year old, but then again, maybe not. Analogies only go so far.
A couple of weeks ago a friend sent me a link to the World’s Smallest Political Quiz.
If you answer 10 questions on personal and economic issues (with possible answers being yes, no, and maybe), you’ll get rated on whether you are a Liberal, Centrist, Conservative, Libertarian, or Statist. I passed the link out to a few friends and family members and said I’d report my test score if they’d tell me theirs. Needless to say it was interesting. I’m married to a libertarian, have a centrist brother, and have raised two liberals. When I take the test (depending on my mood I answer questions differently) I’m either a liberal or a centrist. I lean towards supporting significant personal liberties but believe in the value of some “governmental controls” especially where environmental issues are concerned.
This political test got me thinking about concocting a similar test for software development processes to ascertain whether developers are agile, centrist, traditional, anarchic, or formal. I’ve been reading too much agile and traditionalist bashing on newsgroups lately. It’s time that software folks call a truce to name calling and make a concerted effort to understand what’s driving their differences and what values they may have in common (even though they are in different camps).
I see software situations where more formality is needed. I also see situations where agile approaches would definitely inspire teams. At some places, the development processes seem to work, but development still proceeds slowly. I’m not sure whether agile practices would speed things up. They live in a complex world with lots of rules and regulations. On the other hand, I’ve definitely seen places where testing for quality at the end of a long development cycle definitely hurts their delivery. And I’ve visited other places where any process or project documentation would be better than what they have now. Still other groups seem to thrive on rolling their own software without much thought to process at all. Maybe instead of centrist, I should be labeled “chameleon”. What works depends on circumstances and your group and organization’s leanings.
However, there seem to be two fundamental axes that divide software process beliefs: predictive versus reactive planning, and evolutionary design/development versus targetted (or planned) design/development. (I plan on exploring the differences I see between evolutionary design and incremental design in the future. But from my vantage point there is a big difference.)
What agile folks believe and more traditional folks believe isn’t that different in some areas. Both tend to value teamwork and process. Anarchists don’t. Neither do formalistsâ; they tend to value the formalisms over any process that gets them to those formalisms. It is just agilists don’t place high value on document or pre-work (be it design, extensive requirements gathering, prototyping), etc. The lines between code and design are very blurry. I’m still working on questions that will draw out more of these distinctions.