YouAreHere: UX + Agile

Even research firm Forrester dives onto this subject now and publishes a report called Making Agile Customer-Centric. Unfortuntaly such reports cost $499 so I'm going to skip this one for now.

Jeff and Anders both share a background at the company Thoughtworks but also have different backgrounds. Mr. Ramsey has a UX design background while Mr. Patton's origins seem to mainly in Agile.

It will be interesting how the books will compete with each other. Or better how they will complement each other!

On the book site Anders explains his reasons for writing the book:

Another equally important reason why I am writing this book is to strip away some of the myths and misconceptions about Agile, such as the idea that its all about Sprints and Scrums and Burndowns. Those are all valuable and important practices, but Agile is much larger than any one of them. In fact, perhaps the most important goal of this book is to convey the deeper thinking, the Agile Mindset, on which those practices are founded. Armed with that Mindset, my hope is that many in the user experience field will find ways to not just join Agile teams, but to also transform and empower traditional teams from within.

I sure hope that he will succeed!

Alan Cooper was interviewed at Agile2008 where he, as a fomer programmer and a founding father of the interaction design profession, was a a speaker. In the video he speaks about how Agile allows Interaction Designers to step into the teams and take ownership of the behavior of the products being built. This time as a part of the team instead of as a "hostile" team outside of the developers telling the developers what to do.

He speaks about the different competences brought into the process by interaction designers:

The same way Agile programmers want to know what done looks like, interaction designers want to know what success looks like. And those two work together to create a successful product and that is the missing piece.

According to him interaction designers and Agile programmers have a shared goal and it is more effective to work with developers directly instead of handing a design over to management:

So I very much see a shift from our design organization delivering solutions to management which are worshiped but not followed to feeding directly into the Agile cycle because the thing that motivates good designers is the same thing that motivates good programmers which is seeing their products get built and having them satisfy the users.

In one of the latest Boxes and Arrows articles User Centered Designer Anthony Colfelt explains which mines you can step on when walking the "minefield" of applying UCD within an Agile project. A brief summary of the mines he describes:

Mine 1: An unclear role for design
Agile methods have originated from development, not design. The role of the designer on a team isn’t very clearly defined. 

Mine 2: The requirements gathering process is not defined

“Agile accommodates design activities from the perspective of a developer. It tends to shoe-horn these activities into their view of the world where requirements fall from the sky (from the business or customer who is assumed to be all-knowing) and takes for granted that they are appropriate.”

Mine 3: Pressure to cut corners 
As Agile focuses on delivering working functionality fast there is little time to choose between and test out different options and designs before implementing.

Mine 4: The temptation to call it “good enough”
Agile processes focus on delivering ‘potentially shippable’ code. If Product Owners release because they can, then that could mean products get released while the quality is not high enough.)

Mine 5: Insufficient risk-free conceptual exploration time
The focus of Agile on starting development soon leaves little time for Concepting, UX research and designing a vision.

Mine 6: Brand Damage
When releasing too early, the brand identity suffers

One of the main conclusions: "Agile is good for refining, not defining".

If you have an existing product that you want to develop to the next level, then Agile in its truest sense works because you have a base upon which to improve. This means that if you know what your requirements are and these have been properly informed with user research, comparative analysis, business objectives, and analysis of what content you have and what you can technically achieve, then Agile alone can work well.

But spending money on software development without a plan of what to build is like asking a construction crew to erect a tower with no blueprint. Some level of plan is necessary to avoid a Frankenstein of each individual’s perspective on the best design solution.

In his column at Wired Magazine David Allen paints a picture of how the future could look like in the field of productivity (and creativity!) enhancing software. He envisions intelligent walls and rooms which proactively help you make associations based on the knowledge it has about you, your life, your connections and your prior work.

What I need is more real estate in which to think, and tools to facilitate the process. I need it to be systematised intelligently so that when I engage with it I'm stimulated, not stupefied.

In many respects, function follows form. So as the digital tools have got smaller, the danger is that our thinking has, too.

...

The great new frontier for productivity-enhancing software is in idea generation. Sure, you can use your tiny little PDA to look up words, find quotations and idea-shop until you drop. But it's not a room.

Apparently last week there was an actual conference on integrating (UX) design and (Agile) development at the University of Minnesota called Code Freeze 10.

There were some interesting speakers like Alan Cooper, writer of About Face 3 on the Interaction Design process and Jeff Patton Agile Coach and expert on how to integrate UX into Agile.

In a post on his weblog Bob MacNeal proposes an approach to integrate interaction design (and therefore UX) into Agile projects is to alternate between Discovery iterations and Delivery Iterations:

The diagram below shows what the iterative cycles of User-Driven Rapid Prototyping might look like:

Where

• The hand palming the spiral is a Discovery or Re-Discovery Iteration
• The subsequent handless spirals are Delivery Iterations
• Discovery iterations, after iteration zero, are called Re-Discovery
• Odd iterations are for coding and delivery, while Even iterations are for discovery (interactive research and design).

 

In Discovery Iterations the focus is on learning about the intended users of the product and improving the user experience and usability of what is already built. In Delivery Iterations the focus is on delivering new functionality.

Does anyone have experience with this approach?

Usability expert W Craig Tomlin shared 7 Usability predictions for 2010 which may not be very controversial but are insightful.

Three of them have to do with usability becoming quicker and cheaper and more of a commodity:

1. The cost of conducting usability testing will decrease by a factor of 10.
2. There will be a dramatic increase in the use of low cost web-based usability testing tools.
4. Use of remote moderated usability testing will increase by a factor of 10

As more and more cheaper tools are available it becomes easier and cheaper to run a usability test. This is a positive trend when doing usability work inside an Agile environment where the results are needed fast for implementation in the next sprint.

This point is also worth noting:

5. The UK [and EU] will become a major source of usability expertise

W Craig notes the large amount of Usability related job openings in Europe. The field is clearly growing, these are good times to be in the Usability field!

Fun presentation using sticky notes from an Information Architect on how agile (here called 'washing machine') improved her companies design process.

Great observation from blogger Jason Furnell: the 5 principles of Lean thinking align very well with how user experience designers like to work.

There is an assumption that the standard set of UX activities and outputs should simply slot into agile development practices unchanged
Lets flip the question and ask what would a UX Design project look like if you were to manage it following Agile principals.
The point of re-framing the question is to directly challenge the UX community to rethink its approach and bear the burden of transformation in order to move towards supporting a more effective and enjoyable way of actually delivering real, live user experiences for customers.

On the 'Agile Experience Design' network several User experience designers and Agile Developers get together to discuss the integration of the two disciplines. Very interesting to see how people are seeing their roles change and embracing new and more effective ways of working together towards quality end results.