Mastering Agile UX — Part 1: Managing your work
Many things at one point or another have been erroneously labelled as a ‘Game-changer’. Remember 3D TV? That was once going to be a ‘Game-changer’. Last time I checked the game of watching TV hasn’t changed much at all. It turns out that making viewers wear the sort of glasses that Elton John might have favoured in the 1970s takes a lot of the fun out of watching TV in 3D.
One thing that certainly can be described as a ‘Game-changer’ is Agile software development. Agile hasn’t just changed the game of software development, it’s ripped up the rule book, put it in the recycling bin and then written a whole new one. From humble beginnings in 2001 with the Agile manifesto, Agile has radically changed how digital products are now developed.
Agile has touched every aspects of software development, including of course UX. If you’re working in an organisation that has moved to Agile then the chances are that you’re now working within a cross-functional Agile team. As someone who has previously made the switch from a team of UXers, to an Agile team I can testify to how radically it changes things. Moving from a design, research or UX team into a cross-functional Agile team is like going out on loan to a different football club (soccer to any non-Europeans) and being asked to switch from playing in defence to attack. Sure, the sport is the same, but everything about the team, the role, the set-up and what it takes to win is now very different.
In this 2-part series I’m going to run through some key advice for mastering Agile UX, as part of a cross-functional Agile team. The first part will cover some tips for managing your work, the second will discuss collaboration; in particular collaborating outside of your team. If you’re new to Agile UX you should first take a look at my tips for bringing UX to the Agile party as this provides a good introduction to Agile UX.
Let’s begin with another sporting analogy.
The UX all-rounder
I’m going to switch from football to cricket to explain why becoming a UX all-rounder can help you to better manage your work. If you’re not aware of the game of cricket (shown below), it’s like baseball, but with bigger bats, a lot more grass and games that can take up to 5 days! (In fact the longest ever game of cricket took a whopping 12 days, and still ended without a winner). In the same way that baseball has pitchers and batters, cricket has bowlers and batsmen. A cricketer is generally very good at either throwing a ball (i.e. bowling) or hitting a ball (i.e. batting). However, every now and then an ‘all-rounder’ comes along who has mastered both of these skills. As you can image, these players are invaluable because although they might not be the best bowler in the world, or the best batter in the world, their versatility is very valuable to their team.
An Agile team should be like a mini start-up (minus the blood thirsty investors). As such all the skills required to do the work should ideally be present within the team. The more skills you have, the better you can understand the work required, the better you can manage that work and ultimately like a cricket all-rounder, the more valuable you’ll be to the team.
This means that if you’re a designer in the team you had better start learning more about research, and had better start improving your research skills. If you’re a researcher in the team you had better start learning more about design and had better start improving your design skills. I’ve written before about why designers should research, and researchers should design. If you’re working in an Agile team, this is even more important.
Tracking UX work
Agile teams will invariably track development work. This might be via Jira (a popular issue and project tracking tool), Github or even via a physical board. However, they will rarely track the UX work that informs this development work. This work can include research, design, prototyping and validating ideas with users. By tracking this work via a discovery board (sometimes called a ‘Disco’ board!) you can get a better idea of the design and research work that will be required.
A discovery board not only helps to track design and research work, it helps to link this work to what is being delivered. To find out more about how you might use a discovery board, I’d recommend reading Danny Vigil’s excellent Level Up Enterprise Product Design with UX series.
Limiting work in progress
As a UXer within an Agile team you can expect your workload to fluctuate. Some weeks you will be swamped with work, other weeks the team might seem to barely need you. A good way to protect yourself from taking on too much is to introduce a work in progress (WIP) limit. A WIP limit isn’t the latest dance craze, but a way to keep a check on the number of design and research tasks that you take on. For example, you might introduce a WIP limit of only working on 1 discovery item, and 1 delivery item at a time.
Delegating UX work to the team
Just because you’re the UX guy or girl in the team doesn’t mean that you have to do all the UX work. Delegating UX work to the team is not only a great way to prevent yourself from being swamped, but also to help the wider team improve their design and research skills. As always with delegation make sure that whoever agrees to take on the work knows what is required and has the skills necessary to do it. Having best practice guidance and a design system in place makes delegating UX tasks easier as there is a framework that the team can use.
Protecting your working time
Most Agile teams seem to really love meetings. They must do because they have so many of them. Daily stand-ups to give updates. Planning sessions to estimate and plan the work. Retrospectives to apportion blame, I mean reflect on how things went. Health checks to gauge the mood of a team. Show and tells to showcase the work that has been delivered. If you’re working in an Agile team you can expect to spend a lot of time in meetings. And not just meetings with the rest of the Agile team, you’ll invariably also have to attend cross-team meetings as well, such as design critiques, meetups with other designers and researchers, workshops and cross team show and tells. With so many meetings it can be difficult to find time to actually get anything done!
A good way to carve out time for getting design and research work done is to protect this time in your calendar. You might block out time to get an important task done, or set-up regular blocks of protected time. If someone tries to book something over these hallowed periods, then decline it and politely remind them that you neither negotiate with terrorists, nor pushy meeting bookers.
You could also set-up focused workdays, such as meeting free Tuesdays, or have a regular working from home day to get more done. It’s also important that you use your time wisely. Always ask: do I need to be at this meeting? Do I need to be involved in this? If the answer is, ‘probably not’ then you should look to spend your precious time elsewhere.
Take a look at José Torre’s How can you find time to design? article for more tips and advice on how to protect your own time.
Finding a balance
As Mr Miyagi, Daniel-san’s mentor from The Karate Kid reminds us, “If whole life have a balance, everything be better”. The first step to mastering Agile UX, is mastering your own work. Do this, and you can start mastering other aspects of Agile UX. Part 2 of this series will cover another crucial step to becoming an Agile UX master: Collaboration.
If you like this article then please recommend and share it. You can find lots more articles like this on my blog: UX for the Masses
See also
- Tips for bringing UX to the Agile party (UX for the Masses)
- How can you find time to design? (UX Collective)
- Level Up Enterprise Product Design with UX (Danny Vigil)
Images
Originally published at http://www.uxforthemasses.com on October 19, 2020.
