UX in the Scrum Team — Can it become love?
+++++++++++++++ 2020 Update ++++++++++++++++
I’ve published a 2020 update to this article, so feel free to skip this article and read the update:
++++++++++++++++++++++++++++++++++++++++++++
There is no doubt that Scrum is a great framework for agile software development. It gives you the right format and tools to get things done fast and learn from your mistakes as you go.
Without surprise, Scrum is also our process of choice at our office. The problem was that we never really figured out a good way to include UX in the scrum team. Until now!
History Lesson
Back in the ancient days of software development, there was no Scrum. The development happened with a process that is often called „Waterfall“. Basically you can picture it as a straight timeline where you would first take time to write in-depth spec documents that define nearly every detail of the feature/software you are developing. This spec document is then handed over to the designers, who will design the interface and interactions. At the last stage, the developers will take the spec document and the finished, polished designs and do their best to make this software/feature a reality.
Then it will be released.
In waterfall there is no way back and the feature/software is released when it’s completely done. Any testing can only happen afterwards.
Sounds good? Well, maybe if you are still using Fax as your main communication device.
Scrum to the rescue
Scrum (and other agile approaches to software development) changed this. The new mantra was „release early, release often“. Spec documents and polished designs where now swapped with short concepts of just a bit of the software and wireframes. Design would be part of the development process. Design would now evolve incremental, as the features in the software would.
And here’s the catch. UX works differently. UX tends to plan ahead and create full-fledged concepts including polished designs that would then be realized by the development team. At least this was how it was done back in the days.
Creating these concepts and designs along the running sprint leads to the development team waiting for input before being able to start working on stories and features.
So we see the issue: UX and Scrum don’t really match up. UX can’t be part of the Scrum process, or can it?
Pitfalls
As mentioned before it doesn’t work out to put UX in the Scrum process without also changing the UX process to fit.
But simply applying the rules of Scrum to the UX process doesn’t work out either:
- It’s important to have a conceptional phase, before starting implementing a feature. This consumes sprint time in which the rest of the team has to wait.
- Skipping the conceptional phase and simply trying things out and iterating can work out, but you can lose the big picture of your desired UX on the way.
- Rushing through concepts and designs to get a feature done in a sprint and accepting a „minimal viable UX“ can harm your product.
Mind the Agile Waterfall when implementing UX in your Scrum Workflow!
The Agile Waterfall?
So you could simply let UX write the concepts and craft the designs before the development team starts working, right? And the could simply realize the concepts during their sprints, right?
Well, that’s what is called an Agile Waterfall, or Agilefall. You would use agile methods that are constrained by a process that is more like a waterfall that Scrum wanted to replace in the first place.
Lean UX
One approach to tackle this issue is to have a look at Lean UX. Lean UX changes the way you look at a problem from the UX perspective. Instead of diving deep into the problem first and creating solutions afterward, you now look at the problem and make assumptions on it. „It will work out if we would change A to B.“ or „The user will understand C better than B“. Lean UX can work if you already have a good understanding of your user base and a pretty good gut feeling.
Simply take that assumption and run a test on it. As a paper prototype, as a working click dummy, or even a full-fledged feature that is designed and implemented as a working increment during a sprint. Recap afterward and validate your assumption. Iterate over it during the next sprint to make it even better.
Again the problem with Lean UX is that you are risking to harm your user experience and your product by releasing the wrong feature. Sadface.
UX as a Service
Another option we’ve evaluated is to have the UX designers as a separate team who would then provide UX as a Service, or UXaaS, to the development teams that ask for their assistance.
This can work out, but we found that it’s not a great idea to not have a UX designer as part of the development team. The key part of the important knowledge and information on the development gets lost and this makes crafting a great product hand in hand pretty difficult. Still #sadface.
Finding the right workflow
By now we have talked enough about the problem of integrating UX into the scrum workflow, but what about the solution?
It took us almost two years to figure out the right way for us. During that time we’ve talked to a dozen other scrum teams, agencies and user experience designers about their processes and ways of connecting the two worlds.
Not surprisingly it turns out that there is not one single perfect solution. Different teams approach this issue differently. From simply accepting that UX can’t be part of the Scrum process and setting the UX team apart, switching from Scrum back to a more waterfall-like model, to make it work.
We simply did not want to accept that. So we looked further. And finally we found the right combination of tools and methods to achieve our goal!
I’ll go into detail below, but to wrap it up the solution for us is a dual track agile approach, with a discovery and a delivery track, combined with staggered sprints in which the UX designer has different objectives and responsibilities, depending on the stage of the sprint, complemented with design spikes for uncertain UX challenges.
This workflow gives us the option to include UX deep into the scrum workflow without missing on preparing and planning the user experience ahead of the development.
UX & Scrum? It works with Dual Track Agile in Staggered Sprints and Design Spikes.
Dual Track Agile
The first magic word is Dual Track Agile. Basically it changes your Scrum workflow from having one continuous track in the short roadmap to having two tracks that run simultaneously.
Discovery Track
This track is mostly used by the product owner and the user experience designer. Both work closely to discover the user needs and wishes for a planned software or feature. The rest of the development team, as well as the stakeholders and users, act as consultants that are asked whenever questions pop up.
This track includes the complete user research, concept of the features as e.g. user story maps, drawing wireframes, etc. and crafting simple to complex prototypes.
The findings and concepts during the discovery track are then continuously given into the delivery track in the form of tickets, user stories, concepts and prototypes including results of stakeholder interviews and user tests.
Delivery Track
The second track, the Delivery Track, handles the development of the planned and concerted features or software. This is where the concepts are realized in real products.
If you are running single track Scrum by now this is your only track.
The role of UX in both tracks
In both tracks, UX has its defined role. While the UX designer works closely with the product owner in the Discovery Track, she or he also has her or his objectives in the delivery track.
Since the objective of the first track is to generate information and concepts during a sprint and then hand it over, there are always details missing that are important to consider during the development. For example details on an animation of an interface component.
So the UX designer is kind of a consultant to the development team in the delivery track.
Staggered Sprints
The key objectives of UX in both Tracks during a given sprint are always the same. They build up during the first sprints you run but get consistent after three sprints.
Those objectives are as following:
- Design/Concept for the following sprint (Discovery Track)
- Consult on the UX of the current sprint (Delivery Track)
- Review the result of the past sprint(s) (Discovery Track)
To make it more clear have a look at the following graphic that shows the role of UX during the given sprints on the given tracks.
Design Spikes
This workflow works great during daily business. But at some points there are uncertain UX challenges to face that is hard to work on in a sprint. The reason is that the result of a sprint should always be „good code“ or in the UX case „good UX concepts“. So what if you simply need time to figure something out? Or to try a new method without being able to commit to good results? In Agile Development there is a term for quick exercises that lets you explore solutions without the burden of writing good code, then throwing it all away so you can do it the right way with confidence. A spike.
We make use of exactly the same. When we need time to explore and play around we plan a spike in our sprints. With a defined time box and a defined goal that maybe something like „evaluates if empathy mapping can help us to understand the user better“. The result of that spike will then not necessarily be a great empathy map, but the know-how of empathy mapping and the confidence if empathy mapping fits your needs, or not.
Conclusion
All the workflows and techniques described show just a part of the options you will have to include UX in your scrum process. It’s the way that works for us so far. Let’s see how this will change in the future with new experiences, more know-how and new methods around the corner.
tl;dr
It’s quite hard to find the right workflow to include UX in the Scrum process in a smart way. The solution and flow described above show are the current solution: Dual Track Agile with Staggered Sprints and Design Spikes.
