Header image ‘Business vector’ created by pch.vector

During my many years and many projects of trying to push and show the value of ‘this UX thing’, there’s always been a point — every company, every long-term project — where the team I’m working with realizes we’re at too low a level for the questions and challenges I field their way. When ‘why do we need to build this?’ is answered with ‘because it’s a requirement’, you end up confronted with a choice of being a bottleneck in their backlog, or letting potential nonsense make its way into the pipeline when you can think of fifty more pressing and valuable tasks. I’m guessing I’m not the only one who’s been the thorn in the side of teams who ‘just want to deliver’.

I’ve too often been the cog in the machine. The squeaky wheel. The petulant toddler asking ‘why, why, why’. And as a result of that, more than a handful of folks have come to the (not irrational) conclusion that UX slows them down. Add to that the actual bottleneck we take to design the software the teams need to build, and…you get the picture.

We’re often at odds with our team’s goals or our management’s goals, because we’re working hard to deliver on business goals. And if those aren’t clear in a delivery team, it can be hard for us to see the point of begrudgingly making stuff up.

Turns out that as sure as I’ve been that I’ve been right, I’ve been guilty of a few things too.

I’ve long been a value- and data-driven solutioner. Anyone who’s worked with me has definitely heard me talk up Lean UX to an eye-rolling degree. But let me tell you a story:

The first time I tried to test Lean UX I was working for a large telecom corporation that was fairly new to the software world. I was one UX ‘specialist’ to a team that started around 100 people, 50 of whom were developers, split into feature teams. They were ‘agile-ish’, in that they practiced a weird scrum/kanban mashup and held typical agile ceremonies, but they still answered to long release schedules and imposed deadlines, and I can’t recall a time we had a dev sprint just to improve on previous work if there wasn’t glaring technical debt.

Since I was new to Lean UX but had practically memorized the book, I was gung-ho to try out everything. And one principle of the methodology is that the whole team works together. This made me nervous. It may make you nervous. Because when you work for an enterprise that clearly doesn’t ‘get’ UX, and you ask your devs, POs, and QAs to start drawing out interfaces… let’s just say you can feel like you’re training on best practices instead of methodology.

I came away from that session deflated. The team felt like it was a waste of time because obviously I could design better, and they could have spent that hour coding. The handoff method was working fine, mostly. Besides, as mentioned, they already had requirements. So me coming in asking what the solution should be from a value perspective was already in conflict with the enthusiasm they had for their ideas in progress.

That was about five years ago, and I’d find myself saying to people since that Lean UX was great, but I recommended skipping the collaborative designing bit, even as I moved into a new work environment.

But that, I realize now, was wrong of me. To give something one try in one way and assume it’s useless was extremely short-sighted. Instead of realizing that the entire spirit of Lean is to further develop ‘horizontal’ skillsets and collaborate in real time to deliver with as little handoff as possible, while improving morale and quality within the team… I was frustrated that my attempt to take over a team’s ways of working was unsuccessful. And I was secretly all-too-eager to keep these ‘specialized design skills’ all to myself.

So I’m reframing my thinking.

I’ve recently been deep-diving into Scaled Agile (SAFe), as our project-focused consulting firm has made the switch. It’s been simultaneously exciting and challenging. On one hand, they’ve adopted the Lean UX pillars of value that I’ve been preaching my whole career. There’s a strategic layer for the problem-solving and research part of what we do, and there’s a team layer that’s more focused on executing the solution.

We didn’t have this model yet in the last project I was a part of. But on that project there was a lot of pivoting, and we couldn’t afford to have our traditional ‘UX bottleneck’. The architect on the team, who was (helpfully) skilled in UI, and myself (having an intermediate understanding of front-end development and frameworks), started to frequently get together in front of whiteboards around the office. Or even on one occasion, I dropped a piece of paper on his desk with a doodled solution that I also took a photo of for our user story. Our goal was often the same: how do we most simply get our user from state A to state B? In this case we meant both simplicity for our end-user and for the team’s implementation.

And I have to say, our delivery skyrocketed. Because rather than hiding in my UX bunker doing my UX job, we were ideating. And I started to think back to that first experience running a collaborative Lean workshop, and about the things I could have done differently.

What I learned in hindsight, is that an effective team can work collaboratively because an effective team has the same goals.

And if we have a strategic component to our project at the business level, we can build a delivery team around those strategic business goals. But if we’re purely the executioners, our shared goal may be something different entirely. Like to pivot quickly and come up with something simple. If I’d walked up to that whiteboard and started asking the ‘five whys’ to our architect, he’d have rightfully thrown me out of the room. Because while there was a problem to solve, it wasn’t a business problem. It was a team delivery problem. It was a ‘product owner needs something to demo next week’ problem.

So if you’re down in the weeds like I’d been so many times, and you’re unable to affect strategic change that sprint, maybe it’s time to rethink your goal and align it to your team’s. Maybe it’s time to sit closer (after this pandemic, of course) or adjust your space to better facilitate collaboration. We can be great problem-solvers, and we all need time alone to think, but I think when those brilliant ideas start to fester in our brains and become the ‘obvious way forward’, we risk becoming disconnected.

The first statement of the Agile Manifesto says ‘individuals and interactions over processes and tools’. And while, somewhat ironically, that is process, it’s also at the heart of my experience and learning on this topic. Maybe if we focus on aligning goals and collaborating our way toward them, we can start to cut out the bottleneck handoffs and let go of what’s, frankly, a lot of useless frustration.