Paul McAleer

No One Expects the Agile Inquisition

Paul McAleer

Many years ago, I was working in the UX arm of a company that "went Agile". Famously, my team along with the creative team were outside of the Agile process – we were still in the "design is waterfall, building stuff is Agile" mode, organizationally. Compounding the difficulty, the organization had been led by development since its inception, and design was seen as nothing delivering any value. ("Make it pretty.")

But my team and I really didn't want to work that way, and one of my team members in fact led the way on this; she was tightly integrated with a key development team. There were successes and setbacks, for sure. There was one meeting where, I kid you not, a C-level executive was yelling at me and someone on my team saying, “Why are YOU talking? Who the hell are you? You know nothing about how to build things!” So yes, bumpy.

A key opportunity presented itself when we were doing a full-on redesign of a video streaming product. I worked in tandem with a visual designer who knew his shit, and got input from product owners and my teammates along the way. This was going to be the thing that put our service on the map. The comps and interactions and design we came up with was fantastic, yet practical. A good balance. And it tested well with users.

The way our organization approached Agile was an "in the large" model. A multiple day planning session was held to map out all of the sprints for the upcoming quarter – estimation, sequencing, et al. This was an offsite affair, where teams worked independently and then came together to give a total lay of the land. Within the video streaming team I was responsible for the design so I was its voice. Designers and developers didn't work side-by-side (due to the waterfall-y nature of our Agile implementation) so designers and developers would work on separate tracks in parallel sprints (where one design sprint feeds into the next dev sprint, and so on). This meant we also needed to estimate things separately. Using the mockup we had shown to others, I worked with another designer and estimated out how long it would take us to build this thing and get it ready for development.

We took perhaps 40 minutes to estimate everything out. We overlaid regular usability tests in the mix, testing both the story-level stuff as well as the epic-level stuff. The product owner thought it was a great plan, and supported it.

Then came time to talk with the developers on the team. We were in a big conference room, and I put the design up on a projector. I walked through the plan my colleague and I came up with. The questions started.

"What happens when a user clicks on this?"
"Well, I don't know yet. This is a comp. We need to figure that out. We've estimated how long it'll take to figure it out."
"That doesn't help me. How long is it going to take you?"
"Here are the numbers. But, it depends. We need to be flexible."
"Okay. Well, there's no way I can tell my development team to build that. You don't even know what it's going to be yet."

I was a little surprised by this reaction. We weren't reinventing massive UI stuff here, to be fair, but I also didn't have everything 100% specified – that was never a goal of our work at this time.

"Let's talk about the header. The header has a takeover panel. What happens when the user is on mobile?"
"The same thing, just on mobile."
"I can't estimate that. How can you? I might as well just give everything infinite points."
"Okay..."
"And is any of this going to animate? Is it going to drop down? Does it need to slide in?"

Every single element on the page was dissected, led by one vocal developer (the lead developer). He was incredibly frustrated to think that a designer would make something and have no idea about everything in advance – that was simply not how he wanted to work. I was frustrated, in turn, because he expected me to have an answer for every item on the page, even though this had only seen concept testing with users (and not hardcore usability testing, yet). I'd like to add that I reached out and worked alongside this person for months, so none of this was truly new.

This dialogue continued with the developer over the course of, I kid you not, 3 hours. His argument was clear: because you, as designers, didn't create a comprehensive spec of what we're going to build, we can't build it. We got to yelling at one point. Yelling! Over estimating a mockup! It was absurd.

But, that's what happens when an organization says they're "going Agile" and then drops the ball on implementation. It builds walls instead of bridges, as they say. I had pushed for the design team to be truly a part of the development team, but the offset sprint model didn't help that. In addition, this organization's overall design maturity level was quite low – an in-house creative team was only a few years old at this time, and the creative team was hardlined against using Agile.

In another universe...

I'm a number of years out from this incident, now, and I wonder what could have been done differently.

 

  1. Just put the damn design and development teams together, working together. There were organizational and structural difficulties at play here, and the overall environment didn't promote trust, sympathy, nor empathy – not in the slightest. Assigning a designer to a team is way different than saying she's on the team. That's what happened here.
     
  2. Continuously reinforce the team idea. When it came down to it, it was me and one other guy in a shouting match. That put everyone else on lockdown; who would want to partake in that? While we almost certainly invited others to provide answers for estimates/etc., strong personalities were at play here.
     
  3. Give the product owner real power. Our product owner watched this whole thing happen and did nothing. So it was people arguing and debating and trying to slog through, and no one being empowered to make the "final" call.
     
  4. Force the design team to demonstrate business value. This project originated with a high-up product lead and the creative director, agreeing that the product needed to be redesigned. But overall business goals and values were never truly stated (and we did not explore them in depth), so it was viewed more as a UI bandage. Really, we should have been on the hook for this.

So, what happened?

 

I wasn't involved in that team nor project much longer; this incident was so painful, and showed such a lack of support, that I moved on when I could.

The product we designed never saw the light of day. When it was time to implement, the current branding guidelines were fully applied and the product lead simply didn't like it anymore. The organization scrapped all of it and went forward with another design that was built for another division of the organization. It had no user research behind it, no input from a creative nor design. It was "reskinned" to match the current brand, and launched.

I had a few chances to use it in the wild and I'll tell you this: I noticed the typos.

---

Postscript: I'd like to note that I'm absolutely not opposed to Agile as a methodology; heck, I'm a certified Scrum Master. But this particular implementation was flawed, and put process before people – going against the ideals of the Agile Manifesto.