Based on the belief that a final product evolves through quick and multiple iterations (“sprints”), diverse organizations are increasingly applying Agile development to small and large projects. The content of each short iteration is not decided until a planning meeting held just before the iteration starts. At that time, new requirements can be added and requirements can be swapped out for others with higher priority. This approach enables teams to respond quickly to customers by adjusting the content through incremental, collaborative, and iterative work.
With Agile, there are unique opportunities (such as more collaboration) and unique challenges (such as short cycle time). How the Agile team reacts to the opportunities and challenges will affect how the team works together in a positive or negative way, which impacts product delivery. Similarly, the UX professional working on an Agile team also needs to “get Agile,” or practice Agile UX.
A workshop at UPA 2009 continued previous discussions at both UPA and CHI on Agile and user-centered design. Workshop participants exchanged best practices, success factors, challenges, and solutions. They ultimately arrived at benefits of Agile for user experience professionals.
Best Practices
Best practices include the following:
- Working on the framework in Sprint Zero
- Parallel tracks in design and development
- Rapid Iterative Testing and Evaluation (RITE) method
- 100 percent UX commitment in an Agile project
- User contact plan
- More collaboration and synchronization, fewer documents
Success Factors
Success factors include the following:
- Clear UX vision/goal
- Positive pre-Agile relationships
- Understanding of UCD/UX
- Understanding of Agile process
- Strong Agile coach or champion on
the team - Willingness to change
| Best Practices | What Is It? | Solving Issues |
|---|---|---|
| Sprint zero | Short pre-coding sprint to define product vision, set overall goals, roughly plan out future sprints, define design principles, clarify team members’ roles and communication methods. This sprint is also critical for some basic UX work before production coding gets underway. |
– Feeling that there is no “big picture” – Unclear priorities, or working on wrong stuff first – Doing unnecessary work that is not used – No time for upfront design work |
| Parallel tracks | – Fitting design into Agile cycles – Confusion about design deliverables – Getting design work completed on time – Validating implemented designs |
|
| RITE method | RITE differs from a traditional usability test by emphasizing extremely rapid changes and verification of the effectiveness of these changes. The goals of the RITE method are to identify and fix as many issues as possible and to verify the effectiveness of these fixes in the shortest possible time. | – No time for design iterations – Fewer usability tests – Not enough time to validate solutions |
| UX 100 percent commitment |
UX practitioner is a full time member of a single Agile team and not assigned to multiple products. Paired design (more than one UX member), like paired programming, is also starting to become more common. | – Burn out – Not enough time to design – Feeling out of the loop, missing crucial information |
| User contact plan | Create an upfront communication channel with end users (and end user proxies if applicable) to provide a steady supply of feedback. | – Not being able to find end-users fast enough – Not getting feedback early in the process – Relying on Beta users – Designs not being validated |
| More collaboration, fewer documents | Frequent updates on your designs and the design process. Continuing communication during implementation and testing. Some teams use the prototypes as the UI specification and make sure it is available to the whole team. | – Misunderstood designs – Design “drift” during implementation – Agile team not understanding UX activities |
Defining a clear user experience vision and design goal is critical for the design to be successful. How do you expect end users to use the product in the next five years? How does the product fit into end user’s life? The UX vision and product vision need to be aligned. Design principles are defined based on UX vision and can guide the team to create and evaluate designs. This is an area where the UX professional can take a leading role.
A positive relationship among team members before the Agile process starts contributes to the team success. Agile cannot fix a dysfunctional development team. Furthermore, the UCD/UX professionals have the responsibility to help the team understand how user research, design, and testing can contribute to the product success. For the UX team in particular, understanding how many of the discount UX methods can easily be adapted to the process is important. Realistically, you won’t have six months to do user research up front—it likely will have changed by then, and the release probably will be out the door before you finish. However, you can and should do user research and evaluations early and often.
One of the things that made a significant positive difference for many of the teams was training in the Agile process and the ongoing presence of an Agile coach or mentor. Agile is a new way of working for many folks that does not come easily or naturally. An Agile coach is someone who might conduct the initial Agile training or who might act as a ScrumMaster during the sprints. Their responsibility is to ramp up the team so they can really practice Agile in the shortest time possible. Having the entire team on the same page in terms of the processes, language, and expectations will make this much easier. Having the Agile coach part of the team or on call in an ongoing manner will help the team get out of any ruts that may occur. Having a strong Agile champion on the team (for example, a senior developer) can also help move the team forward.
The team will gel when the roles and responsibilities are clearly defined, collaboration methods are well understood, and team members open their mind to change how they used to work before.
Challenges
The waterfall method (a sequential, linear development process) has deep roots in most organizations and has been practiced for many years. One of the biggest downsides of the waterfall method is that it makes changes in requirements difficult if not impossible. Agile, on the other hand, makes it easy to incorporate changing requirements at each new sprint. But Agile is still relatively new, and it requires time for organizations to understand it and make it work. Teams also need time to gel. Based on the experience of workshop participants, it takes six to twelve months for the process to work. However, once teams make the process work, nobody is willing to go back to the waterfall method.
When Agile is not officially adopted by the organization, there may be no executive support. This can lead to only partial adoption of Agile. For example, the developers are Agile where quality assurance is not. This makes it particularly challenging for these teams to succeed since the Agile process requires that all participants buy into the concept. Fixed dates and feature lists mixed into the Agile process will cancel the benefits that Agile offers.
Some organizations do not fully implement the Agile process. Symptoms here include no daily meetings, no cycle planning, no changes allowed, long cycles, features are not done at the end of cycle, and others. Another challenge is a by-the-book strict Agile process without considering the organization’s specific needs. For example, in complex domains such as the financial industry, more detailed documentation is necessary to help the team understand terminologies and functions needed to support user stories. Oversimplifying the requirements may result in functions that deviate from requirements derived from user stories.
Applying the Agile method to new system versus legacy system development has different challenges. When working on legacy systems, there are many interconnected systems and history that cannot be changed easily. The Agile team may not have the influence on other teams that support systems closely connected to the system being changed.
To UCD and UX professionals, the biggest challenges are when to conduct user research, how to make user research Agile, and to have enough time to do quality design. If the product team thinks that Agile is about speed, they sometimes complain that “usability slows us down.”
Sample Solutions
Based on the above challenges collected from the group, workshop participants brainstormed successful solutions. Here are a few examples:
1.Virtual Team Room with Online Cards
Challenge: Distributed resources (multiple team members, multiple projects, multiple geographies)
Solution: Set up a virtual team room with online cards representing stories in the backlog. This online backlog helps story prioritization and sprint planning. All the story metadata are also tracked in this log. The reality is that distributed teams may have to work harder to communicate and the collaboration may have to be a bit more formal and documented.
2.Warm Handoffs
Challenge: Not enough time to write UI
specifications. Implementation may deviate from the designs.
Solution: When handing off the design to development, don’t just hand over the document. Instead, post the document where the team can access it, and have a meeting to discuss it with the team, keeping the communication channel open at all times. It’s important to help developers understand the designs and support them. Staying in touch allows you to detect any possible design drift during implementation and to supplement the information, such as error message designs, during development. Some UX professionals walk around regularly to see how things are being implemented.
3.The “Little Things” Card
Challenge: Design flaws and desired improvements are noticed during implementation but there is no time to fix them during the sprint. Or, they are so little that they are not really considered a feature.
Solution: Don’t panic if there is an inconsistency when the product is released. Record the problems and desired improvements on the “Little Things” cards, also called UI change log, UI debt, or even UI placeholder. Create a new feature (that combines all these little items) in the next sprint to address these issues.
[greybox]
Agile Manifesto
In 2001, seventeen prominent software development thought leaders came together at the Snowbird Ski Resort in Utah to discuss their methodologies. They created the Agile Software Development Manifesto, and accompanying Twelve Agile principles.
Manifesto for Agile Software Development
We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
[/greybox]
How UCD Contributes to Agile Success
The UX team can play a huge role in making an Agile project a successful one. One of the items of the Agile Manifesto (see sidebar) is to deliver a product that will satisfy the customer. UX professionals have a lot of experience to contribute in this area.
Translate your UX terms and techniques into agile terms and techniques. Assimilate these into the Agile process. Just like changes before—from mainframe to workstation to web to mobile—it’s still about user experience. Our overall goals and processes haven’t changed. Fundamentally, many of the same issues we faced with waterfall are some of the same challenges we face with Agile.
Start small, prototype more, continue testing. There’s been a push for years in our profession to move more to the front of the development cycle and do more iterative prototyping and evaluation. Here’s your chance! Do more paper prototypes, more wireframes, and more mockups. Test them and don’t be afraid to iterate and test again.
Sprint Zero. Focus on the who, the what, and the what will be. Design ahead. Validate the current. Test what has been completed. Set up a user contact plan. Line up users to participate. Schedule evaluations on a regular basis and test whatever is ready at the time. Skimping or skipping here will have big impact later.
Work across organizational boundaries. Work with product management, product marketing, and anyone else who might have something to offer. Share research across teams. Re-use and build on previous user research if you can. After all, sprints are short and we don’t have time to do it all.
What UX Gains from Agile
While all of this may seem a bit daunting, there are some real benefits that a UX professional gains from working on an Agile team.
- More influence, more ability to affect change in the product quickly. The process, by its very nature, works by each sprint looking at what needs to happen next and re-evaluating/re-prioritizing the requirements. Instead of waiting one to two years for the next release, the items that we really need to add or fix get into the cycles quickly. So, more of our designs get into the product quickly and there is less wasted UX time.
- Increased likelihood of delivering the solution a customer wants. Because the most important features are done first, and because they are delivered in each cycle as working code, you have time to evaluate them with users and validate that you are indeed meeting their needs. If not, you can move quickly to alter direction and fix it. User input has a direct and immediate effect on the current release.
- Better integration into the project team. If you are a core part of the team and participate in the daily Scrums, you contribute and find out about things more quickly.
[greybox]
12 Principles of Agile Software
We follow these principles:
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
- Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
- Business people and developers must work together daily throughout the project.
- Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
- Working software is the primary measure of progress.
- Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
- Continuous attention to technical excellence and good design enhances agility.
- Simplicity—the art of maximizing the amount of work not done—is essential.
- The best architectures, requirements, and designs emerge from self-organizing teams.
- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
[/greybox]
Final Summary and Parting Words
Before you go running out excited to get started with Agile UX, remember, none of this comes quickly. In general, the teams represented say it takes around six to twelve months for the teams and the processes used to gel and be comfortable and productive. The good news here is that once you have had this positive experience, no one wants to go back to their previous methods. The other good news is that you don’t have to do it alone—there are many of us out here working to build an Agile UX community who are happy to share both the good and the bad.
