Introduction to Agile Usability, User Experience Activities on Agile Development Projects - Part I - 6 April 2007

This article was originally published at the website of Agile Modeling by Scott W. Ambler
Courtesy of Scott W. Ambler

Read this article in Chinese
(translated by Sean Liu)

1. Agile Software Development (ASD)

To address the challenges faced by software developers an initial group of 17 methodologists formed the Agile Software Development Alliance, often referred to simply as the Agile Alliance, in February of 2001. An interesting thing about this group is that they all came from different backgrounds, yet were able to come to an agreement on issues that methodologists typically don’t agree upon. This group of people defined a manifesto which defines 4 values and 12 principles for encouraging better ways of developing software; this manifesto defines the criteria for ASD processes.

Just as the Software Engineering Institute’s Capability Maturity Model Integrated (CMMI) defines the requirements for a heavy-weight software development process, the agile manifesto defines the requirements for an agile software process. Agile processes which reflect these requirements include:

• Agile Data (AD)
• Agile Microsoft Solutions Framework (MSF)
• Agile Modeling (AM)
• Agile Unified Process (AUP)
• Dynamic System Development Method (DSDM)
• Extreme Programming (XP)
• Feature Driven Development (FDD)
• Scrum
• Usage-Centered Design (UCD)

The vast majority of agile projects are teams of less than ten people, are co-located, have direct access to stakeholders, have access to inclusive modeling tools such as whiteboards and corkboards, have their own development machines, and have access to the development tools that they require, including testing tools. Having said that, some agile teams are very large (upwards of several hundred people), some are dispersed geographically, and some do not always have easy access to stakeholders (Eckstein 2004). Although most agile teams take an test-driven development (TDD) approach where they write a unit test before writing just enough production code to fulfill that unit test, they typically do not have access to UI testing tools. Furthermore, they rarely have access to a usability lab, so in this respect agile is little different than traditional development.
Figure 1 depicts my rendition of a generic agile SDLC, which is comprised of four phases: Iteration 0, Development, Release, and Production. Although many agile developers may balk at the idea of phases, the fact is that it’s been recognized that processes such as XP, AUP, and Agile MSF (which calls phases “tracks” instead) do in fact have phases.

Figure 1. The Agile SDLC.

Let’s consider each phase in turn:

1. Iteration 0. The first week or so of an agile project is often referred to as “Iteration 0” or “Cycle 0” (cycle is an alternative term for iteration). The goal during this period is to initiate the project by garnering initial support and funding for the project; actively working with stakeholders to initially model the scope of the system at a high-level; starting to build the team; modeling an initial architecture for the system; and setting up the environment.

2. Development phase. During development cycles agilists incrementally deliver high-quality working software which meets the changing needs of stakeholders.

3. Release phase. During the release cycle(s) agile practitioners transition the system into production.

4. Production. The goal of this phase is to keep systems useful and productive after they have been deployed to the user community. The fundamental goal is to keep the system running and help users to use it.

On the surface, the agile SDLC of Figure 1 looks very much like a traditional SDLC, but when you dive deeper you quickly discover that this isn’t the case. Because the agile SDLC is highly collaborative, iterative, and incremental the roles which people take are much more robust than on traditional projects. In the traditional world a business analyst created a requirements model that is handed off to an architect who creates design models that are handed off to a coder who writes programs which are handed off to a tester and so on. On an agile project, developers work closely with their stakeholders to understand their needs, they pair together to implement and test their solution, and the solution is shown to the stakeholder for quick feedback. Instead of specialists handing artifacts to one another, and thereby injecting defects at every step along the way, agile developers are generalizing specialists with full lifecycle skills. More importantly, from a user experience point of view, they take a very different approach to modeling and testing than traditionalists do.

2. User Experience (UEX) Activities

Usability is a quality attribute of a system which encompasses learnability, efficiency, memorability, error recovery, and end-user satisfaction (Neilson 1994). User-centered design, also known as UCD although I will use that abbreviation for usage-centered design, is a highly structured, product development process where the focus is on understanding the needs and goals of the user of the product. Interaction Design (ID) is a methodology described by Alan Cooper where the goal is to provide end users with functions that are both desirable and useful. In ID, interaction designers focus on what’s desirable, engineers on what they’re capable of building, and business stakeholders on what’s viable I use the term user experience (UEX) to encompass all of these concepts – although there is good reason to distinguish between the various ideas, that isn’t relevant for my current discussion.

An important question to ask is why should agile practitioners consider UEX important? Jeff Patton believes that UEX addresses several issues which are critical to the success of ASD teams:

• UEX places emphasis on the usage necessary for roles to meet their goals.
• UEX helps meet the goal of identifying the behavior the software should have.
• UEX practices can be applied with varying degrees of formality, thereby making them compatible with agile methodologies.

Other important terminology which I use in this article includes:

• System. The product, which often includes software, under development.
• User. Also known as an end user, a user is a person who will actually work with the system/product being built.
• Developer. An IT professional involved with the creation of the system.
• Stakeholder. A stakeholder is anyone who has a stake in the creation or operation of the system. This includes people who are a direct user, indirect user, manager of users, senior manager, developer, operations staff member, support (help desk) staff member, developers working on other systems that integrate or interact with the one under development, or maintenance professionals potentially affected by the development and/or deployment of a software project. Some agile methodologies, XP in particular, uses the term “customer”.
• Acceptance testing. A testing technique, the goal of which is to determine whether a system satisfies its acceptance criteria and to enable the stakeholder(s) to determine whether to accept the system
• Usability testing. A method by which users of a system are asked to perform certain tasks in an effort to measure the system’s ease-of-use, task time, and the user’s perception of the experience. Usability testing can be both formal and informal, using dedicated rooms and equipment to simply using physical mock ups of the system.
• User testing. Testing activities, including both acceptance and usability testing, where stakeholders are actively involved.

3. Current State of the Art

First the good news. I believe that there is a growing recognition within both the agile and UEX communities that they can benefit by working closely with the other. Within the agile community Larry Constantine’s UCD work is well respected and the UEX community seems intrigued by the promises of ASD. There is an active Agile Usability mailing list where ASD and UEX practitioners interact regularly. There are agile usability tutorials at conferences, including both UPA 2005 and Agile 2005 recently. There seems to be a will to bring the two communities together.
Now for the bad news. There are several challenges which need to be overcome if we’re to work together effectively, and just the fact that we talk about two different communities indicates that we have a problem. These challenges include:

• Different goals. Software engineers focus on the technical design, implementation, and maintenance of software system. UEX practitioners focus on developing systems so end-users can use them effectively. Unfortunately each group seems to all-but-ignore the issues addressed by the other.
• Different approaches. UEX methodologies are centered on the user whereas agile methodologies take a broader view and focus on the stakeholder. With UEX methods one tries to get a holistic view of the user needs and comes up with an overall plan for the user interface before starting implementation. Agile methods favor little up front design and instead focus on delivering working software early.
• Organizational challenges. The agile community follows a highly collaborative and fluid organizational strategy where teams are self organizing. This doesn’t appear to always be the case with the centralized UEX groups within some organizations. While a center for UEX is important to provide the needed practices, tools, and standards, a strong organizational and management hierarchy can be problematic.
• Process impedance mismatch. The agile community forgoes detailed modeling up early in the project, something they refer to as “Big Design Up Front (BDUF)”. Many within the UEX community prefer more comprehensive modeling early in the project to design the user interaction “properly” before construction begins.
• UEX practitioners struggle to be heard. Although this is true within traditional teams as well, my experience is that this isn’t as problematic with agile teams for the simple reason that agile practitioners favor high levels of collaboration. Jokela and Abrahamsson (2004) believe that UEX practitioners often complain that the results of their work are not considered in the design decisions. They also point out that no UEX practitioners were invited to participate in the formation of the Agile Alliance, which may be why there has been insufficient UEX influence to date within the ASD community.
• Our thought leaders may be a bit too extreme. This was exhibited in the discussion between Kent Beck and Alan Cooper, the founders of Extreme Programming (XP) and Interaction Design (ID) respectively. Many interesting points came out of the discussion pertaining to the differences between the agile and UEX philosophies, summarized in Table 1. Unfortunately, both Beck and Cooper seem to be at the extreme end of the discussion, and you can see in the interview there were bones of contention that weren’t resolved.

Comparing agile and UEX philosophies

Agile Philosophies

• Asks “How can what we have now be improved this iteration?”
• You should work closely with your stakeholders/customers to identify their exact needs.
• Details behind requirements can be identified on a just-in-time (JIT) basis during development.
• Detailed, up-front modeling is a risky endeavor at best.
• Interaction design has a role to play from the beginning of a project, as a way to come up with the metaphors for the project.

UEX Philosophies

• Asks “What is the ideal system?”
• Defining the behavior of software-based products and services is very difficult and it has to be done from the point of view of understanding and visualizing the behavior of complex systems, not the construction of complex systems.
• All behavioral issues need to be addressed before construction begins.

4. Addressing a Few Misconceptions

To help promote effective collaboration between the two communities we need to clear up a few misconceptions that each community may have with the other. There are several that UEX practitioners may have about the agile community:

• Agilists don’t model. The actual fact is that agile practitioners do in fact model, it’s just that they discourage extensive up-front design work in favor of more agile approaches to modeling.
• Agilists are continually deploying software into production. Although some teams do this, it’s not the norm. What is common is to deliver working software on a regular basis, perhaps every few weeks, into an internal environment for system and user testing. Deployment into production may occur every six-to-twelve months, if not longer, based on need and the ability of our end users to accept new releases.
• XP is the only game in town. This is a serious misunderstanding because UEX practitioners who believe this miss agile methods such as Scrum, Agile Modeling, MSF for Agile, and DSDM which are arguably more attuned to their philosophies.
• There is no role for UEX practitioners. Many agile methods forgo the concept of specific roles in favor of more generic roles such as developer/programming, coach/leader, and customer/stakeholder.
• Agilists aren’t specialists. This is partly true because agilists prefer to be “generalizing specialists”.
• User interfaces shouldn’t be refactored. Many people fear refactoring the user interface, often because they believe the UEX issues will be forgotten or that end users will not be able to deal with continual change. The reality is that UI refactoring results in the slow but safe evolution of the UI, thereby improving its design. To ensure that UEX issues aren’t forgotten, people with UEX skills should be involved with the development and evolution of the UI. Yes, the UI changes, hopefully for the better, but the only people affected by the changes on a continual basis are those actively involved in user testing. And when you stop to think about it, shouldn’t developers act on the findings of usability testing efforts and thereby improve the UI?

The agile community equally suffers from debilitating misperceptions about the UEX community:

• All you need is a good set of UI guidelines. That’s a good start, but there is a fair bit more to UEX than creating consistent UIs.
• Working closely with stakeholders is good enough. That’s also a good start, but Jokela and Abrahamsson (2004) found that even a close and frequent co-operation between developers and stakeholders does not ensure good usability at all.
• UEX is just about UI design. UI design is clearly a part of UEX, but so is understanding how your users will work with your system and what their goals for using the system are so that you can build something that is usable by them. This requires significant modeling and collaboration skills to accomplish.
• UEX relies on comprehensive up-front modeling. Although some people (Cooper 2004) in the UEX community want you to believe that, many others believe different. In many ways getting the UI right is similar to getting your architecture right, it often requires some up front thought although that doesn’t imply that you need to take a serial approach to development.

(Part I ends. To be contined on Part II)

Possible Related Articles:

• A Visual Tool for Brand Personality Development
• 2009 Mobile Trends - (Part Two)
• 2009 Mobile Trends - (Part One)
• Of Mice and iPods, or The Death of the Designer
• Culture in the Further Development of Universal Design
• Adopting the Universal Design Approach Instead of the Stigma That Creates Poorly Accessible Enviroments
• Universal Design – The Time is Now
• Is Universal Design Really Universal?
• The Concept of Universal Design
• Five Rules for Communication between Machines and People