Why Agile UX is Meaningless without an Agile Attitude

Imagine yourself walking down a fictional hall in a fictional office building and passing two different offices.  In the first office sits a UX designer, busily plugging away at a deck of wireframes, preparing to review them with the rest of the team.  In the second office sits another UX designer, also busily plugging away at a deck of wireframes, preparing to review them with the rest of the team. At the surface level, these practitioners appear identical.  And yet, they are worlds apart. Me as my former traditional designer self and my present Agile designer self.
The first designer, as he is working on his wireframes, thinks of them as a clear representation of the user experiene layer of the final product.  He is expecting to present them to the development team and then for the development team to build the UX layer, mostly according to the design, perhaps with a few minor tweaks down the road.

The second designer thinks of his wireframes merely as a starting point for the design of the actual product.  He sees them more as sketches rather than specifications.  If developers were to respond simply with a “looks good” to his work, he would be worried indeed. He intentionally only a spent a minimum of time working away from the rest of the team, quickly generating a few UI concepts, and is now expecting to collaborate with the team to evolve them.

These two designers represent the essence of what sets a traditional waterfall approach apart from an Agile approach.  If you think being Agile is about doing daily Scrums and Standups and doing Story Mapping and Retrospectives, think again. They are nothing more than tools. Going through the motions of these activities without understanding the thinking behind them is like speaking a language without knowing what the words mean.

No, the true power of Agile is not knowing Agile activities inside and out or being able to recite the Agile Manifesto by heart. The true power is in understanding the underlying thinking, the attitude toward software that fueled their creation. And at the end of the day, as Jim Highsmith and others have said, Agile is no more than an attitude, a mindset. In fact, you are likely to find greater success when starting out with Agile by ignoring the well-known Agile activities and principles and to continue working the way you currently work, and focusing instead on only one change: your attitude.  That shift, in turn, will drive change from within your current practice, rather than attempt to impose it from the outside with some activities you read about in a book.

So how can one develop an Agile attitude?

First, let’s be very clear, changing your attitude when it comes to adopting Agile is about changing your habits, changing your mindset, changing what you see as a Normal way of working.  And that is unlikely to happen overnight. In fact, that first designer at the beginning of this post is me about ten years ago and the second designer is me today.  Now, that’s not to say it will take a decade to change your attitude. In fact, among the many changes, here is one central change that I made and which worked for me.  More importantly, it is something you can start to put into place now

Stop Designing Alone

For a number of reasons, many UX designers are strongly conditioned to design alone.  This unfortunate yet common pattern is perhaps the single greatest obstacle in allowing for developing an Agile attitude.  Among its many detriments is that it perpetuates an Us/Them mindset and that it makes ritual-free rapid communication, a cornerstone of Agile, nearly impossible.

A common working-alone pattern is to first gather information from team members and stakeholders, and maybe do a bit of whiteboarding with the team, and then go off and create the “real” design in your cubicle with your headphones on.

Designing is a process of making innumerable micro-choices, and as software systems become more complex, each choice needs to be looked at from multiple dimensions.  When you are working alone with your headphones on, you are making one-dimensional decisions: yours. Perhaps you spent hours and hours designing a custom UI solution, only to learn that an off-the-shelf solution already exists. Perhaps you made some technological assumptions about what is and is not technially possible, only to learn that something you assumed not possible in fact is possible or vice versa.

Yes, focusing on a problem alone can have value, but usually only in brief spurts.  Hours and hours of alone time is almost guaranteed to equal an increasing percentage of waste. So how do we stop designing alone and start designing together?  Two inter-related patterns for addressing this are Cross-Functional Pairing, which I’ve talked about before (and others have as well), and Active Collaboration.

Collaborate Actively, Not Passively

How many times have you presented a UI concept to team members, in which they are all sitting around a conference table, leaning back in their chairs, occasionally nodding in acknowledgment of your ideas? How many times have you then had them much later raise an issue about the UI that you in fact had discussed during that meeting? Why does that happen?  A huge reason is because they are only passively engaged, which in turn is largely caused by how teams traditionally collaborate, through stale old (and as 37 Signals would put it “toxic) meetings. The attitude is that you were off alone designing this thing, so its your design, not theirs, and now they are taking a passive audience stance, only half-listening, only half-participating.  If you want true participation, you need active collaboration.  And that can be powerfully enabled by implementing a few ground rules:

  • Stop talking about meetings and start talking about workshops.
  • Commit to delivering the real high-level design concept during the meeting. This means actually creating the real design documents as a team, not having you create it afterwards.
  • Commit to creating living documents, i.e. those that everyone can see and participate in creating.
  • Commit to doing detailed design in pairs, not individually.

This will be hard at first for traditional teams, but stick with it.  A fundamental shift will be in the types of artifacts you produce.  You will go from creating document-centered artifacts (i.e. those in which the document is expected to contain the primary information) which are time-consuming and anti-agile, to conversation-centered artifacts (i.e. those in which documents are designed only to support conversations, which are the primary conveyors of information), which can be created and updated in the moment. Over time, you’ll start to see a change in how your team works together, and a change in attitude, toward one another and toward the design of the software as a whole.

19 thoughts on “Why Agile UX is Meaningless without an Agile Attitude

  1. Pingback: Inner West LIVE

  2. Virginia

    What about the research that was done to help create these “alone” designs? Where are the customers to provide their feedback?

  3. Anders Post author

    Hi Virginia, not sure I understand your question. Research is equally critical in an Agile model, though it might manifest itself differently. For example, you may do far less research up-front, instead making research more of a continuous activity throughout the project lifecycle. And as far as where the customers are, they are hopefully easily accessible and in continuous contact with the team to provide feedback.

  4. jef

    great post, anders. i think this is one of the most overlooked aspects of successfully working UXD into an agile environment. process and tools are important, but these are easily learned and ultimately ineffective unless you are open to the collaborative/iterative mindset that is at the heart of agile.

    the flip side to designers making this change is, of course, that developers need to learn how to work with designers. i think that while most developers understand the value of good design, they don’t necessarily understand what it takes to get there and how it can be collaborative. talking about some special design process and producing reams of static artifacts only makes the problem worse. working collaboratively, showing a degree of technical competence, and producing artifacts that are actually useful and usable, however, make the process less opaque and ultimately produces a better result. while some might complain that this is “design by committee”, in my experience that’s usually a reaction to bad design/process and poor design leadership, rather than symptomatic of an intentionally collaborative approach.

  5. Anders Post author

    Hi Jef – great point about how the attitude thing is a two-way street. Interestingly, I did a workshop at this year’s Agile Roots conference specifically for to developers, to illuminate how UX is equally complex and valuable compared to coding, but is so in a very different way. And yes, a traditional approach to UX will certainly not help in improving a developer attitude toward it. But conversely, I would say that by having UX practitioners move toward developers, or become more Agile, is a good first step toward developers moving closer to understanding the value and importance of UX.

  6. Pingback: Agile UX and The One Change That Changes Everything - Anders Ramsay.com

  7. Pingback: UX Agile Requires An Attitude! « Tales from a Trading Desk

  8. Anders Post author

    Hi Ben – the story card is probably the quintessential conversation-centered design artifact, The purpose of a story card is not for it to contain the actual requirement, but rather for it to be a placeholder for a conversation between the author of the card and the reader. In other words, it intentionally contains an insufficient amount of detail for the reader to be able to create an actual solution based solely on the information on the card. They need to have a conversation, ensuring that they receive the most up-to-date information at the point when they are actually ready to work on the solution.

  9. Pingback: Jagwish » Is Agile UX is meaningless ?

  10. Kara

    How do you back Agile up a step further, into the product requirements? Do the product managers need to do more work up front to fully define the product requirements and feature priorities in order to make UX and Dev more Agile?

  11. miguel

    This is all great in theory, I’d like to see examples in practice. I’m working on a product now where every engineer is asking for detailed specs and wireframes for the sprints. We are supposed to be practicing agile methodology, but really it’s a hybrid of waterfall and agile.

    How do you create a software product without designing every instance of every screen and hand off to engineers? I’m sure Apple creates a 1 to 1 screen of every instance prior to handing off to eng, that’s the difference between their products and others.

    1. Anders Post author

      Hi Miguel,

      The problem here is not on the UX side, but on the developer side. These developers seem to be practicing Agile in name only. They should be collaborating more closely with UX designers, such that every last detail does not need to be communicated via a document.

      To answer your question, the way to not design every screen is to use templates, style guides, and pattern libraries. Similarly to a how a developer might build a widget once and then call instances of the widget throughout an app, UI specs should work the same way.

      I can tell you that Apple does not create 1 to 1 screens of every instance prior to handing off to engineers, and that they work far too closely with engineers for it even to be considered a hand-off. Instead, they use a style guide-like document called the Human Interface Guidelines, for each of their operating systems and applications. That is a model that is highly compatible with an Agile way of working, in which the team has a shared UI language.

  12. Pingback: Paired Interviews – applying pair programming thinking to user research - Anders Ramsay.com

  13. Anelia

    BMW are famuos for having a very expensive maintenance. Also, try to find out where the person took the BMW for maintenance and ask for the timeframe of having the car taken in to be fixed, and the per hour fee that is charged for it. Sometimes, you need to make an appointment to take the car in and that date can take up to two weeks to get… So imagine yourself, stuck with a busted car, maybe not being able to use it for two weeks until your appointment is due…!

  14. Pingback: UX, Insight, Management And QA Links | crackedhorizon

Comments are closed.