Part 1: Top 5 Pain Points about Agile for Researchers and Designers

I’ve worked in digital product design for over 20 years, and I confess, I roll my eyes when it comes to agile.

I want to love agile, because I believe in collaboration, iterative releases and ongoing development. Digital products need to be continually evolving to stay relevant to users and deliver value to businesses.

But all too often I see agile product teams cherry picking agile principles and cranking out crappy products and disjointed experiences. The big picture vision is lost amidst a giant backlog, and solid research and design are sidelined.

The top 5 things that make it hard for me to love agile:

1. Agile doesn’t mean good. It’s often an excuse for lack of strategy and vision.

I cringe when I see a lame vision statement like, ‘Our vision is to create transformational solutions’. What does that even mean and how does a team embrace it? How do they know they’ve achieved it? How will they measure it? Without a compelling vision, and strategic principles that guide direction and prioritization, it’s hard to be more than mediocre.

2. Self-organizing teams, really?

You need leadership, planning and accountability. If the company and product development team is small, it can be workable. But in any large corporate you need someone who can herd the cats, talk to customers, manage upward and be accountable to stakeholders. I get that teams work best when they define their own priorities, timeframes and sequencing, but this is a skill that comes with experience and needs oversight to meet market realities.

3. Teams build features not experiences. 

In engineering-oriented cultures, it’s common to see managing the backlog getting a higher priority than understanding the value to end users. Audience research and good UX are often sacrificed when the success measure is producing working software. If there are many products, this problem is compounded. Solid design systems can help, however a good design system requires upfront investment and ongoing evolution as products themselves evolve.

4. Agile principles often aren’t realistic in practice. 

Agile principles favour co-located teams, business people and developers working together and all team members engaging with customers. Fine in theory; not fully embraced in practice.

Is in-person interaction desirable? Absolutely. Is it essential? No. We can collaborate remotely (as COVID has shown) and bring the right voices and talent to the team. 

Business people and developers working hand in hand? Rarely happens. They don’t speak the same language. Typically the Product Owner is the bridge between business and dev but rather than collaborating, they become order takers.

The team spending time with customers? Not likely. Maybe in small companies with small product teams; but at scale? Doesn’t happen. In global tech companies researchers and UX designers are embedded in agile teams. The team works together to identify research priorities but researchers lead the work and share with the team.

5. Measures of success and product performance are lacking.

Within agile teams, working software is how progress is measured. The underlying rationale is that time to market equates to success. The Facebook motto: ‘move fast and break things’ epitomizes this. But look where this got us. Even Facebook has abandoned it.

We need broader measures of success that include usability, inclusivity and accessibility, data integrity, security and trustworthiness. And we need to be accountable for potential harms and social impacts. Yes folks we need greater accountability.

.....

And there you have it, 5 top reasons why working within an agile development environment can be challenging for researchers and designers.

In Part 2, rather than just rant about what doesn’t work, I’m going to share our thinking on how we can better connect digital strategy, design thinking and performance frameworks with agile processes.