Working Agilely... With Agile? Whatever...

I talk a lot about working with other teams, satisfying the business owners and making sure your work as a designer is consumable by implementation and test. But when I started typing a response to this question on a LinkedIn group, I realized I hadn't really gotten tactical enough in some of it.

The basic question is a good one, I have answered many times internally. "How should UX work within Agile development processes?"

The common refrain from other UXers is to follow Jakob Nielsen's suggestions on the matter. But I find that doesn't work well at all, actually.

I've worked on several dozen (large scale) serious Agile projects and have developed ways to make UX work within them.

First: The IT process gurus they hire are, not to put to fine a point on it, idiots. I have asked such pointed questions of them in kickoffs they were fired and never came back. (Yes, there are also good process guys, and I have actually worked with some to develop the processes below. But process consulting has grown too much in the past 10 years or so and will put anyone through a 2 week course. If you are a process guy who is offended by this you are not a good one, or you'd be annoyed at your many awful colleagues.)

The key problem is that everyone who loves Agile likes to conflate "iterative" and "incremental." Look it up. It's scary. What it means is that a LOT of projects are Agile in name only. They break up development into Sprints, they have their daily Scrum, etc. but the end result and the day to day work is the same as it always was: developers go off, write a piece of code for as long as it takes them, never come back and add to it again, and just toss everything over the wall to the next team. Waterfall in all but name.

But let's assume the process is practiced correctly and is not a bad choice. By the way Agile is practiced even correctly, design is rather left behind. The best that can usually be hoped for is something like this:

You can see Design phase, but they are for software design, and are far too late and constrained for user experience teams to influence the course of the work.

A common retort is to have UX help in the planning phases, and be deeply involved in the iterative design phases, but spend at least half their design time each week working on the next iteration (if iterations are longer than a week, just replace the word “week” as needed).

This is the version where UX gets to do their work 1 iteration ahead. It is clearly wrong. It never works in practice because you end up working on the current and next iteration. Not only is there not nearly enough time to do the work, but it leads to methods (by PM, IT, and you) of solving today's problems, and having no holistic view.

Really its... okay. I’ve done it, with measured success, but it’s not truly satisfactory.

In fact, when I worked previous model and evaluated success (when I talk about whether process works, I mean it; I actually do AARs and run stats on my projects so know when things work or don't), I eventually realized I had a bug in the data. The best part of the results were from the early planning I helped with.

In Agile, two things are pretty solid, from the original planning: the timeline, and the original plan itself. The list of features is completed in week zero, during that planning phase. Many software design documents are completed here, and are almost completely stuck to throughout the process. So, what’s wrong with just adding UX deliverables to this?

As it turns out, a few things. Even there, IT definition processes can get ahead of design and business needs. UX design needs to make their basic plan during the phase before this when business requirements are being developed (and even help make them). Then, additional details of interaction design, fixes, and guidance can be offered throughout the rest of the process.

So I added time to the process! No. I didn't. Agile is not a project plan, it's a development process. There's other work before Agile exists, and I just say you need to get involved up here. Yes, I reframed the question. Tricky, aren't I? Anyway, months earlier is ideal, but I'll take a week if that's all I can get.

Note that I’ve make UXD (and IxD) a whole new bar in the chart. That’s because the holistic view and the work on multiple tracks mean they work more at the PM or business owner level, and work with – but not within – several individual phases, all at the same time.

If you think this will be hard to sell, read up on the process again. If you approach it right, and use their terminology, and offer to help with Sprint 0 deliverable development, you can sneak this in, effectively. You aren't adding anything to the process, but are complying with the original Agile intent much more than by trying to shoehorn UX into each iteration. Process guys will sigh when you introduce yourself as the UX guy, then love that you are just gonna work in their process and not insist they add time or phases.

What about user testing?

Okay, one more thing is that you can still do iterative evaluations and fixes. But not as much as Nielsen's article would have you believe. Agile projects rarely push something usable with every iteration. If you attend the planning meetings, you can figure out which ones are big, can make friends with test and get access to the test site to run people, and try to get some feedback during the project.

What can you do with it? Well, I say not much. If it's more than minor, then you will want to change stuff that is architectural and that's planning or featureset stuff. That's hard to change on a dime (maybe XP can do it, but we're talking Agile). Usually, I just gather the data, analyze it, and only raise issues if they are critical enough I think it's worth arguing for more time. Otherwise, I go to the product owner and make sure we can have a second phase.

The closest this gets to ideal is that there are a handful of phases with unassigned features at the end, and whether it's after the initial launch or not, you can go off, make your revisions, and get them slotted into these last phases with the same team as a rapid maintenance release. This can work, but you have to know the process, and be able to talk the language to make it happen.

And in case you haven't figured that out, if you get in early enough, you can do the normal design process stuff, and take months to do competitive analysis, do needs research, come up with paper designs and A/B test them, or whatever makes you happy.

Regardless of the development process, I say the greatest benefit UX can provide is the moment after the project is a glimmer in the program manager's eye, or when the data comes in that implies a revision/improvement is needed. If integrated well, or engaged at the right time, UX has done a lot of it's work before any IT Dev process has even begun.

And I have successfully done this many, many times.

If those diagrams above are too small, you can get a PDF of them if you'd like.