Agile Development Processes: An Interview with Jeff Patton

Since working on an X(treme) P(rogramming) team in 2000, Jeff Patton has been heavily involved in agile methods. In particular Jeff has focused on the application of user centered design techniques on agile projects, resulting in leaner, more collaborative forms of traditional UCD practices. We recently sat down with Jeff to discuss how agile development processes can work with and enhance user experience design.

When it comes to experience with Agile Development, our clients are all over the map. For development teams just getting started, can you explain how Agile Development processes differ from what they may be used to?

In Agile development there’s a big emphasis on development, getting ideas cast into working code and validated. Development teams new to Agile development may first notice the shortening of the cycle time, the cycle that starts with an idea and ends with a finished product. In a typical software development lifecycle, this may take months. In an Agile lifecycle, the goal is usually a couple weeks.

To shorten the lifecycle, work is generally broken up into lots of little chunks and moved through a cycle of design, development, and validation much faster. This shorter and faster lifecycle results in all sorts of process changes. People sit closer together in cross functional teams, they use lighter-weight ways to describe and document requirements, and they employ automated testing to shorten the cost of adding to and changing the software.

What are the benefits of moving over to an Agile Process?

Agile Processes lead to happier people and reduced cycle times. Development teams engaged in Agile approaches generally work more collaboratively and see the software they are designing and building delivered at a higher frequency.

More frequent feedback and delivery cycles also results in quicker course corrections which can reduce project risk and increase the rate of return on software development. For a business stakeholder, there are strictly financial reasons for the move to Agile processes.

An Agile Process also substantially reduces software development risk. It’s characterized by rapid response to change or rapid course correction. Agile achieves this quality by reducing cycle times. Agile development alleviates the risk of delivering products very late or not at all. It also prevents a development team from redelivering functionality that isn’t useful to its target users and then not being able to change course fast enough to allow the product to succeed.

If an organization switches to an Agile Process, what types of changes would the User Experience team members need to make to their practices?

Agile development often substantially changes the way the team works. With reduced cycle times, UX members have less time to forward work to the developers and less time to evaluate the product. This means instead of designing and validating a full solution before sending it forward to development, the UX team may only design and validate just a bit—or design some and only validate the most risky aspects of the design before development.

Alias, a company who makes graphics and video editing software, is a great example of doing this well. They’ve taken a very rigorous user experience process and shortened their cycle time to 2 weeks. In a single two-week period, the UX team composed of 3 interaction designers and a couple of prototypers, will design and validate the work for the next 2 week iteration, support the ongoing development by working with developers directly, and run usability tests on features developed during the last two week cycle. Things move fast for these teams.

Although Alias works using a 2 week timeboxed iteration, strictly speaking Alias’ end to end cycle time is 6 weeks: 2 weeks designing for a future iteration, 2 weeks writing software, and 2 weeks validating a previous iteration. But, since their team is overlapping all three activities in each 2 week iteration, it keeps tested functionality flowing out every two weeks—and keeps the entire team’s adrenaline pretty high.

You talk about teams validating their work before moving forward. What does it mean to validate in this way?

Agile development is characterized by lots of recursive cycles—each cycle having its own little bit of design, building, and validation. The smallest cycle is the development of a single product feature. Validation for a feature might mean automated unit tests on code modules, automated functional tests that validate functionality, and visual inspection of that feature.

At the end of a typical two-week iteration, validation would be the cumulative sum of all those automated unit and acceptance tests, plus automated tests that validate the integration of all the features built during the iteration of development. It’s also common to perform manual review and testing of the features built during each iteration.

During a cycle, usability professionals will validate that the product built is usable. Organizations with strong usability practices will typically place usability testing inside the validation stage of each cycle. For example, in a two-week development cycle, they may conduct a quick heuristic evaluation plus lightweight usability testing. However, for a product release, the team would conduct more rigorous usability testing.

Alias, the company I mentioned earlier, does a lot of ad hoc inspection of features being developed during an iteration, and more formal usability testing using recruited test subjects during the following iteration.

Agile approaches suggest a framework where the development team incorporates techniques when they are most appropriate. An Agile approach may make room for a validation step, but not explicitly recommend validating usability. I’ve seen organizations that have a blind spot towards usability practices before Agile adoption often still have that blind spot after Agile adoption. However, since they see their software working and running more often, it makes poorly designed software harder to hide.

Many traditional usability techniques take weeks to accomplish. How does this work within the smaller iterations of an agile process?

The trick here is to avoid “waterfall-head,” serializing events so that other work can’t proceed until team members have completed the traditional usability techniques.

For example, let’s say the UX team is conducting some research that will take a month of interviews. However, after a short amount of research, they have some general ideas about what the product solution might be. At that point, they should give some guidance to the development team about what they should build.

In an agile world, teams are allowed to be wrong and quickly change their course. Alias again is a great example. When creating the Sketchbook product, they wanted to pursue several weeks of startup activities. However, the development team couldn’t just sit by and wait. The UX team had a general idea of what they thought the application might look like and they were pretty sure they needed one big feature—importing and exporting Adobe PhotoShop files. As a result, they set the development team to work on those items where the risk was low that they would reverse these design decisions.

Many flavors of Agile development recommend you have a “customer” representative on the team. Is this a real customer or someone pretending to represent the customer? Is this a good role for a UX designer to play? If not, how does the ux/usability practitioner work alongside this person?

The customer is a challenging role. The Customer represents the people who are buying and using the product. Unfortunately, these often aren’t the same people. In addition to representing the interests of all of these people, the customer role is responsible for articulating requirements to development and being available regularly for close collaboration as the development team renders these requirements into working code.

The customer is then responsible for validating that the software is what they had intended it to be. It’s a huge responsibility and pulling an actual customer away from their work is often a bad idea. The customer role in product development of any reasonable size is usually filled by a group of people working together.

I’ve seen environments where a UX team fills a customer role very effectively. I’ve seen environments where a UX team functions in partnership with business analysts under a product manager—all of these folks working together to fill the role of an agile customer. If you’re a UX person, you’re an agile customer.

Are there some techniques adopted for Agile Development that would benefit UX team members who are still in more traditional development environments?

Agile Development reminds us of a lot of the techniques we know work well but may have forgotten to use. When a development team is in a crunch to get a project done, they may meet and talk more frequently. Or better yet, they may gather together to work in a war room. Agile development uses things like daily standup meetings for the whole team to keep everyone on the same page to keep collaboration high. These are ideas that have always worked but teams forget about them until things are tense.

When I’m teaching Agile processes to development teams, I immerse them in an Agile lifecycle, asking them to plan for a short iteration of work, and to reflect on their process and make adjustments. In a very short iteration, they are forced to plan, execute, evaluate their results and make changes to both their product and the process they used to build it. Invariably, development team members find Agile techniques they can take back to their working environment.

Other Agile concepts like keeping formality low are important. I teach paper prototyping and Wizard-of-Oz-style usability testing. While these techniques aren’t new, I’m often surprised by how many usability people forget how valuable these techniques really are. They often design alone in very high fidelity environments waiting weeks before getting any validation from users—even users that aren’t ideal. Short cycle times and frequent validation weren’t ideas invented by Agile development, but sometimes it’s good to have something remind us they are important.