What Agile with UX Is Not
- Agile is not a methodology; it’s a concept
- Agile is not an excuse to produce less documentation; it’s an excuse to produce relevant documentation
- Agile is not a method where any one discipline rules; it requires collaboration
- Agile is not a solution to waterfall; it’s a different tool
- Agile is not a system where everyone rushes in at once, but overlap can happen when appropriate
- Agile is not viable if there is not buy-in from the top-down
If you haven’t already, I recommend reading the Manifesto for Agile Software Development. It’s worth reading through the “Twelve Principles of Agile Software,” instead of just stopping at the first page.
Make no mistake. UX design in agile is difficult. It’s hard because Agile is hard to begin with. Agile requires self-discipline among each team. The larger the team, the more challenging self-discipline becomes. It requires motivation and commitment to doing the right things for the customer. And it will be as long as people think of them as separate concepts, competing for attention.
(Later I’ll add some diagrams showing the similarity of Agile/Scrum diagrams to the Boehm Spiral model & UX diagrams)
UX & Agile are incredibly similar, as an overall approach. This may very well be the first hurdle for many designers to get over. The comfortable “phase,” previously enjoyed by the experience subject matter experts is removed and suddenly everyone has a say in what the experience looks like. While anathema to some experience designers, this is a dream come true for others. After all, this is what we try to do to architect a truly brilliant experience: collaborative discussion and design with all of the disciplines involved in the development of the software or site. This encourages buy-in from the ground level and increases the likelihood of technical feasibility, from the start.
I’m just going to come right out and say it. Successfully working in Agile requires intelligent, committed, motivated, hard-working people. Everyone on the team needs to exemplify these values and an Agile team is truly only as strong as its weakest member. That’s not to say you need to start kicking people off the team; but everyone on the team has to have both the acumen to see when someone needs guidance and the humility to accept guidance when it’s offered to them.
As UX designers, we need to be guiding hands, not dictators, within Agile. Everyone has good ideas on the team. Our role is to inspire that conversation to take place in a way that produces results and positive outcomes. Be a culture ambassador and instill a willingness to participate in your team. Place value in every suggestion made by every team member, despite how wonky you may think it is. When you work with everyone and step through ideas, you sometimes define solutions that you were previously blind to.
You are not in a silo. You have to work with your developers, your engineers, your content strategists, your vidual designers. They’re all important to your process.
The bane of the development profession. Doing it over. The first thing to destroy morale and dishearten the team. Re-work is probably pushed back on harder than any other concept in Agile.
As part of our ambassador role, UX needs to encourage re-work. This is our team’s opportunity to reinvent. There’s no reason to be discouraged based on “whims” of stakeholders. The reason for the stakeholders’ feedback loop is to identify things that may have escaped us during the design and development cycles. Own the mistakes and own the re-work. Every mistake is a chance to learn and do it better the next time. As an experience designer, our work is never truly done. The world changes, people adapt, their models change. Agile allows us to instill this mindset to the rest of our team.
UX in Agile does not mean “fly by the seat of your pants.” We’re still beholden to backing up our decisions with research and data, and, where possible, moderated interviews. We still need to apply the knowledge we have and create elegant, simple, effective solutions for users based on their needs.
Metrics are all-important; real metrics. Understanding what’s been done and, more importantly, watching for what needs to be done. Coupled with customer feedback, you can gain valuable insight into your users’ behavior. These things allow you to identify the top issues that need to be solved on a regular basis.
Key to this is not trying to solve for the 1% first because it looks like a quick win. The low-hanging fruit is the most tempting one, but not always the one that will provide the best end result for your users. By definition, if you solve for the 1%, you risk screwing up the remaining 99%. Don’t take a quick win at 1% when the 3, 5 and 7% are still unsolved.
UX in Agile does not mean throw deliverables out the window. It means be smarter about deliverables. Call it lean, call it what you want, but the point is not to reduce deliverables, as much as it is to reduce unnecessary deliverables. A project may very well require exploratory sketching, personas, wireframes, patterns, storyboards, and prototyping. Define your deliverable types and define a common language to work from. This way the type of deliverable your provide isn’t a surprise to your teammates or your stakeholders.
Don’t marry yourself to your deliverables. Go fast, go hard, and be willing to change and adapt. Don’t become so obsessed with the pixel-perfection inherent in your deliverable and the level of aesthetics involved with it that you become disappointed every time you have to change it. Don’t polish details, unless it’s appropriate to the deliverable. Don’t obsess over the little things when they aren’t appropriate. Separate your deliverables so you don’t have a cascade effect when you have to make changes. Interactions, content, layout, can all be represented in different documents, allowing you to provide the level of detail appropriate to the type of deliverable only within that deliverable.
Reviews & Demos
Regularly scheduled reviews are the perfect time for presenting prototypes. UX should present UX deliverables the same way the developers would present code, or visual designers would present comps. Present them on paper, present them as wires, as PDFs, interactive prototypes. You’ll be able to determine what resonates best with your stakeholders and they will truly understand the value in architecting the experience. Regular exposure to UX deliverables helps reassure the stakeholders of your organization that you are on the right track. You also have the added bonus of having the entire team chime in on the experience presentation, when it’s designed collaboratively. That kind of enthusiasm for work is infectious.
Wrong. No. It’s not true. Square pegs, round holes and all that stuff.
Don’t get your head wrapped around any particular solution as the holy grail of design and development in Agile with UX. The point is flexibility. What makes sense for low risk features does not make sense for brand new, out of the box solutions. Your team, and your organization will have to adapt to what makes the most sense. This may even include adopting a different methodology altogether if the one you’re working with doesn’t make sense for your team’s dynamics.
Going back to the level of intelligence involved in designing UX with Agile, be smart. Be smart. Be smart. Be smart. Make intelligent decisions on how you do things. Review what you’re doing in a cycle as regular as your demonstrations to stakeholders. Fix the things that aren’t working and cultivate efficiency out of the things that are working.
What Agile with UX is
- A concept promoting iterative change, cultivating a better experience
- A chance to work more efficiently, focusing on appropriate documentation
- A platform for truly collaborative design sessions, involving the whole team
- A different tool to build with, allowing you to approach problems from a different vantage
- A chance to get it right; rapid iteration allows you to make mistakes and learn from them
- An opportunity to instill the culture of designing for the user into the organization