How Do We Do UX With Agile?
How do we do UX with Agile?
Let me propose (humbly) that this may be the wrong question.
Agile, Design Thinking, Kanban Method, DevOps, Lean Startup, and [insert X] are all necessarily incomplete perspectives. Of course, if you squint hard enough they can be applied to anything — but with excess abstraction comes a lack of utility/function. By being incomplete and biased, they’re actually helpful (in context).
Given that perspective, I can almost guarantee that no team is “doing Agile” in isolation. They likely draw from many traditions. The challenge is that engineering is a necessary step to “building” things, and that engineering is commonly known for “doing Agile”. So it feels like everyone needs to learn how to integrate into Agile.
Which naturally breeds resentment. Why do they, the engineers get to pick the way?
At least based on my experience, high (for their context) performing teams don’t think in terms of “doing Agile” or “doing X”. They draw on many, many perspectives at once, and craft a “way” that is highly adapted to their context, people, and (gasp) culture. The approach is holistic, cross-functional, and co-designed — not UX figuring out how to “fit into” Agile, and not the individual functions establishing entirely bounded ways that they execute in isolation.
The question is more like…
How do we deliver value together?
Agile (like any Way) does not have a monopoly on what cross-functional teams do. It is, like many things, a necessarily incomplete perspective. In figuring out how to work, teams engage in sense-making and emergent work co-design … creating a new “way” where none existed before.
So, from the UX perspective, it is far more valuable to engage in the question of “what works” and embark on that journey with your partners, than it is to begrudge Agile and/or worry about how to “fit into” Agile (or waste time trying to kingdom build and carve out a perch on a ledge upstream). Agile bashing doesn’t really help. Correct, Agile doesn’t explicitly discuss the role of design. But, you know, design doesn’t explicitly discuss the role of developers either (outside of the box on the far right that says “build”, “ship”, or “deliver”). This is the nature of Ways.
So get out there, and design a new way of working with your collaborators.
Are they refusing to collaborate?
That’s another problem altogether.