Is Your Agile Software Process Handcuffing the User Experience Design?

I’m running across a new problem with a number of clients and wondering if my user experience colleagues are having similar issues. The advent of web applications has resulted in a change for many software providers in the way they release software today.

Agile software development is a method in which software is designed, examined and delivered to the market swiftly, so that end-users can provide feedback and more feature changes can be made and adjusted within a few months time, rather than once or twice a year. For off-the-shelf software, such as Adobe, Apple or Microsoft products, this is not as practical a method as it is for web-based services. I’m not sure if large corporations have employed any Agile methodologies or not. The Wikipedia entry describes my issue perfectly:

Agile chooses to do things in small increments with minimal planning, rather than long-term planning. Iterations are short time frames (known as ‘timeboxes’) which typically last from one to four weeks.

So here’s the problem: I am often called in to redesign an existing product, that was designed primarily by developers and managers, and not by an interface or interaction designer, or with consultation by a user experience design specialist who could point out workflow and related product issues, as well as design a product brand identity. And that’s great – this is one of my favorite things to do. Redesigning a product is sometimes easier for me than designing one from scratch, because I can see the technology working – it’s like a live prototype to play with. To take an unpolished, but great idea, and make it even better for the users it was built for, is a lot of fun for me.

Historically, I come in, look at a product, talk about the business and marketing goals, and craft a “big picture” plan for the product line identity, interface design, workflow, help systems, etc. and then the big picture gets broken down into phases and tasks. But look at the Agile description again: minimal planning, small changes, releases every 1-2 months. That allows for feature by feature adjustments, not a total redesign of the workflow, layout, navigation systems, etc.

What’s a user experience designer with a great idea of how to make this product in front of her better, to do now? I don’t have an answer to this yet. I think when it comes to restructuring the workflow of a product to make it significantly better, executives need to understand there is a time for Agile, and a time to redesign, and redesign efforts take more in the range of 2-6 months to complete, in my experience. It all depends on how much is “surface” redesign, such as moving things around on the pages and creating a nicer look and feel vs. how much the deeper code has to be modified because features need to work completely differently than the developers designed them.

As is our habit in the software industry, we tend to look inward and not outward when creating processes that are supposed to make our business run better. Do we need the internal motivation of a release every 4-6 weeks to make things happen? Customers don’t necessarily demand a release once a month, they just need bugs fixed and problematic features redesigned so they can perform their tasks better. Can we design an Agile process that is flexible enough to allow for large-scale design changes when they’re needed? Why do we have to release something once a month? 

How are you handling this issue, user experience designers? I’d love to hear your advice and stories on how to combine Agile with big picture design or redesign approaches. A List Apart offers a wonderful article on Agile Design (below) but doesn’t really answer the “how” to make it work that I am struggling with. Is persuading executives to give me the time I need with developers to make the software better, the only answer?

More Agile & User-Centered Design Thoughts…

  • http://www.burnimage.com Etan

    I think you’re certainly expressing a lot of the concerns other UX practitioners are having with being integrated into an agile process, and it has definitely been covered EXTENSIVELY on ixda.org , boxesandarrows.com , and countless other design blogs.

    One thing to keep in mind is that nobody is doing “pure” agile. Mostly, development teams are using some kind of hybrid agile with their own style.

    In terms of design processes merging with the tight release schedules… don’t do an extended period of up-front design. Similar to the dev style, you should be doing lightweight, quick turnaround designing that you can get rapid feedback on.

    Agile assumes it is impossible to plan software development well enough that you can do a very lengthy software design phase and release something months later. It’s the same with UX design, you need to do shorter cycles, and validate your UI right away (usability, expert reviews, whatever).

    And, just because the release needs to happen once a month, it doesn’t literally mean you release a new version to your clients once a month. These releases are often internal releases that never see the light of day, however they need to be stable enough that it doesn’t blow up if someone tries to use it (or compile it). This is mainly to keep repository commits from containing broken versions.

    My company EchoUser, has a rapid, iterative design methodology that blends quite well with an agile development process.. if you hunt around our methods section, we have some whitepapers on the subject that you can look over.

    See the “RITE” style (Rapid Iterative Testing and Evaluation).

    Cheers!

  • http://twitter.com/kriscolvin Kristi

    Thanks Etan. Actually, several of my clients are literally releasing every 4-6 weeks. And when the shell design and workflow just isn’t right, doing small-scale design changes often doesn’t address the root of the problem, which is usually workflow and task presentation-related. I’ll look up your whitepapers and see how you’re addressing this issue. I actually like the Agile method for usability testing, because of the iterative nature of having a working product to test on, and then making improvements fairly quickly. In the context of feedback, the Agile process works quite nicely, but that is not something I went into here. Thanks for your comments!

  • http://www.burnimage.com Etan

    Perhaps we can discuss this in the context of an example? Let’s treat this issue as a kind of case study.

    Can you provide a hypothetical (or real if you prefer) example where there are task / work flow design issues that you have already detected that can’t be addressed during a short cycle (of one month) in some form or another? What would you normally do (outside of an “agile” environment)?

  • http://twitter.com/kriscolvin Kristi

    Actually, I appreciate you saying this, because in one scenario I have, we are definitely having to hold off on major workflow redesign because it is a bit bigger than could be done by dev in one month (would probably take a couple of months) but also because there are so many competing requirements – all of which are very valid for the business – that to get many small things done vs. this sort of larger, over-arching thing done has been the preference.

    In another case, we are doing exactly what you describe. We’re adjusting the framework/navigation, giving a cosmetic upgrade to everything, but only improving the actual deeper workflow problem in one or two features. A month is still an excruciatingly short time in which to develop the changes I’ve prototyped, test and release it.

    I guess my follow-up question would be: how buggy is stuff that goes out so fast? :-)

  • http://twitter.com/kriscolvin Kristi

    I think I opened a technical can of worms, because I asked this question on LinkedIn, but I realize my point is more philosophical. My clients aren’t doing Agile “wrong” – the system is working for them and they have solid QA. I think *I* am more of a “point & version” girl. I love the idea of major and minor releases, and am quite comfortable planning features accordingly. I like doing small feature adds, feature tweaks and bug fixes in minor point releases, and major feature splashes, with all the marketing hype that goes with it, to get new customers and existing customers excited about what is coming and what is being released. I have often either been the marcom (in small software companies) or worked with product marketing & marcom in large companies, on all this planning, design, approach, customer outreach, etc. and it is the system I am most comfortable with I realize now. I’m sure I will have to get used to this, because as I pointed out, it’s just now become an issue for me as more clients have moved to this process.

    I read Jeff Patton’s article (added to the links above) and it is excellent – I do 90% of those things now though, without Agile. My prototypes tend to be exact replica’s and with notes serve as specifications, and that is one thing we’ve done to save time and help developers understand what the end result should be. I still think an element of persuasion to deviate from this process is needed when something is going to take longer than a cycle to produce, and that indicates to me there are some issues with using the Agile process.

  • http://nomadnetinc.com/blog/ Dave Sherohman

    Speaking as a developer rather than a designer or UX specialist…

    I have a hard time accepting your assertion that there are interface changes which a) will take over a month to implement and b) must be released atomically (i.e., “all or nothing”). Even if it’s a major workflow overhaul which needs to be presented to the users as a single changeover, the underlying functionality can still be developed in month-sized chunks until it’s ready to support the new workflow while keeping all those changes behind the scenes (at least as far as the public UI is concerned), then, when that’s ready, 4-6 weeks to change over the interface all in one shot should be sufficient.

    In the ideal case, there would also be a separate project running in parallel to prototype the new UI and get user feedback, usability tests, etc. via Agile methods (as mentioned in an earlier comment) so that it’s all ready to be put into place once the back end is prepared to support the new workflow. Unfortunately, in the real world, there rarely seem to be the resources available to allow this.

    On your side question of how buggy Agile code tends to be, the answer is “not very”, for two primary reasons:

    1) Automated testing (and, often, test-driven design) figures prominently into Agile methodologies – it’s often considered one of their defining characteristics. A good test suite helps to find and fix bugs quickly, then ensures they don’t return.

    2) Shorter release cycles mean less time (and fewer new features) for bugs to creep in on each release. They also mean that, when bugs do appear, they get fixed faster.

  • http://twitter.com/kriscolvin Kristi

    Dave, thank you!!!! I can definitely wrap my mind around getting done what I need within an Agile process by doing this:

    “Even if it’s a major workflow overhaul which needs to be presented to the users as a single changeover, the underlying functionality can still be developed in month-sized chunks until it’s ready to support the new workflow while keeping all those changes behind the scenes (at least as far as the public UI is concerned), then, when that’s ready, 4-6 weeks to change over the interface all in one shot should be sufficient.”

    Thanks for this feedback!

  • http://www.flyover18.com Christian Thilmany

    I will be speaking at Mix 2009 about this very topic and how some tooling may aide in integrating the two process models (UX and Agile/Dev). My slide will be up on slideshare.net shortly. I have to side on the first commenter Etan. Although some larger architecture components can’t be fully shown every month they can be discussed, layed out, and certain elements can be developed in an agile fashion with the use of certain design patterns such as facade and mocks. Without getting too nerdy it is possible. And Yes large orgs are using agile more and more as my job was to improve those processes for them at Microsoft. One of the largest computer manufacturers in the world are almost completely agile now (I’m sure you can guess who that is). ;-)

  • http://www.flyover18.com Christian Thilmany

    I also will be bloggin about ALM and UX on http://www.flyover18.com.

  • Bora

    Can’t help but wonder whether we are the cause of this article lol :) It’s turning out OK Kristi, thank you!

  • http://twitter.com/kriscolvin Kristi

    Hi Bora! You are definitely one of my Agile clients, but I have several others. I am just trying to understand how to play with this unfamiliar process… iterative, I am somewhat used to, but not the precision of the schedule. I cannot WAIT to see how the product we’re working on is coming out! We will figure it out, I am sure. :-)

  • http://www.commadot.com Glen Lipka

    Agile, to me, is summed up with the words “Embrace Change”. I’ve been in Waterfall, Agile, and Fragile processes. (Fragile is like Agile but without any of the discipline and totally chaotic). I believe the key to success is the willingness to change things based on gained knowledge and wisdom.

    It sounds like your method of fixing the UX is to do a waterfall project. (2-6 months) It totally depends on the organization and the product, but if the product has alot of pieces you could improve the UX in smaller chunks with an agile release schedule.

    I love the big bang approach myself and sometimes it’s the only way. But its not ALWAYS the only way.

  • http://www.fluidnewmedia.com Ahad Bokhari

    Hi Kristi,

    Found your blog from your twitter profile. Wanted to say i that i also find the redesign of website/application much easier than to design from scratch and that has become my speciality these days.

    Naturally 2nd and 3rd generation websites are challenging to rebrand as clients have been through their first most probable “bad experience”. They realize that they actually need to dish out some cash and get it done professionally.

    We have also established an agile web development team and much like yourself are trying to get with the program! I’d have to agree with @Dave Sherohman about why Agile code is less buggy – it does make alot of sense.

    Well thanks for the great reading and your insight into the universal experience! Excellent and well thought out content! Many thanks…

    Ahad
    http://blogspot.fluidewmedia.com

  • http://www.christopherritter.com/ Christopher Ritter

    Hello!

    I found your blog from your Twitter profile as well, and wanted to thank you for validating my experiences with the Agile Method! (I thought I was going insane all by myself.)

    As a UX Designer, I wanted to give a +1 to the developer who recommended a prototype being developed alongside the product. We have had some challenges with developing usability in tandem with new features, and are currently developing a prototype that will be wired into the main product as part of the sprint.