UX in an agile world — An updated love story
Nearly two and a half years ago I’ve published an article on my everlasting endeavor to harmonize agile frameworks, like Scrum, with the needs and constraints of good UX Design.
This is a 2020 update with everything I’ve learned along the way.
tl;dr
After spending a couple of years finding the right workflow to include UX in the Scrum process in a smart way, our current solution is a Dual Track Agile in Staggered Sprints, utilizing Design Spikes. And I’m still sure it can be improved.
What’s happened so far
Since my first article I’ve spent countless hours with product teams in a variety of companies, talked to every product designer I could get my hands on and had the honour of sharing my experiences on different stages, like the World Usability Congress in 2018 and 2019.
→ Feel free to download my slides from the 2019 talk at the end of this article.
+++ Update 20.03.2020 +++
The recording of the 2019 talk is now publically available.
On harmonizing UX and Agile
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.
UX Designers, on the other hand, tend to work at a different pace. It’s about understanding the big picture first, doing user research and then jumping into delivering wireframes, mockups, prototypes and so on.
This work needs to be done in advance, before the developers can code the feature, as it’s a base for the development process rather than a part of it. Mainly because there’s only so much time in a given sprint and if that is used to do proper research and wireframing then the time can not be used for coding and shipping the feature.
4 main dissonances exist when you want to do UX inside of the Agile Sprint:
- It’s important to have a design phase, before starting to implement a feature. This consumes sprint time in which the rest of the team has to wait. UX becomes the bottleneck.
- Skipping the conceptional phase and simply trying things out over iterations can work, 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.
- During a sprint, the entire team should work towards the same sprint goal. If the UX designers work for an upcoming sprint they do not.
On UX Designers and Developers
Another issue I’ve encountered numerous times is a common understanding that UX designers do the UX design and developers do the development. At first hand, this sounds quite obvious and clear. But there’s a big catch!
Good UX design is not done by the UX designers, but by the entire product team. This becomes even more clear if you swap the term “UX design” with “product discovery”. And the development should not be done only by developers, but by the entire product team. Also, this becomes clear if you swap the term “development” with “product delivery”.
The lesson we learned the hard way: There is no they and us. There is a cross-functional product team. And it’s their task to ship a feature for the user. As a team, not as individual fields of specialization.
Let’s not talk about UX Design any longer
So we stopped talking about UX design and development in that context. We started talking about the discovery and delivery of a feature. Of and idea. Of a product.
Both discovery and delivery are tasks the complete team has to accomplish. Collaboratively.
By changing the terminology magic happens and the team finally speaks about us instead of them. Give it a try — you’ll be thrilled!
The driver’s seat
Now an individual designer and developer can only do so much work in a given sprint. And of course tasks like user research and wireframing are usually assigned to the designers and researchers. But they need the input and knowledge of the entire team to put the right information together.
We talk about being in the driver’s seat for a given phase (discovery and delivery) to make this clear. During product discovery, the UX designer (- and/or researcher, etc.) is in the driver’s seat and steers the expedition.
When it comes to product delivery this changes. Now the developer is in the driver’s seat and the UX designers assist.
It’s important to understand, that both Discovery and Delivery are done by the entire product team with changing specialists in the driver’s seat.
Product Discovery 101
To be on the same page here’s our definition of product discovery:
- Every story needs to be discovered. Exceptions prove the rule.
- It’s not only about UX design. Also, technical stories deserve discovery. (e.g. discovering your API architecture before implementing it)
- Discovery answers four important questions for every feature:
• Is the desired iteration valuable for the user/customer?
• Is the desired iteration usable for the user/customer?
• Is the desired iteration feasible?
• Will the delivery of this feature be ethically correct? (Not everything that can be built should be built.)
Product discovery is a process that helps us make sure we’re not just creating products that are usable, but also useful.
https://clearbridgemobile.com/the-step-by-step-guide-to-product-discovery
Deliverables of the discovery
We have two deliverables during product discovery.
The first is what we call a “Feature Blueprint”. Feature Blueprints are a high-level conceptual document that describes the Big Picture and possible iterations.
Our approach is to think about the feature we want to build assuming that we have unlimited resources and will ship tomorrow: What would the feature look like?
One way to do this is Amazon Press Release. Think about what you would tell the press when this feature ships, given everything you know today.
The second deliverable is “story-based discovery”. Here we talk about what is commonly understood as detailed design and engineering decisions. Research Insights, Data Analysis, Competitor Analysis, Mockups, Wireframes, Prototypes, High fidelity designs, etc.
The Quest for the right Workflow
While exploring various workflows to harmonize product discovery and product delivery with cross-functional teams in agile environments we’ve learned a lot. We’ve learned what does not work for us:
👎 Agile Waterfall
For everyone working in an agile environment the word “waterfall” alone should ring an alert. And that’s right. Back in the day, software developers worked according to a model called the waterfall. The project was split into parts (concept, design, development, etc.) and every step was done subsequently and the results were then handed over to the next phase. Not much communication during the phase, no way back. #sadface.
In an agile waterfall, you do the same. You create your designs and then hand them over to the developers to code them. No way back, not much communication during the phases. This frustrates developers and designers. Simply don’t do that.
👎 UX as a Service
The second thing we’ve tried is seeing the UX team as a satellite team that lives next to the development teams. The developers would then call the designers when they needed UX for their products.
Well, it turns out that developers (sorry guys and gals, you know I love you) tend to not really know when a UX designer can be of help and when not. In most cases I’ve encountered, UX was more in the role of firefighters to combat interfaces where even the developers had to acknowledge that the UX was crappy.
Again: Don’t do it. Get your designer to be an integral part of your cross-functional product teams.
👎 Lean UX
Having the designers in the team put them closer to the daily development business. That was great, but the circumstances of the Scrum Framework we used made it hard to spend enough time for UX design. So we tried Lean UX.
I know that this part of the article will be controversial and I know many teams that celebrated great success with Lean UX.
The change in approach, not working towards research but instead following assumptions and validating these as quickly as possible, to avoid becoming the bottleneck in the sprint, just did not work out for us.
The (not so) Magic Formula
But then we found the magic formula. Sad news: It’s not so magical. It’s hard work to implement in your team’s workflow and it will produce friction that you will need to handle. Communication is key here.
The formula that works for us: We work in a Dual Track Agile approach in staggered sprints and we utilize Design Spikes for uncertain challenges.
Let’s dig deeper to understand some of these buzzwords.
Dual Track Agile
If you are working according to Scrum, you work on one single agile track. This is where you plan your sprints, do your work and evaluate your findings after shipping.
Let’s call this the Delivery Track.
We’ve now learned that Product Discovery does not really fit on this track since it’s mostly not working towards the track’s current sprint goal.
So we embrace this fact and add another track to our agile toolbelt. This track lives next to our existing Delivery Track. It’s not hierarchically above or below it. Picture it more like parallel tracks on the same road.
This new track is where our discovery will live from now on. So we simply call it Discovery Track.
You might already do this
The two tracks above sound familiar, but you just don’t call it that way? True. Most teams I’ve had the pleasure to work with discover their stories in advance. They just don’t call it discovery. They call it “Refinement” or similar.
What is the basic idea behind the refinement? Making sure your stories are ready to be developed.
Well does that mean … Yes. What we now call discovery simply fulfills our Definition of Ready.
And with no surprise, the already existing delivery fulfills the Definition of Done.
The radical change here: We give it a clear name and allow the discovery to officially happen inside the sprint and not beside it.
Two tracks, two sprint goals
In the dual track agile approach, each track can have its own separate sprint goal. So basically your team will now define a delivery sprint goal, as you will most likely have been doing, but also define a separate goal for the discovery of the upcoming sprint.
Example:
- Discovery Goal: “Collect and document insights on the mobile usage of feature A”
- Delivery Goal: “Users can use feature B to accomplish C”
Two tracks, one sprint board
While you are now working on different agile tracks during your sprint it turns out that it’s best if both tracks are on one single agile board. The reason is simple: Your entire product development team is working on both tracks. Therefore everyone on the team must have a constant overview of the tasks and accomplishments on each track. Separate boards make this overview way more complicated because a team member will always focus on their board instead of the whole picture.
Our approach is to add Discovery Stories and Tasks that exist besides our User Stories and Chores.
Staggered sprints
To make both tracks work together without one becoming the bottleneck for the other we stagger our sprints and apply different roles to our UX designers on every track.
Let’s project our two new agile tracks throughout 3 sprints. And let’s have a close look at the roles and responsibilities of the UX designers in that scenario.
Sprint 1: Product Discovery
During the first sprint, the designers are in the driver’s seat to discover for the upcoming sprint. Again this does not mean that the designers do it all by themselves, but they are steering efforts in getting the right people together, asking the right questions and documenting the findings.
These findings are then handed over to the Delivery Track for Sprint 2.
Sprint 2: Product Discovery & UX Consultancy
In the next sprint, the designers again discover for the upcoming sprint. Same as in Sprint 1. But now there’s also life on the Delivery Track. Here the developers are in the driver’s seat. And as we all know features in the browser or app always look and feel different than in InVision or Zeplin.
Therefore the designers are now in a consulting role. Pairing with the developers to define the details of the feature during the sprint and assist in delivering the feature with great user experience.
Sprint 3: Product Discovery, UX Consultancy, Evaluation & Tracking
Without any surprise Product Discovery on the Discovery Track and UX Consultancy on the delivery track is the same as in Sprint 2.
What is new to this third sprint is that we now have a feature shipped to the users and can evaluate and track it. This again is not a one-person job, but it needs to be orchestrated and this is what the designers and/or researchers are now able to do.
After Sprint 3 the roles and responsibilities repeat.
Pro Tip: Every sprint is different
The flow pictured above describes a perfect world. A world where you only discover one sprint in advance. A world where all responsibilities are the same for every sprint (at least after sprint 3). The reality is different from that.
Your designers will have more discovery in one sprint and way more evaluation in another. Sometimes you will need to discover for 3–4 sprints in advance and sometimes you will need to discover and deliver in the same sprint because deadlines leave no way around it. That’s fine. That’s life.
Utilizing Design Spikes
Even with two different sprint goals, one for the discovery and one for the delivery you will face uncertain UX challenges. UX challenges where the result of your efforts are not increments that directly help in your given or upcoming sprint, but answers to a given question.
How do these challenges or questions fit into our workflow?
Well, the answer has already been given in the development world. If you need to work on something that does not deliver value for the customer you simply wrap it in a spike.
We utilize this and simply call it a Design Spike.
Design Spikes are always time-boxed so they can be planned for our sprints. They always start with a question to be answered (e.g. “Will this new fancy prototyping tool help us get better insights faster?”).
Well-designed UX harmonizes with Agile when working in a Dual Track Agile approach in staggered sprints utilizing Design Spikes for uncertain challenges.
Lessons learned: It’s a framework, not a fixed solution
After several years working with and on this solution, one thing is pretty clear to me. What I’ve described above is a framework, not a “one size fits all”-solution.
Mind the agile waterfall
Adding the second track to your agile workflow and staggering your sprints means working in advance. This always comes with a slight taste of waterfall.
Keep that in mind and make sure not to work too much in advance. Make sure you always get everyone on board on both tracks.
Every team is different
I’ve tried this framework with different teams myself and talked to a lot of people working that way with their teams. With every team come different challenges, opinions, and ideas that make this framework work better or worse, at least different.
Please understand this framework as a boilerplate, a starting point. Take it and adapt it to your way of working to make the most out of it.
Be aware of the context switch
Switching from Discovery to Delivery in the same sprint also means switching your context of work. Switching the context means disrupting the current workflow.
Take care that your discovery efforts do not interrupt your feature delivery. Plan your discovery the same way you plan your delivery. Make sure that everyone on the team is aware of that and respects the current context of the others. Communication is key.
🍬 Goodies
Slidedeck
Following are the slides that I’ve used at different conferences and meetups when talking and teaching this framework.
The slides are free of charge, but feel free to chip in a dollar. The slides are only for learning purposes. Public sharing is not allowed.
Possible JIRA Workflow
Here’s a version of our JIRA Workflow that describes how a story can move through the tracks and phases. Please remember that there are always shortcuts because every story is different.
