Article: Agile Development Processes: An Interview with Jeff Patton

Jared Spool

September 12th, 2006

UIEtips 9/12/06: Agile Development Processes: An Interview with Jeff Patton

For the last 20 years, a revolution has been underway in the way organizations have developed software systems. It came about from a realization that existing processes for developing large systems were just not meeting the demands of the workplace. Before the revolution, the resulting systems were late and often didn’t come close to meeting the users’ needs.

The result was a brand new set of practices, often called Agile Development processes. Instead of long development times, software is developed in short time boxes, called iterations, which typically last one to four weeks. Each iteration is handled as its own project, with small, but solid deliverables. The goal is get something in front of users as soon as possible.

Sound familiar? In parallel, there’s been a similar revolution in the field of Experience Design over the same 20 years. We started with doing all of our usability work at the end of a project, but we’ve been pushing to get teams to conduct shorter and shorter iterations, with testing and other research techniques moving as far forward into the development process as possible.

Now it’s time for these two revolutionary approaches to merge. While the basic fundamentals are the same, their independent evolutions have made it a rough match. Care needs to be taken to get them to talk to each other.

Seeing the impending collision of these two revolutions for many of our clients, we reached out to a person who has been at the forefront of this thinking, Jeff Patton. Jeff floats (shall we say agilely?) between these two worlds and is our go-to guy when it comes to how you integrate experience design in to the agile environment.

In today’s UIEtips, Joshua Porter and I had the opportunity to interview Jeff Patton about his views. The interview turned out great and I’m very pleased to share it with you today.

Is your organization involved with a move to Agile processes? How have you worked to integrate your UX practices? We want to hear your thoughts and comments. Add to the conversation in the comments below.

Read today’s UIEtips article.

9 Responses to “Article: Agile Development Processes: An Interview with Jeff Patton”

  1. David Malouf Says:

    It is always interesting to hear about success stories that merge Agile and UX. Thanx for doing this.

    I’m afraid though that the methods presented don’t really bring to mind the real issues involved here. UX by its nature is not componetizable the way development can be (actually, it has been argued by technology architects that agile doesn’t work for the reasons I’m about to say for design purposes).

    Applications are systems. You can research and design pieces, but for more successful design products, you’ll find a more holistic approach to design where total language sets are created and managed and used to narrate a story. In order to do this takes time. Now that isn’t to say that you can’t have development working with design on proofs of concepts and other prototyping of technological needs as they come forward, but this is very different from a production lifecycle.

    I find that Agile often puts “expediency” in front of “efficiency” in the way it works at the world. It took a problem, which is development is too slow and quality is too low and tried to fix THAT problem without looking at the total ecolotical effects of fixing that problem. Its like when electrical cables create magnetic waves that throw migratory birds off course and then there is an insect invasion due to lack of birds in the old area.

    Design is not about producing things. Design is about conceiving of systems, languages, and then communicating these ideas. This is done through long hours.

    Yes, you can discount design techniques, but you get what you pay for.

  2. Moe Rubenzahl Says:

    We call it guerilla development and we use it for programming and page / UI development alike. We don’t do specs, design reviews, or formal QA and we charge each developer with quality. It’s risky — you go live with bugs and mistakes on occasion. But the team becomes very, very good at checking their own work and in the end the efficiency is very high and it amplifies the team’s commitment to results.

  3. Tai Toh Says:

    We’ve struggled with integrating Agile methods where I work as well. I work in a medium-large professional services company (consulting company).Has anyone tried to manage an Agile approach within a “fixed-time, fixed-priced model”? The creative design team (as well as development) have been struggling with this concept. A lot of the examples that I’ve seen written about Agile UX are based on product companies, and to be quite honest, the timelines and expectations are very different in professional services.Perhaps I’m not diligent in my research, does anyone have resources for Agile UX in a consulting environment (specifically “Fixed-time, Fixed-price”)?

  4. Dmitry Says:

    I have been struggling with these very same issues for the last few years. We are a custom web applications developer with a big focus on usability/UX.We have gradually migrated to Agile methodology. This year we have developed our first own product – Wild Apricot – association management software using the latest reincarnaction of our Agile+UCD process. We are working on two week cycles and for this product our topmost priority has been to make it work for non-technical users. It has not been easy but I am quite happy with the result so far.
    Really looking forward to the seminar at the UIE conference!

  5. Luis de la Orden Morais Says:

    Hi Tai,

    Have you tried to offset the initial impact when diving into agile by templating your services and sticking to a basic skeleton of services and products that you already know how much will cost and how long will take to re-implement (since we are talking about templates, after the initial development work, most of the work afterwards will de re-deploying it to different clients). This is the bit you could keep fixed both in time and costs, along with your team’s sanity.

    You can create a set of ready-to-use solution(s) that you can offer upfront to clients and go back to the old drawing board whenever any customisation is required.

    Going from a documented and risk-averse methodology to an apparently laissez-faire methodology such as agile is a shock to the system. I have heard of people that developed some weird traumas with much less than that :). But in the transition time, you guys might find helpful to have something stable to stick to as a stepping stone to gradually deeper waters.


  6. Tai Toh Says:

    Hi Luis,

    Thanks for the response. I think the situation is a little more complicated than as you describe. Contractually speaking, the things we develop can’t be templated and redeployed across multiple clients–it’s the nature of the contracts that my company signs–all custom development with a huge focus on visual design and UX. Granted, technology has become a bit more flexible, but a lot of the requirements are driven by the UI.

    Quite simply, we’re so used to designing the UI first. We don’t have that opportunity with Agile. From a coworker:

    Which makes me think that Agile is just a substitute for a good design process, and one that costs the client a lot of money in re-working decisions. I’ve been on a couple of agile projects and it’s difficult to design in slices – the user experience is a combination of all elements and you can’t get part A right (or even signed off sometimes) until you know how part B works. I think it’s probably better value to get the entire design right up-front (on paper) and then roll out the development in an agile fashion, refactoring the design as needed based on user/customer feedback and technical discoveries.

    Operationally, as a consulting company we struggle with things like staffing shortages, skillset shortages and a turn-over rate (while lower than the industry standard for professional services) that makes knowledge sharing difficult.

    We have an Agile process in place that is suppose to be repeatable. Works well with Development, but the Creative Design / UX team has the short end of the stick. It’s hard to slice Design in iterations. It’s even harder to say to a client, “Hi, remember the first 3 iterations, well we made a mistake and have to revisit them all.” This is very hard to do in a “fixed-time, fixed cost” environment. At this point, I don’t know if it is possible.

    Add to the fact that some clients are simply not ready for the rigours of Agile Design (e.g., they are not available, they are not engaged)–it gets messy.


  7. Ed Schlotzhauer Says:

    Following up on Mr. Malouf’s comment: I agree that both UX design and system/software architecture are, by their nature, holistic. That does not mean, though, that they are completely incompatible with an agile process.

    I work in a product design environment. We have adopted our own specialization of agile development and it actually works well. I am the UX leader and occasionally the software architect, sometimes at the same time.

    We begin our product development with a couple of phases of research and investigation before starting actual development. This is to investigate customer needs and profiles and refine the requirements. Once we begin converging on a definition, we begin developing the overall view of the interaction model and the high level software architecture. These are both tested before we begin actual development.

    For each iteration, I firm up the design for the areas to be developed in the next iteration, consistent with the overall vision, and assist in developing the current iteration. This is a lot of pressure on me, but so far the results have been good. We do a light round of user testing at the end of each iteration.

    For our team, in our environment, doing our products it works. Your mileage may vary.


  8. Robert Says:

    Great topic on something I have been concerned with for some time now.

    My company has also moved into using the Agile approach. It seems to me that this method was developed by Developers, not Designers and without Designers in mind. Quite often Development teams gloss over the design aspect of an application. When I say “design”, that includes requirements, interaction, look-and-feel, etc. I think, and others here have hinted at it as well, that proper application design cannot take place at breakneck speed. As Tai Toh essentially says above, you can’t design part A to fit with part B correctly, if you don’t know what part B is yet….never mind parts C, D and E.

    I think Agile is smart and Agile can work but I think there is a fair amount of “design” that has to take place before that first sprint. Perhaps the design team is always at least a sprint ahead of the development team.

    I would love to hear more chatter around Agile and the design process.

  9. Trevor Grayling Says:

    Very interesting article. I’ve not worked in an “agile” environment (only in “rushed,” “panicked,” and “endless and stodgy” ones); so I may be misunderstanding many of the finer points. But here are the comments that strike me:

    QA TESTING: Jeff states that, “they employ automated testing to shorten the cost of adding to and changing the software.” MAYBE: QA testing is still plagued by the fact that it is difficult, if not impossible, to test the millions of pathways an end-user may take through an application. If you are automating only a fraction of what is possible, then your testing is still inadequate and you are kidding yourself as to the actual “cost” of testing. Agile may have a number of positive features, but it is not addressing this major QA issue.

    COURSE CORRECTIONS: Jeff states, “More frequent feedback and delivery cycles also results in quicker course corrections, which can reduce project risk.” COMMENT: “Course corrections” could involve minor, even cosmetic changes to a GUI. On the other hand, they may cause fundamental changes deep down in the software and cause major redesign, recoding, and retesting. I’d love to see some actual data on various real projects, but it seems to me that course corrections could increase project risk, and the more course corrections there are, the greater the risk.

    USABILITY TESTING: Jeff states that, “UX members have less time … to evaluate the product. This means instead of designing and validating a fullsolution before sending it forward to development, the UX team mayonly design and validate just a bit – or design some and only validate the most risky aspects of the design before development. QUESTION: Users want to do real-life tasks, which usually involve many sub-tasks, which may well range into all sorts of odd corners of the application. After doing sub-task 3, say, the user needs to be triggered somehow by the software to do sub-task 4; and they also need any pertinent information about doing this sub-task (either text in the GUI, pop-ups, context-specific help, message dialogs, etc.). If they lack either of these items, the risk of them not being able to complete the overall task increases greatly. If the sofware is released only in incomplete “splinters”, then it will not be possible to complete many real-life tasks. How then is it possible to check for usability, except near the end of the process when most of the GUI is available?

    I can see how this could work for very simple web-based applications (e.g., photo sharing) that have only a handful of tasks with a few, obvious sub-tasks, but I don’t see how it can work for applications with any degree of complexity.

    CUSTOMER VALIDATION: Jeff states, “I’ve seen environments where a UX team functions in partnership with business analysts under a product manager – all of these folks working together to fill the role of an agile customer. If you’re a UX person, you’re an agile customer. COMMENT: One of the major reasons that applications fail to gain market acceptance is that, for whatever reason, Marketing professionals often seem unable to exactly define what end-users need and will respond to, as compared to what end-users say they want or what the decision-maker (guy with the checkbook) thinks he wants. I don’t see the Agile process dealing with this in any way, especially with UX folk, business analysts, and product managers filling the customer role: They are just going to confirm their own prejudices.

    There seem to be many good features in the Agile process: Development teams meeting and talking more frequently, daily standup meetings to keep everyone on the same page, cross-functional teams sitting closely together, minimal documentation, and so on. However, to an outsider, it doesn’t seem to address a number of real issues, as noted above and by the other comments.

Add a Comment