Addendum - An Agile UX Story

In my previous post I shared about experience I’ve had in “connecting” UX activity into Scrum development teams. I tried to explain a pattern of collaborative partnering over either embedded UX in the teams or independent UX outside of the teams.

I thought I’d share another story that illustrates an aspect of these ideas.

Not that long ago I was working with a client to help them understand and practice release-level planning across their Scrum teams. Some of the challenges revolved around incorporating UX design work and cross-team dependencies in their projects.
They had hired a gifted, Harvard-educated designer. I’ll call her Sue. Sue reported directly to the Chief Product Owner and had been given the assignment of redesigning some of the legacy application as well as designing some new components.

Taking the role to heart for the next 5-6 months, she developed an entire view toward a redesign of a specific area in their product line. But there was one problem.

She did this independently and hadn’t vetted any of it with the development Scrum teams. Not one bit.

But the Chief Product Owner became enamored with the new design ideas, and began “pushing” the teams toward them in all of her conversations. Yet, the teams still hadn’t “seen” anything, or been asked to provide feedback.

This is where I came into the picture.

I’d been asked to do some Product Owner training for the organization. This included training on the role, backlogs, story writing, and some release planning & story mapping work.

When I heard this situation, I asked the Chief Product Owner if we could engage the designer in a release planning exercise. I thought it would be a good way to:

1. Allow the designer to present her ideas to the team;
2. Allow the team to brainstorm their own design ideas and story reactions;
3. And allow everyone to create a “merged” or “shared” view of the work – via user stories.

We did just that.

The Chief Product Owner set the big picture of the redesign effort. She spoke in terms of the WHY behind the effort and what constraints and goals she’d asked the designer to consider.

The designer took about 30 minutes to explain her overall design ideas and goals. But she didn’t physically share the designs themselves.

Then given this information, everyone began writing stories that captured aspects of the work effort. This included functional and non-functional stories. It also included user story research spikes and simple design idea explorations.

What I wanted to do was allow the team, including the designer, to come up with a shared view not only to the design, but to also what was feasible.

It worked BEAUTIFULLY. Once we had our story map, the designer then shared her physical ideas. In some cases, they were identical to what the team had come up with. In others, they were new, but quite complimentary. In others, she changed her ideas toward the teams, because of the simplicity or implementation effort associated with them.

The key point is we entered the room with:

• A team who was essentially ill-informed and uninvolved with the new design, and
• A designer who was running with everything in parallel.

We exited the room with:

• A team and a designer who had a shared view of the work. They had listened to each other and collaborated towards a design vision that everyone could get behind…because they had created it together!

I felt this was much better than simply “throwing the design over the wall” to the team. Don’t you?

Read my previous blog, How should UX Work in Agile.

Stay agile my friends!

Bob.

Up Next:

• How should UX Work in Agile >> Read
• 8 Rules of Agile Architecture >> Read