Stop using Agile as a design process
I’ve recently discovered a strangely compulsive TV show from the BBC called Fake or Fortune. In the show a TV presenter and art dealer work with a barrage of art world experts to determine whether a work of art put forward by a member of the public is genuine or a well-made fake. Whilst part of the attraction is of course the big reveal at the end (and the estimated new fortune if it is genuine), the forensic work that goes into investigating a painting, drawing, or sculpture is also fascinating. The tools, techniques and processes used to design and create something will always leave their tell-tale marks. An expert eye can pick these up, you just need to know what you’re looking for.
Clues that can reveal the history of how something was designed and made don’t just exist in the physical world, they are present in the digital world as well. With my product designer’s expert eye, I can often tell how an app or website has been designed. Has a form over function approach been taken? Has a user-centred design approach been taken? Has a particular design system been used for inspiration? Increasingly I’m seeing more and more examples of digital products being designed using an Agile approach. Where a team has undertaken rapid cycles of design and delivery to incrementally (and invariably haphazardly) build up a product. Tell-tale signs include siloed features, sprawling navigation, disjointed user journeys, inconsistent user experience and ever-growing design debt. Let’s look at an example of this.
I’ve been using Zoom, the video conferencing tool a lot recently. I think it’s fair to say that I have a love, hate relationship with Zoom. Whilst I love the fact that its reliable and the performance is generally great, I hate the design with a passion. A burning, burning passion. Zoom has clearly been designed using an Agile approach. It’s a product that has grown in a haphazard manner, leading to sprawling settings, a confusing UI and generally poor user experience. For example, I use two monitors when I’m working, a laptop screen and a larger main monitor. When I’ve used previous video conferencing tools, such as Webex, or Microsoft Teams I’ve always had videos on one screen and any screenshares on the other. This is usually done by docking and undocking the application windows. Webex for example has simple icons for switching between floating and fixed windows.
When I started using Zoom, I naively assumed that I’d be able to do something similar. I clicked around aimlessly looking for an option to undock the windows, but alas no such option could be found. Then a few months ago I stumbled across a chance discovery. Whilst looking for a way to share sound via Zoom I stumbled across a setting for using dual monitors. Miraculously this setting allowed me to have videos on one screen, and screenshares on the other. I punched the air with delight and then imagined punching the entire Zoom product team, one-by-one in retribution for the frustration their app had caused me.
As a designer you’re taught to use existing design patterns where it makes sense to do so (like this instance). So, why have Zoom in their infinite wisdom decided to go against the norm? Why have they buried an option within settings, rather than within the main video call UI where users would expect to find it? I suspect that Agile is to blame. I can imagine the conversation the team probably had:
Product manager: “Lots of our users have asked to be able to show videos on one screen, and screens being shared on another one. We should work on this during our next sprint.”
Designer: “That makes sense. We can simply let users dock and undock their windows. This is what other tools like Webex and Microsoft Teams do. Let’s follow a pattern users are familiar with.”
Developer: “Hmm, it’s going to be hard to design and develop something in one sprint. What about a setting for using dual monitors? That will be much easier to implement. We could probably squeeze that into one sprint.”
Designer: “But users would have to know that the setting exists, and it would go against how every other video conferencing tool works.”
Product manager: “Ok. Let’s add a setting for now so that we don’t have work that carries over to the next sprint. If users complain about it we can always change it later.”
(Footnote: Don’t assume that users will let you know if something is brilliant, or terrible. When was the last time you fed back to a product team? 99% of users have better things to do than let the product team know that the setting they just added is a really crappy design solution).
Designer: [Sigh] “Ok. So long as we evaluate whether it’s being used or not, and look to improve it further down the line.”
(Footnote: This also never happens. For most teams a featured is delivered and then they move on to the next. Changes are rarely evaluated, and necessary improvements are rarely, if ever made).
Product manager: “Err, sure, sure. Whatever you say.”
Of course, like an episode of The Crown (a fictional, but fact-based drama about the British royal family) that conversation, whilst being plausible is entirely speculative. It demonstrates how Agile might significantly impact not just how a product is built, but how it is designed in the first place. This is a worry because Agile was never intended as a design process and yet many teams use it as one.
Agile as a design process
Wikipedia lists a whopping 14 different flavours of Agile software development, from Scrum and Extreme programming to Kanban and Lean software development. Whilst there are many differences between the various frameworks, they all have one thing in common: They are frameworks created by engineers, for engineers. Product design either hasn’t been considered or is very much an afterthought. Put simply, Agile doesn’t work as a design process because it was never intended to be one.
Wait, you might cry. What about Agile UX, or Lean UX? Surely, they are the best of both worlds. Look, see below how master framework wine maker Jeff Gothelf has expertly blended the Agile and UX grape varieties to create an absolutely belter of a vintage! Alas, if it were only that simple.
Unless you happen to be a time lord, and therefore can bend the usual rules of time to your will (although be careful about inadvertently creating a time fracture), squeezing product design practices into rapid design and delivery cycles usually involves:
- Working like crazy to carry out some minimal product design work upfront, such as during a short design sprint or ‘sprint zero’.
- Working like crazy to carry out some minimal product design work during design and delivery cycles (e.g. two week sprints).
An Agile approach is not very accommodating of product design work. It’s like deciding you’re going to build a railway and then trying to lay the track, design the trains and build the train stations, all whilst you’re still trying to work out where the train should go and what you should be transporting. As I’ve written before (see How to deal with design debt), an Agile design approach will inevitably lead to lots of design debt, lots of rework and ultimately a poor user experience.
Use Agile as a delivery process, not a design process
Rather than trying to shoehorn product design practices into an Agile approach I believe that it’s better to let Agile do what it does best: deliver, rather than design.
A great way to do this is to have a little more upfront design work, and then to have a dual-track discovery/design and development/delivery process (see below). This allows just enough design work to be carried out ahead of delivery cycles. The upfront design work should be just enough to establish the solid foundations of a design. It could take the form of a storymap and low-fidelity wireframes or prototypes. With the solid foundations of the design in place, work can be researched, explored and defined just ahead of delivery cycles.
Finally, it’s worth remembering that no team should be a slave to a process. If you need to change your process, change it. If something isn’t working, don’t do. After all, it’s not a process that will deliver a fantastic product to your customers, it’s people. Steve Jobs certainly knew that to be the case. In a 1994 interview with Rolling Stone magazine he said:
“It’s not the tools that you have faith in — tools are just tools. They work, or they don’t work. It’s people you have faith in or not.”
Steve Jobs
Don’t put your faith in Agile to design and deliver a great product to your users because 9 times out of 10 it won’t. Instead, use Agile as a delivery process, not a design process. Find the right process that works for you and don’t be afraid to change it. Oh, and if anyone from the Zoom product team is reading this, can you please find a better solution than the crappy dual monitor setting checkbox. It really does make me angry every time I use your product!
See also
- How to deal with design debt (UX for the masses)
- Dual Track Development is not Duel Track (Jeff Patton)
- The new user story backlog is a map (Jeff Patton)
Image credits
Originally published at http://www.uxforthemasses.com on May 19, 2021.
