Lean Atomic Micro Sub Agile Pasta UX

A picture of Claire's hands making fresh pasta.

In our last episode deconstructing the current state of the User Experience profession¹, we asked: Just What the Heck is UX? We learned that UX ain’t what it used to be and that it is what it is.

Today I’d like to focus on a specialty(?) within UX: Lean.

I’ve long wondered, what is Lean UX? I’ve not wondered enough to read much about it, but I have asked people from time to time. Usually it goes like this:

Me: So. Lean UX. What’s up with that?
Them: Yeah.
Me: No, seriously. What is it? Or, more precisely, how do you describe/define it?
Them: Well … [explanation that is roughly similar to what others say, but not exactly]²
Me: So, it’s quick UX?
Them: Yeah, like Guerrilla UX.
Me: Isn’t that its own thing?
Them: Maybe?
Me: Should we stop talking about this?
Them: Yes, please.

Today, I broke down and clicked on a article that purported to define Lean UX. I read it. And my first thought was, “So … it’s UX?” Collaborative, focused on the user, little-to-no documentation, “cross-functional”³, fast!

So … it’s UX?

Back in my day⁴, we did this thing called UX. It bears a striking resemblance to Lean UX. The one thing I’ll concede is there was a lot of documentation. Then again, it was after we determined what was the right thing to build. As much as everyone seems to hate documentation⁵, relying on the prototype to communicate everything is a terrible idea.

Should UX Even Be in Agile?

What I’m taking away from what I’ve gleaned from my lean-learnings on Lean UX, is it was/is an attempt to make sure UX wasn’t forgotten during the Agile Development process. My mind races off in many directions having typed that sentence, primary among which is: should it even be in Agile?

I think my answer is no, it shouldn’t be in Agile.⁶

Agile is a Development methodology. UX is not a Development methodology. It’s a Research, Design, and Testing methodology(ies). Agile Development comes into play once you’ve determined what you want to ship. Until then, you haven’t (or, should not have) determine what the Thing™ even is.

You might be saying to yourself about now, “But, Matthew, that sounds an awful lot like Waterfall. We aren’t supposed to do Waterfall anymore. We are supposed to laugh derisively at Waterfall.” To which I might respond, yeah, good point. Because what I’m describing is Waterfall-y.

That said, the way I see Agile being implemented by so many organizations is, essentially, tiny waterfalls. I mean, Lean Waterfall™ (patent pending). It’s rapid in the sense that rapids are kind of one tiny waterfall pouring into the next. And that’s all well and good. The problem with Waterfall has not been the method, but how it’s implemented. Same with Agile. I love the idea of Agile. Never once seen it run well. You may have, and that’s great! Seriously, it’s a good thing you got to experience that. I’d be inclined to look at that experience as an outlier though.

The problem with all methodologies is, uh, how do I put this politely … Well, the problem is people.

For a long list of reasons, it’s people. The primary culprits tend to be Design-by-Committee and Swoop-and-Poops. Design-by-Committee is like Collaboration, but more of a “what do you wanna do? I dunno, what do you wanna do” flavor. Swoop-and-Poops are when someone who has the ability to fire you tells you what will be designed and built and how and also the person who can fire you has a kid who doesn’t really like that particular shade of blue.

A well-oiled⁷ Lean Waterfall™ machine should work like this:

  1. Discovery. This may include some research, design, and development activities, but all of the outcomes may be thrown away and laughed at derisively at any time.

  2. Definition. This comes after you’ve done your Discovery homework. You’ve determined already that The Idea™ is worth doing. This includes activities such as research, design, and development. Kind of like the Discovery phase, but you are committing to a path, yet still require some refinement. Documentation begins!

  3. Development. This comes after Definition. You’ve refined the idea enough, validated the Desirability, Viability, and Feasibility. You’re innovating! Or, at least, building something people want. Activities in this phase will include Development (any building at all, not limited to software here) and Testing! Also, realistically, some design refinement. It happens. Documentation ends!

  4. Discovery 2: Electric Boogaloo. This is after you built The Thing™ that was based on a sound The Idea™ and you ship it. Activities will include, keeping a close eye on how things go and more research, design, and development. And hopefully profit!

Strangely enough, that’s how some of the places I’ve worked have implemented Agile, though it’s tended to not run well. Again, people. Don’t get me started on people. The places who run Agile and don’t work like that tend to shove UX (Lean or not) into wherever they can and it ends up being activities to make the UI look better.

I like Lean Waterfall™. Can’t say I’m a fan of all the other stuff that’s come along. Creating a conceptual placeholder for UX so that it fits within the development cycles of an organization instead of designing the organization to actually work well in the first place is an entirely missed opportunity. It’s also way harder, so I get why designing organizations to work well in the first place isn’t at the top of most people’s To Do list.

It’s much easier to Lean Atomic Micro Sub Agile Pasta8 whatever it is you need to cram into the never-willing-to-pause-and-self-assess machine most people work in. It’s easier because UX has longed for so many years to have a seat at the decision-making table and to get there you had to be a team player and ship! The thing is, they finally let us have a seat at the table.

Now it’s time to make a better table.

¹ With a Marxist French-Feminist Post-Structuralism perspective.
² The variants of the explanation are in-line with the explanations of Agile. Everyone does Agile … differently.
³ Assuming you can get the functions to stop being cross long enough to collaborate.
⁴ Probably back in your day, too. But back in my day, everything was in black & white.
⁵ They love having it available, they hate writing it.
⁶ “Strong opinions, loosely held” etc.
⁷ Yes, a mixed metaphor about things that famously don’t mix.
⁸ In the sense of how one (incorrect) way to test the doneness of pasta is to throw it against the wall and see if it sticks. Much like many brainstorming sessions.

Previous
Previous

Everyone is a Designer

Next
Next

Just What The Heck Is UX?