Skip to content
who your customers and users arewhat they needwhat is valuable to themwhat architecture and capabilities will best support their needs
Individuals and interactions over processes and toolsWorking software over comprehensive documentationCustomer collaboration over contract negotiation (ndr.at the time customers were internal customers, business people)Responding to change over following a plan
Reframing Agile to deliver great UX
Agile is used today like it was used 30 years ago. It has usually been framed as the solution to waterfall. Waterfall wasn’t working because it delivered things that weren’t what people needed. Agile tried to solve the problems of waterfall with time boxing. It’s a working process but it’s aimed at helping developers develop, not creating great UX, therefore UXers have always struggled with getting UX into Agile. In Agile there was never UX in the picture.
We can reframe Agile to get to a better place.
Most of Agile today is focused on product delivery. The problem with this framework is that the only dimension of quality is the working code. But working code doesn’t necessarily mean useful code that is valuable to somebody. It just means that the code does what it is supposed to do. This lack of quality beyond that gets us into trouble when we try to move UX into it, because you can have things that do what they have to do but also have a very crappy user experience.
If you look into the early Agile writings, there’s a lot of mentions of the word “value”. But value is also not well defined. The idea of getting some useful is great, but it also has to be something that people will want and will pay for.
We need a better definition of quality, one that actually benefits users, and value.
This comes down to three basic areas: prediction, collaboration and learning. These core aspects resonate well with the original value of Agile, so they should be quite simple things to define. We’re not changing what Agile is, we just zooming out and refocusing to actually see prediction, collaboration and learning working better.
Prediction
The original goal of Agile wasn’t to deliver faster, but to better predict when we’re gonna deliver, counteracting a problem of waterfall that is that everything was late. The idea that if we can predict when we’ll have something and what we’ll have is what people want when they install Agile: being able to set deadlines and hit them. Hitting deadline, as opposed to not hitting them, means that being fast is really a side effect of Agile.
Time boxed sprints help identify how much work you can get done in the sprint. The goal is to get better and better at predicting how much work you can get done in a sprint.
But we need to differentiate outputs from outcomes.
Outputs are what we deliver. We can list and count all the outputs.
An outcome is a change that we want to see in the world. When we have a clear understanding of that change, we can start to measure whether we’re getting that change. When we change the focus from outputs from outcomes, it’s a shift of how we’re able to predict whether we’re getting closer or not.
Collaboration
Agile was always imagined as a collaboration of equals that come together, bring different perspectives and learn from each other in the process. But it’s not as Agile has often been implemented. What’s happened is that teams are put together and then to each team member is given a job, and they don’t collaborate: they work on their thing and pass it to the next person. That is not collaboration, it’s flow. It’s the factory mode.
Instead, we have to spread through the team a pull of skills. We must shift from roles to skills. Everybody on the team needs to be learning how to do all the things. This is very much a challenge, but it’s a key part of Agile that’s missing.
Learning
Agile was always seen as a way for teams to learn new things, but what you need to learn is not well described. You need to learn:
When you focus on outputs you end up completely avoiding learning. When you get into the outcome mode, then your focus is always learning, because you need to learn what’s preventing you from getting closer to the change you want to see in the world.
Reactive and proactive UX
UX has always been a collaborative, iterative process:
This is basically all a sprint is about. So sprints and UX work nicely together. The problem is that over the same period of time (early 2000’s to now) UX has shifted from being an iterative process where we’re always learning about our users, to being very reactive.
We need to shift from reactive UX - the factory setting - to proactive UX.
Reactive UX in Agile focuses to shrinking the whole UX process into a sprint. The effect is that everything feels rushed and incomplete. The best you can do in that scenario is try to build the product right, but you can’t figure out if you have the right solution or even understand the right problem. Teams underinvest in research. UXers focus a lot on solutions instead of reaching a shared understanding of the problem, and then they overcompensate with design and coding, then it doesn’t work and you have to get back into the factory model.
In proactive UX you get to feed into the roadmap, define what you work on. When you do that you get more control over what you’re supposed to accomplish.
UX and Agile work towards the same goal (delivering the best products and services to users). But we want to take Agile from a situation where it doesn’t take into account users needs to a situation where they are front and center, driving the Agile activity. To do that, we also have to reframe UX, changing the focus from outputs to outcomes.
The writers of the Agile manifesto listed out some values:
These values work pretty well. They are very human centred principles. That is great because we can work with that as UXers, but we have lost focus on this: with the framing that Agile is really just about delivering products fast, they all go away. And actually a lot of Agile implementations become very waterfally, with months of sprints already defined by the team leadership, knowing exactly what will be delivered, leaving no space for response or collaboration.
Agile is not the problem, it’s the way we’ve framed it.
Want to print your doc?
This is not the way.
This is not the way.
Try clicking the ··· in the right corner or using a keyboard shortcut (
CtrlP
) instead.