Monthly Archives: December 2012

Agile UX Health Check

When adopting a new way of working, it’s natural to use what you currently know as a starting point, and to frame questions about the new thing you are learning using the terminology and perspective of the old way of working.  So, if you are a UX designer coming from a traditional UX background, which tends to have a strong process focus, it’s no surprise that you may be asking questions like “What is the Agile process?  And are we following it?”

These questions may seem innocent enough. But it’s actually not too different from asking “Where on the bicycle does the steering wheel go?”

Bike with a steering wheel

If waterfall is like driving a big clunky car, and Agile is like riding a light-weight bicycle, then applying waterfall thinking to Agile might look a bit like this. (Source: Bicyclog.)

Now, in the case of the bike, it’s pretty obvious the question doesn’t make any sense.  But it can be far less obvious to someone new to Agile that there is no such thing as a specific Agile process.  The “process” in an Agile world, is a continually emergent path forged by a self-organizing team, not too different from E.L. Doctorow’s famous description of novel-writing, that it’s “like driving at night in the fog. You can only see as far as your headlights, but you can make the whole trip that way.”

What matters is if the team is equipped to forge this path and make good progress toward their destination. What matters is if they are able to collaborate and communicate in an effective and healthy fashion.

As an Agile UX coach, when evaluating a new team or organization, I usually conduct a kind of informal Agile UX health check, in the form of a set of core questions.  In some cases, I ask them outright to members of the team, in others it’s just something I’m asking myself.  Among the innumerable possible questions one can ask in assessing a team’s health, I have found the questions below to be an effective barometer of how well they work together and their ability to deliver a high quality product.

How early do developers become actively involved?

By developers, I am referring to anyone participating in making the actual product. By active involvement, I mean direct participation in product research, design, and implementation.  Sitting in a meeting watching a presentation of work someone else did is passive participation and does not count.

A traditional meeting, with mostly passive participation

Here is a standard waterfall-meeting from hell, with basically zero active participation.

A developer who is actively participating in early design work can often do something most designers can not: they can tell you when starting to build the product will be more valuable than continuing to imagine and describe it.  They will help you fail faster and keep your ideas closer to the proverbial rubber hitting the road.  They are also often able to offer ideas for solutions that a non-developer may not have considered.  Just as importantly, early active involvement helps reduce the destructive Us/Them relationship that so easily emerges between designers and developers when they work separately.

But like many things worth doing, this can be damn hard to pull off.  Active involvement by developers early in a project, ideally starting on day one, requires an organizational culture that sees just as much value in developers participating in sketching and exploring the product experience as in having them code that experience.

It also requires that developers themselves believe in this way of working, which will usually also mean that they’re going to be more attentive to experience quality in general while building on the product.  And that is basically priceless when it comes to delivering a well-designed product. Because no matter how good a UX designer may be in defining a great experience, the buck will ultimately stop with the coder.  They make the final atomic-level choices about how the product will work.  They fiil in blanks where design documents fall short, or, for better or worse, choose to ignore them, in trying get a feature out the door.

Successful Agile UX adoption, in other words, is not just about transforming how UX designers work, but how the whole team works, particularly developers.  If they are actively involved early on, that is a clear indicator of healthy collaboration.

Do UX’ers also code or design?

While having developers participate in design work is great, collaboration in an Agile UX model is not a one-way street.  It is just as important for UX designers to be crossing the design-engineering chasm in the opposite direction. The degree to which they do this is another key indicator of Agile UX team health.Bridging the chasm between design and engineering

The most common and least healthy pattern I see in this area is the UX designer who strictly does UX design and nothing else.  This is like only writing recipes but never actually baking any cakes.  Being a coder or a visual designer in addition to doing UX means you have a much more multi-dimensional perspective on the product.  It also increases your empathy for the effort of other team members, and reduces communication churn.

And I’m talking about production-grade coding or designing production-grade visual assets. That is not to say that there is no value in having UX designers code and design throw-away prototypes.  It’s much better than nothing at all.  But getting back to our cake analogy, that is like creating a plastic model of your cake.  We can look at it and it may have some benefits over just reading a recipe.  But we can’t eat it.  We can’t truly experience it.

The point of doing production-grade coding isn’t just about the coding part, it’s also a social and cultural thing.  When you are checking in code, when you get to see automated tests puke out all kinds of errors, when you at some point break the build (and you will break the build at some point), and pair with another developer to figure out the problem, you are collaborating on a completely different level than if you’re building throw-away models.

How does the team determine if the design is good?

The method by which a team decides if a design is of sufficient quality can be very revealing of their general health and effectiveness.  Traditional teams tend to use approval from a client or a business sponsor to determine if the design is good.  Quite honestly, this is an area where many Agile teams fare only somewhat better, with the concept of Done.  Done is basically a judgment call made by the team, and ultimately by the Product Owner, as to whether the team should stop or continue work on a feature.  It’s great for helping teams make decisions and move forward, but it can also lead to shipping half-baked crap.

Yes, the feature you shipped may technically support what the customer asked for, but oh boy is it ugly and a pain in the ass to use.  Some developers like to talk about how what really matters is that the features do what the customer requested and that everything else is icing on the cake.

To all those developers, I would like to thank them by serving them the following fully functional meal.

MRE Pork chop dinner

Ready-to-eat-meal, which technically contains all the ingredients of a pork-chop dinner.

Technically speaking, it contains all the ingredients of a pork-chop dinner, but oh-my-gawd does it look awful.  And eating it ? Gaaaaaaahhhhh.  (Yeah, yeah, yeah, I know this is for wartime consumption on the battlefield, but you get my point.)  Compare this to a pork-chop dinner you might be served in a good restaurant, one in which presentation and all kinds of intangibles have been tended to.  It looks good and is a pleasure to consume.

Pork chop dinner

A pork chop dinner that looks good and is a pleasure to consume.

So, getting back to our original question, how do we determine if the design is good.  Well, the only real way to know if a design is good is if actual users are f*ing using it.

This is one of several areas where Lean Startup can come to the rescue.  We use metrics and other forms of validation from real or prospective customers to measure whether or not a feature is good, or just as importantly, if it sucks.  Too many times UX designers and clients get so wrapped up in their own “succes theater” (my favorite Eric Ries phrase), that they convince themselves of the brilliance of their own ideas, when in fact it may or may not have any basis in reality.

Does the team have a co-location mindset?

Co-Location is a state of mind

There’s a lot of talk in Agile circles about how everyone should be working in the same room.  Well, guess what, you can put a bunch of people in the same room, but if they aren’t used to working that way, if they’ve been sitting in cubicles their entire working career, you may end up with a bunch of agitated wrecks who want nothing more than for everyone else to get out of their hair.

What’s more important than being physically co-located is to have what I call a co-location mindset, which effectively is the ability to communicate as if you were face-to-face even when you’re not.  A great indicator of a co-location mindset is when the team can maintain a low bullshit-to-content ratio in their virtual communication.  For example, rather than needing to formulate long-winded emails intended to really only ask another team member a single question, you can just pop up a chat window and (gasp!) just ask the question.

In other words, a team scattered across the planet that communicates openly and frankly and without a lot of ceremony is more healthy in my book than a co-located team where everyone is walking on eggshells.  Now, don’t get me wrong, achieving fast high quality communication is often much easier when you’re co-located.  Just don’t assume it will happen automatically because everyone is in the same room.

Is the whole organization participating in the Agile adoption?

A team within a larger organization is not an island.  They are part of an inter-connected eco-system, and you can’t try to have just, say, the design department of a company “go Agile.”  So a key question is the degree to which other parts of the organization also are adopting Agile methods.

Many of them are parts of a company you’d likely never associate with Agile and, as such, are hidden barriers if they are not part of the overall Agile adoption.  Here are some of the more common Agile bogey men that might be lurking in the dark corners of your company.

Let’s start with Business Development, basically the progenitors of new project work.  During this initial phase, there often is high-level phase-based planning that occurs, with research folks only participating early on, and developers not scheduled to be brought in much later in the project.  In other words, you’ve basically been locked into a waterfall project before you’ve even started.

Another great example is the facilities group.  Agile is very much about allowing teams to shape their own physical workspace around their own needs.  However, for that to be possible, whoever is in charge of room setup, desks, meeting rooms etc. needs to understand the value of empowering teams in this way.  What often is the case is that the individuals in charge of facilities and building logistics are far removed from the Agile adoption, and trying to get them involved can be a major bureaucratic headache.

Last but not least is the IT Dept.  You’d think that they’d be your closest ally when it comes to adopting Agile, and that may often be the case, but don’t assume it.  Don’t even assume that they have adopted Agile in the first place.  And if they have, don’t assume that the flavor of Agile is one which will welcome UX designers into their midst.  In many cases, what they are really practicing is Agile-fall, where they certainly do practice Agile methods when it comes to the coding part, but when it comes to the experience part, they still expect others to tell them and preferably specify in detail what they should build.

There are several other parts of an org that can be a hidden barrier to an Agile adoption, such as HR or the marketing dept. The fewer of these that are involved, the less healthy your adoption is likely to be.

How did you fare?  Was this a useful health check?

With this health check, few teams, especially those in a large organization, will get a perfect bill of health, but it is a great goal to strive for and a helpful measuring stick in determining how well your team is doing.

How would your team fare in answering these questions?  What other question do you think should be part of an Agile UX health check?  Let me know in the comments, or via the Twitters!

(Originally a guest post on the Hypenotic blog, as part of the UX in To workshop series.)