Challenge
Design Process

— Pure agile team with no experience working with UX
— Educating product and engineering on UX process and values
— Rapid growth
— Multi-city org
— Build 19 products at once, ready, fire, aim!
 

In the winter of 2015, a new agile coach joined the team in Minneapolis.
Suddenly backlogs were being pulled, our design system’s engineering resources were being questioned, and we repeatedly heard the refrain “that’s not agile.”

The challenge was clear: the majority of product and engineering leadership had never worked with a UX or design team. Thus began a three week process education, the likes of which I’d never had to lead.

Before the agile coach joined our team, we’d built up a lot of trust with product and engineering (most of which hadn’t worked with UX teams before, either). This new agile coach had derailed months of hard work aligning on terminology, cadence, roadmaps, and execution.

Hannah Grossman (our lead UX contractor in Minneapolis) and I had spent countless hours arguing for good UX process with the product and engineering teams in Minneapolis. This meant standards like user research, story maps, flows, and UX working closely with users and products preparing stories for engineering sprints.

I quickly found alignment with a brand new team member, Allison Hopkins, who’d joined our team as VP of Product from Qualtrics.

She’d had difficult experiences with the agile coach in a prior role. We worked tirelessly for three weeks straight — I moved into the hotel across the street from our office in the middle of winter in Minnesota for long hours in small rooms.

The crux of our argument was around timing and terminology. The idea that design was working on anything without engineering was unacceptable to the agile coach. He felt strongly that stories should be defined as part of sprint planning, and that design and product should work in sprints with engineering.

To be clear, the “agile purist” approach can work for small teams and small application development. Iterate slowly towards a cohesive product. Engineering-led product development has done this for decades, but we were not a small team or a small product.

We had roadmaps to validate in the market with our customers, sales teams to support, user research, prototyping, testing… all the trappings of a larger product org trying to align over 19 product roadmaps, six in active production. The idea that we should run our entire team on the original principles of Agile as written down in the 1990s was a non-starter.

“The only thing of value in sprints is working code.”
— The Agile Coach

The Agile Manifesto

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

The Infor Retail UX Manifesto

Results over process. Creativity is messy.
Form is function. Design isn’t how it looks, it’s how it works.
Respect the user. Understand their wants and needs. 
Test everything. You’ll never know until you take it to the user.
We're all designers. UX is everywhere, and the details matter.

Eventually, we’d emerge with a clear process that everyone understood, and it was stronger for it—more comprehensive, it addressed all the stages of a product’s life cycle for all stakeholders, documenting roles and even tooling.

Our agile coach was soon moved to a different role: leading a tech evaluation of an obscure multidimensional database we’d later become all too familiar with, called LogicBlocks.