Is Focusing on Agile or Lean Damaging the Practice of UX? Part 1
I was one of the contributing experts quoted heavily in the latest Ask UXmatters Get expert answers columns. But in reading it this morning, I think it might need some additional explanation before I get letters. I answered very narrowly, so might end up sounding very, very negative about simply everything.
I keep seeing discussions of process where not only is UX blamed as usual, but even the concept of our disagreement with process, or the state of the industry, or the resulting products it itself a negative feature, and we’re inherently bad people, doing it wrong. So, some more framing:
But First, More About Me
I have been doing this simply forever. I have been paid to do graphic design for around 35 years, used the Internet for at least 31, and built my first website 25 years ago. Not long after, clients started demanding them instead of things like CDs, and I became a self taught “web designer” as well. I’ve designed (and sometimes built) not just Web, but mobile apps on a dozen platforms, databases, APIs and services, control panels, hardware, emails, SMS response, IVR, and more that I can’t even remember now. I get the tech and have actually run development teams.
I have worked at agencies big and small, local and giant-German-congomlerate, in advertising, marketing, and digital-specific solutions.
And, I have worked in, or for, almost every type of corporation, from startup to Fortune 50, in every industry but gaming (why never gaming?!), on several continents.
I’ve done probably a thousand projects; I counted over ten years ago and had done hundreds then, and 150 Agile ones back then. Since then, many more, and more training. Lacking a national standard so I can show my certificate and sit it out, I’ve had full, multi-day training on Agile six times. Aside from working with the many flavors and custom spinoffs of agile, I’ve done Lean, XP, Spiral, Rational and… I forget. So many others. It’s never happened that someone describes a process or methodology and I have not worked in something at least functionally like it.
I learn. You know me, I read everything and research that I don’t understand fully, but also go to conferences, to Meetups. I have tried even more, gotten the word and the take home packet, and heard some success stories of the new thing many times as well.
Flexible and Collaborative Works
I’ve done some very good projects, and one thing I have learned from decades of this is that every project is better off not alone, embracing the wants of clients, the constraints of technology, and the needs of end users. Every one. And this isn’t new. We’ve known it from the print graphic design era onward. It’s baked into deeper processes I learned later, like human factors engineering that are closing in on 100 years old. That makes them a lot older that software development. Our ancestors pre-date the computer itself.
Every organization is different. Every client, every customer, every user. So the method required for every client or organization has to be different. But very often, I change even more. I change to match needs between projects within an organization.
The best methodology matches the needs and capabilities of the organization, and always has. I have written on ideal process, and started 20 years ago as I had to make up my own, long before we were called “UX” and there were UX processes like the UPA chutes-and-ladders chart. But then I learned not to be so rigid, ever.
I have worked a long of successful projects, and built teams within, lean/agile/Agile organizations. Good ones. Ones I am still proud of. I am going to repeat that part, in bold, for everyone who thinks I am negative and hateful, and just don’t understand their flavor of agile:
I have worked a long of successful projects, and built teams within, lean/agile/Agile organizations. Good ones. Ones I am still proud of.
If there’s anything I am pretty rigid about, it is results. And the simplest way to say what results must be like is “quality.” Not pretty, or on time, or with small and consistent panel gaps, or unlikely to break or crash, but the economics definition of quality, where it meets the needs of everyone. You can — and must — even scale that up and down, and it then automatically encompasses MVP-like thoughts.
Quality is the sort of thing UX does well, because we are a practice area that is data driven, and holistic. We can see the big picture and support project managers in having the right information to make decisions about what gets built now, vs in the future.
Backlogs are great, and organically-implemented lean sorts of methods can improve existing processes. I, and every UXer I know, can support your increased speed, or other needs, if you let us.
I have already done a lot of writing on what I think works, especially from the point of view of integrating design, UX design, and the user into the product design process itself:
UX Processes, Product Design, and Development Methodologies
What Doesn’t Work
First off, objecting to discussing the problems of your process doesn’t work. People negative about methodology, pointing out problems in the trends of the industry are helping. We need autopsies and accident reports to find why people die, and we need open and honest discussion to make sure the digital industry doesn’t spiral down the drain.
Seriously. Everyday consumers are starting to get cynical about technology on several fronts — cost, reliability, security, privacy. We ignore all this, and do the same old thing, or lean harder to what made it bad, at our peril.
I generally say a few things don’t work:
Forced processes. Too much Agile is imposed from outside with no flexibility, and no transition period. You take a week off to train and move the desks, then better start being more efficient.
Measuring progress by speed and completion only. No factory works this way. They also take into account scrap rates — the amount of work that is not good enough to use — and we have a lot of software where scrap rates in a single iteration, or even release, approach 100%.
Making decisions off gut instinct, off information gathered with bad process (surveys, focus groups), or using bad metrics (velocity).
Confusing iterations and increments. Your old process with 2 week increments is not agile.
Insisting on lean/agile flexibility while also retaining old-school schedules with fixed dates, and fixed features at those dates.
Working to a handful of metrics only. Your teams will work to metrics to keep their jobs, and not do what is needed to make good products.
Your only high level decision is “buy.”. Assuming that “build” is always harder or more expensive, and going with off the shelf, turnkey solutions. They either get customized to meet your needs so cost more than a clean-sheet solution, or you change your business to match some third party technology. The customer experience degrades either way.
Shedding everything but development in the name of speed. Ignoring, pushing off, or firing UX, marketing, security, writing, accessibility, regionalization, SEO, customer care, technical support, operations, scale, and everything else that used to make your products good, reliable, and trustworthy.
Now, go ahead and read what I, and several others with deep experience think about the state of UX in the Agile/Lean world:
Is Focusing on Agile or Lean Damaging the Practice of UX? Part 1