Want to integrate Agile & UX intentionally? Start with these reads.
I’m a designer with a traditional agency background. Two years ago, I switched to working in product development and agile environments. Why? To find a bridge between design and agile.
I’ve worked for clients worldwide elevating their user experience and research strategy for over six years in English and Japanese. I recently joined yamaneco, an agile/UX coaching consultancy in Tokyo that helps integrate agile and design in teams. We work with teams of all skill levels to build unique, sustainable, and customized solutions for our clients.
When I first encountered agile as a designer, I was skeptical. I heard whispers of agile in agency, but it was always paired with the image of a lack of innovation and respect for design. I did what any good skeptic would do — put away my assumptions for a moment and tried to understand the topic. I buried myself in a collection of books and articles on design and agile. I talked to our engineers, designers and managers. Through this I learned two important things:
- Agile and design thinking were made to serve two different needs.
Agile and design, on the surface level share many similarities. However, they were both made to solve different problems—one, to make a production process more flexible and people-centric, another, to make the creative process clear and communicable in business. For over fifty years they grew their own separate mindsets, separate processes and separate languages.
Though there are similarities, they are at war. Agile is an enemy of design specs, claiming they are too detailed for a quick iterative process, and designers are anti-sprint, claiming they are arbitrary deadlines that harm rather than help productivity and quality.
- Hybrid solutions address merging processes, but not mindsets.
Hybrid solutions such as design sprints or Lean UX have gained traction and want to merge the best of design and engineering. But there is still turnover in agile product teams with designers. “Even though we’re doing design sprints in our team, there’s still a high turnover,” said one manager I spoke with, “[designers] just don’t want to stay.”
What makes design agencies praise the benefits of design thinking but not use agile regularly? And why can’t some agile teams keep their designers? It is a problem of mindset. Processes can be integrated and tracked easily, but mindset shift takes time and heart from the entire team, leadership included.
The best way to find a solution is to first understand the problem. These are the best reads to start when intentionally integrating agile and design.
1. Outcomes Over Output, Josh Seiden
In Josh Seiden’s easy-to-digest book, he outlines the differences between output (the things you make) and outcomes (the behavior you change) in terms of planning, running and evaluating projects. In it, he asks the magic words of how to visualize outcomes, which are, “what are the customer behaviors we want to change, and how do we measure these?”
A principle of agile is “working software over comprehensive documentation.” This was initially made to prevent over-documentation but an unintended consequence of this is the focus on “working software.” Do you want your team to be known for the amount of features they output, or the behaviors they impact in customers and the business?
Reading this is a great way to understand the common pitfalls teams of all types fall into when it comes to measuring success. It reframes the conversation from what features do our customers want? to how would we like our customer’s behavior to change?
2. How to Make Sense of Any Mess, Abby Covert
How to Make Sense of Any Mess should be required reading for anyone in tech. It takes the process of solving problems and breaks it down with simple, neutral language that is accessible for everyone.
It’s not uncommon for designers and engineers to be using the same words but interpreting these words so differently one cannot understand the other. The question, “is this the final design?” is an excellent example of this.
From a design standpoint, it is interpreted as, “is the design done?” which, as most designers know, the design is never done. From an engineering standpoint it is seen as, “is this design going to change?” A better question is “how might this design evolve over time?” This is something both engineers and designers want to know, even if it is not easy to answer.
Reading this enables you and your team to be intentional about the words you use and what their meaning is, both real and implied. It allows you to choose what kinds of words you like to see used within your team and understand how intent is communicated.
3. Working with Design Thinking, Lean and Agile, Amanda Stockwell
Amanda Stockwell’s article succinctly summarizes design thinking, lean UX and agile mindsets. She outlines out how each of these types of thinking was developed to solve a different problem, and gives some basic principles on guiding your team towards a shared understanding.
Rather than having set principles for team integration, all teams have their own individual ecosystem that requires different approaches. For example, trying to tell a typical agile team to throw away sprint reviews for pin-ups, show and tells or whiteboarding sessions doesn’t work unless you’re understanding the innate value the team gets out of the sprint reviews and find a solution that works for all members, regardless of what the vocabulary is.
Being able to adapt to changing requirements is a hallmark of all Agile teams and changes in process are a part of this. I can see Stockwell’s article starting to break the mold of “designers do this, and engineers do this,” and reframe the ideas as principles everyone can adopt.
4. 5 Rules for Integrating UX with Agile and Scrum, Jeff Gothelf
Jeff Gothelf’s article also contains guiding principles, more specific to product managers and leadership. These are principles, that, if supported by leadership and the teams, can facilitate organization-wide change.
The closest concept I have seen in agile is working agreements, authored and shared by the team on how they will work together. Something similar exists in design agencies like frog and IDEO as well. Typically, it is usually undertaken at the start of a phase, but having continual updates and refreshes as the team evolves is far more important than simply at the outset.
Breaking out of “how we usually do it” is the key. If the process continues as always, so will the mindset. A team could be design-led and agile, but if they are not prioritizing time with the customer or outcomes in the backlog, then they run the risk of becoming a feature shop.
5. Working as a cross-functional team, Sjoerd Nijland
In his short article, one of many defining some case studies around integrating Lean UX with Scrum, Sjoerd Nijland gives us a snapshot of what a cross-functional team might look like. Though it is just a snapshot, you can see him using his own version of Gothelf’s principles in an actual team to deliver business value. To talk about principles in theory is different from how they work in a living, breathing team. His series of articles on UX and scrum are great, real-world examples of how he is putting them to work.
Using his case studies as a starting point, your team can try their own set of experiments. Start small, and measure your success.
In conclusion
In the coaching I’ve done, integrated teams seem to fit into one of two categories: a team with an agile base and optional design flavor, or a team with a design base and optional agile flavor. I’m starting to realize that both sides are not optional. They’re integral to forming a team that delivers usable, feasible and sustainable products through a highly iterative process.
As a design team, you can adopt sprint reviews and backlog refinement, but if you don’t also have a blend of the agile mindset, you will only be performing agile, but not being agile.
And as an agile team, you can adopt prototyping and user testing, but if you also don’t have a blend of the design mindset, you will only be performing user centric design, but not being user centric.
Crossing this mindset bridge takes a lot of thought and intention. I use the word intention because a true mindset shift takes a great deal of thoughtfulness on where you are, humbleness to admit what is wrong, and curiosity to explore outside your comfort zone. These five reads are just a seed that I hope grows larger within our slowly converging community. I hope these help inspire you as well in your own mindset shift to building intentionally integrated teams.
