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.

Influencing the Requirements Process - Designing Documentation, Part 2

Specifications are hard. There are a lot of conflicting needs, and the complexity of the documents might be more severe than the product you are specifying. Aside from designing products or interactions or interfaces, I spend a lot of time designing the documents themselves. A happy ending to this sort of process is detailed in last week's post on Designing Requirements Documentation.

Which might bring up the question: What type of specification? Design documentation, which is most of what we do (well, by hours – most actual documents by count are proposals and emails and so forth) took a long time to settle on, but it has evolved into something pretty specific and which works very well to communicate to everyone on the entire project team. There have been several evolutions, many mandated by technology alone; I used to do everything as a single sheet which functioned as sitemap and flowchart and detailed page/state layout. But when I had to work with more remote teams getting 36" x 10' pieces of paper to them was more difficult and had to change to something else.

But complete technical specifications are still something else. There are also content specifications, style guides, and lots of other documents. But today let's talk about the general technical specification, that developers use to build or modify software or presentational code to meet your design needs. Integration of technical specs with design has always been an issue. I've spent a lot of time messing with my deliverables to make them comply, or revising them to be pasted into the appendix of an IT specification. All of which is fairly unsatisfying and never helps much.

It is also important to believe that design documentation is good, important, valid work. We spend a lot of time buried in IT process, and I have to fight even people here at Little Springs to make them believe that our work and our method of work is valid. Sure, you can use IT requirements documents to do your work, but that's not their intent, and there are better ways to do it.

After a lot of work imposing myself and my team into the development process with our own documentation, way back around 2002 – while working at Sprint, I got to work my design documentation directly into the technical specification. At the time, Sprint IT used something called Application Design Documents, and I was able to persuade them that the UX team could do the best, most efficient job of making some of the document.

Note that the text and tables are in the IT format, specifying the behavior of each widget in a specific manner. And the screenshots (I prefer other methods, but this is what they could handle at the time) are placed in a process-compliant manner, but there are just about 20 times as many as usual. I also did a lot of the writing, or at least editing, of the specifications, so when it was done both the IT analyst and the whole UX team agreed on the behavior of each and every feature.

This product, both by design and implementation, was a high-water mark in ease of use in my career. Web-initiated SMS with millions of uses a day, without a help system and hardly any error messages, with impossible uptimes and no measurable customer complaints. Almost unheard of for a mobile telecom operator, at least in the US. And although it took forever to create the document, some of this was simply getting everyone involved used to the new process, and we saved a lot of time correcting errors and explaining stuff in development.

But then that dream died. After a few months of work, a big fire-everyone-for-IT-outsourcing binge left disappointingly few software designers and analysts in house. I had to start all my relationships over and reconsider how all deliverables would work with random, far-away teams using them. So for the next few years I made do by improving my design documents, communicating with project teams as much as possible, and actually writing requirement documents when I could.

Writing requirements

Which became a key task I tried to accomplish. If the UX team got engaged early enough (which is always a problem) I pushed to review and approve the requirements. Then I found out no one wants to write them, so simply volunteering gave the UX team lots of additional authority.

A key reason I like working on requirements is that they are often poorly done. For example, Business Requirements and Functional Requirements are too often conflated. A BR document is very, very high level. It contains the goals of the project, and rarely more than a couple dozen, or that's a sign you either wrote them wrong or the project is too big to be completed. Some Business Requirements you might read are:

• System shall have the ability to allow user to enter a street address and geocode it to a dynamic map displaying coverage and signal strength.
• System shall have the ability to drill down from a national map perspective if no address on file for user (i.e. in-front of log-in).
• System shall have the ability to allow user to enter only a ZIP code and geocode it to a displayed map.
• System shall have the ability to allow user to enter an intersection and geocode it to a displayed map.
• System shall have the ability to allow user to enter a City/State combination and geocode it to a displayed map.
• Etc.

But this is dead wrong. System? And so very many. That's a set of Functional Requirements, and not a well-written set at that. But all is not lost. Assuming that the marketing and product people like these, you can redo them as actual requirements. A typical, well-written Business Requirement could read:

• Allow customers to find coverage for a specific area in multiple ways: by entering a general location, a specific street address, an intersection, two locations, etc.

And this covers all those bad requirements above, and then some. Cases you don't think of at the beginning of the project are still in scope. A half dozen more like this and you have a project.

Functional requirements

A Functional Requirement on the other hand provides specifics of technical, logical, or presentational behavior. These are also boring, so often don't get enough attention. Oh, they have to be written to proceed through the IT process, but no one wants to do it, so they get poorly written. If you want to make sure the product gets built right, and that the implementation teams are doing what you designed, just insert yourself in the process.

Good Functional Requirements look like this:

FR-40 From within the Wired Web unified messaging access portal, a function will be provided for customers to move SMS messages between folders, (e.g., Inbox, Outbox, Spam).

Better written Functional Requirements help a lot. Some notes about requirement writing were in the earlier blog entry, so I won't repeat them here. But they better not all start "System shall" or "Ability to." Even if it's nerdy, academic, and technical, with otherwise annoying neutral-voice characteristics, use good english, first and foremost. The above requirement is written the way I like them all to be. First, the condition or state From within. Then, who can do it, here the customer, but the system may automatically do things at certain times or when certain conditions occur. And then, what happens. Pretty generally. An example of the folders are given, but there's not a requirement for each folder, and a comprehensive list is not given.

Not just because this would be cumbersome, but because it would be wrong. Remember, there are other documents and other requirements. The structure of the folders here is likely described in some architectural specification. So as part of this writing, be sure to understand the scope of the document, and how it works with the many other documents that are part of the IT process upon which you have imposed yourself.

The product is more important than you are

And after all that, it is a bit thankless. Your name will probably not be on the document as an author, and everyone will credit the analyst, who may not credit you. That's fine. Often, it's preferable, since UX is viewed with dark suspicion by parts of the organization.

Even as a vendor, we pretty often deliver work in someone else's template (or, have to create one that looks like the client's brand).

Getting the product right is most important; work on how your team is perceived later. Which is probably a good topic for another post in the future.

While I won't be hosting a process workshop at this year's Design for Mobile conference, there's plenty more to learn about mobile design, technology, strategy, research and implementation. Still some space available, so join us in Chicago next month.