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. 
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.
{ 15 comments }
