Surviving and thriving as a UX professional
in an Agile development organization
Dmitry Nekrasovski
Thanks for being here everyone.
Especially since you could be on your way to watch the hockey game right now!
I’d like to talk to you today about what it’s like to work, and succeed, as a user experience designer in an Agile
development environment.
But, before I do, I’d like to tell you a little story.
And, if there’s one thing you take away from this presentation, I’d like it to be this story.

Once upon a time, there were a chicken and a pig who were good friends.
One day, the Chicken suggested to the Pig that they should open a restaurant together.
“What would you call it?”, asked the Pig.

“How about Ham and Eggs?”, replied the Chicken.
“Thanks, but no thanks”, said the Pig.
“Why not?”, asked the Chicken.
“Well, you see”, replied the Pig, “I would be committed, but you would be merely involved.”

Committed vs. involved
So why is this story so important to this talk?
Because I think that the distinction between being committed and involved is key to understanding the mindset of
the agile software development movement.
And, I would argue that it represents a change that we, the HCI/UX/usability community, have to make in how we
think of our role.

What is this Agile thing, anyway?
Now you might be thinking to yourself at this point:
“Why should I change the way I think of my role? I don’t work with an Agile development team.”
or even
“What is Agile anyway, and why should I care about it?”
Those are good questions. Let’s answer them.

Agile =
a new way of thinking about SW development
Agile is a set of methodologies that represents a new way of thinking about software development.
A couple of the better-known examples of Agile methodologies are Scrum and Extreme Programming.
These methodologies have evolved over the last 10 years or so as many people in the software development
community have been looking for a more lightweight and human-centered alternative to older processes like
Waterfall and RUP.

Agile =
collaboration + adapting to change
What’s new about Agile compared to these earlier methodologies is its emphasis on two practices:
Collaboration: internally within a development team; externally with business stakeholders and customer
representatives
Adapting to change: external change (requirements, scope, timelines) and internal change (as the team and the
system evolve)

Agile =
perceived as an improvement by developers
Agile proponents believe that these practices lead to higher-quality software that’s delivered more efficiently and
is more responsive to customer needs.
And this seems to be backed up by industry surveys.
Over 75% of developers whose teams have adopted agile approaches report improvements in software quality,
team productivity, and business stakeholder satisfaction.
So you might think “That’s great. But how many people actually use Agile?”

35%
fraction of software developers who currently work
on an Agile development team
84%
fraction of software developers whose
organizations have adopted Agile or plan to do so
(source: Forrester/Dr. Dobb’s Journal)
More than 1 in 3 developers, as it turns out. More than all other methodologies combined, in fact, since many
developers don’t follow a particular methodology.
And, most software development organizations have either adopted some form of Agile on at least one project, or
plan to do so in the near future.
This change has only come about in the last 10 years. To paraphrase Will Ferrell, agile is kind of a big deal.
But why is it important for us, as UX/usability professionals, to be thinking about agile?

Agile =
user experience agnostic
The Agile methodologies were created by software developers, for software developers.
They are not focused on the needs of users, or on designing software that fits those needs.
In general, Agile is user-experience agnostic.
It’s up to us, as user experience professionals, to understand Agile practices and ensure that our work and
methods can succeed within their context.

Some Agile practices fit well with UCD.
Others don’t.
Each of the agile methodologies comes with their own vocabulary.
But they share a common set of practices.
Some aspects of these practices are familiar to us as UX professionals and fit nicely with a user-centered design
approach.
Other aspects can be frustrating and downright contradictory to what we are comfortable with as UCD
practitioners.
Let’s talk about these in more detail.

Agile is about
constant communication and collaboration...
Agile methodologies emphasize the need for constant communication and collaboration between people on a
project team.
And this is, of course, something that we all can appreciate, as we recognize that these are key for designing a
good UX.

... but it’s also about
self-directed teams of generalists.
But, many agile methodologies advocate for self-directed teams of generalists.
Each person on the team is supposed to be able to perform all the tasks required to design, develop, test, and ship
software.
Also, tasks are supposed to be chosen by team members themselves, rather than assigned to each team member
based on their competencies.
While this is not always achieved in practice, it still forces us, as UX practitioners, to justify our value as specialist
contributors.

Agile planning and design are iterative...
Agile methodologies are iterative.
An agile project is broken down into iterations or scrums.
In each iteration, the team plans, designs, implements, tests, and releases a working product.
This would seem like a natural fit with UCD and its emphasis on iterative design and evaluation...

... but the iterations are time-boxed...
... but agile iterations are time-boxed.
This means that they are always of the same length, which varies between 1 and 4 weeks, depending on the team.
The short lengths are supposed to help the team keep up a productive pace.
But, as you can imagine, this places a severe constraint on the amount of user research, conceptual design, and
usability testing that can take place in an iteration.

Agile is focused on the needs of the Customer...
Most agile methodologies require the role of a Customer on a project team.
This role acts as the interface between the business stakeholders and the developers.
The Customer is committed to being available to answer the team’s questions about what constitutes business
value throughout each iteration.

... but the Customer is not necessarily representative
of actual customers and users.
But this assumes that the Customer already knows everything there is to know about the needs and requirements
of actual customers and users.
If the Customer is representative of the product’s users in terms of experience and domain expertise, this is a
good assumption.
But usually, they aren’t, and it’s not.
Moreover, since the Customer is supposed to be available full-time to the development team, they are not likely to
have much time to talk to the very people whom they are supposed to represent.

Agile is about adding business value...
Agile methodologies are focused on adding business value.
At the end of every iteration, an agile team is expected to demonstrate the value that its work has added to the
system over the course of that iteration to its business stakeholders.

... but “business value” is not the same as
value to users.
But, since agile processes were created for and by developers, they usually don’t define “business value” very
rigorously.
What constitutes “business value” is ultimately up to the Customer and the business stakeholders he or she
represents.
And, as we’re well aware, value to a business stakeholder does not always equate to value to a product’s users.

Agile captures requirements as user stories
that lend themselves to the use of UCD methods...
Agile methodologies define requirements in units of incremental business value called user stories.
User stories are created by the Customer as starting points for conversation with the development team.
They are supposed to be small enough for the team to implement and test in a single iteration.
User stories often take the form “As a user, I need to be able to perform a task using the system, so that I can
accomplish a goal.”
For example, “As a student, I need to be able to buy a campus parking pass, so that my car doesn’t get towed.”
This is great, because it lends itself to the use of UCD tools like personas and task analysis.

... but it’s easy to lose sight of the big picture.
But, agile methodologies typically don’t concern themselves with the context of a user story, or the design of the
overall user experience achieved by combining the implemented user stories.
In fact, agile proponents frown upon the idea of what they refer to as “big design up front”, because they equate it
with work that doesn’t deliver business value.
So defining key UX objectives and a coherent design vision to meet these objectives can be a real challenge in an
agile project.

Agile is about
continuous feedback and improvement...
The final Agile practice I’ll talk about is continuous improvement.
Agile methodologies stress the importance of continuous feedback loops and iterative refinement.
This applies at all levels of the project, from the code to the development process to the way the team manages
itself.
Again, this is something that’s seemingly consistent with the UCD philosophy...

... but UX is not explicitly considered
as something worth improving.
But the focus of these practices in the Agile world is purely internal to the project.
There’s no explicit consideration of continuous improvement as it applies to the user experience or the product’s
design.
The feedback loops we think of as UX professionals, ones that involve customers and users, do not exist in the
world of Agile.

So, given all these potential pitfalls and deficiencies, you might ask why would you, as a UX professional, ever want
to work with an Agile team?

Agile =
promise of better software built in a better way
Agile is a promise of better software
created in a more humane way.
Because, fundamentally, Agile has the potential to enable the creation of better software products in a better way.
In a sense, we can think of Agile as bringing the values of UCD to the software development process, trying to
make it more sustainable and humane.

And hopefully even fun. Although not as much fun as he’s having. :)
Personally, having worked as a UX designer on Agile teams over the last 3 years, I’ve enjoyed the dynamic and
collaborative nature of Agile.
And I would find it difficult to go back to working with a more traditional software development process.
But, there is a caveat...

Agile and UX:
Lead, follow, or get out of the way.
UX professionals can’t afford to be passive in the face of Agile process adoption.
We have to take an active role and help the teams and organizations we work with.
We need to work with them to adapt their Agile methodology of choice to include UX values and methods.
We can position ourselves as partners with complementary skills, rather than roadblocks on the way to developer
Nirvana.
If we can do this, we may find that, rather than being threatened by Agile practices, our influence and ability to
make our users’ lives better will actually grow.

10 steps for UX success in Agile teams.
So how can this be accomplished?
I’d like to share with you a set of guiding principles or steps that can help.
It’s based on my own experience over the last 3 years, and inspired by the many people in the UX community who
have been sharing their own experiences with Agile and what has worked for them.
And, of course, there’s 10 of them, because we all love Top 10 lists :)

10. Be iterative.
A lot of people in the UX community are concerned about Agile’s focus on timeboxed iterations.
The typical comment is “There’s no way I can possibly conceptualize/design/test anything in X weeks.”
Instead of looking at it this way, try seeing this constraint as an opportunity.

10. Be iterative...
... so that you can fail and learn quickly.
Agile’s iterative nature is intended to force developers to fail and learn from their mistakes quickly, rather than to
waste months working towards the wrong goal.
Try to do the same in your work. Iterate your design ideas early and often, not just with users as in standard UCD,
but with the project team as well.
Of course, as UX professionals, we typically need time at the beginning of a project to do the research and
conceptual design that will give us a foundation to iterate upon.
This is where you can leverage Agile’s concept of “iteration 0”.

10. Be iterative...
... but fight for your right to an Iteration 0.
In Agile methodologies, “iteration 0” or “sprint 0” denotes the first iteration of the project, which the team uses to
plan the project and define an initial list of user stories.
As a UX professional, you will typically need longer than 1 iteration for your “iteration 0”.
This is because your “iteration 0” is your chance to do user research, summative usability testing, competitive
analysis, and to elaborate a solid design vision based on these.
Your team needs to know that your “iteration 0” really needs to take place before the project starts, so that you
can spend their “iteration 0” communicating and vetting the design vision with them and your stakeholders.

9. Be incremental.
The incremental nature of Agile development is another challenge for most UX professionals.
We are trained to define user experiences top-down, from user needs, goals, and tasks, to the actions and
affordances that make them possible, to the pixel-perfect visual design.
But Agile follows a bottom-up approach.
Each iteration, an Agile team builds on the previously delivered functionality to add a circumscribed chunk of
business value.
This doesn’t mean that we need to abandon our process, only change how we communicate our designs to the
team.

9. Be incremental.
Communicate your design vision in layers.
When you’re working with an Agile team, you need to feed them just enough design every iteration.
You may still want to create a single design spec to describe the vision for the overall system or a complex feature,
and review it with the team early on in the project.
But, when you’re writing user stories or creating design artifacts in support of user stories, structure these in
layers.
This way, the team can deliver the base layer first, and then build on that base.

9. Be incremental.
Visualize dependencies between the layers.
It may be helpful to visually show dependencies between layers of stories in a diagram like this one.
This will give your team a context for the current batch of user stories, and an idea for what might lie ahead.

8. Be lightweight.
As I just mentioned, monolithic design specs don’t work well in an Agile context.
The team’s focus is on the iteration ahead of them, and the pace of change is too fast.
So you need to find tools and techniques that will let you capture design decisions and the rationale for these
decisions in a lightweight way.
What I mean by lightweight is
- easy to create and maintain (for you)
- easy to access and understand (for your team)

8. Be lightweight.
Try different tools to capture design decisions.
Here are a few options you can experiment with:
If your team is small and co-located, try annotated paper or whiteboard sketches
If you need to capture a large number of textual requirements, try using a wiki
If you have a development background, try creating an interactive prototype
- again, ensure that it’s easy to maintain
- when working with my first Agile team, I created one in Java
- it worked great, but, towards the end of the project, maintaining it became a full-time job
If your team uses an issue tracking system like JIRA, leverage it
- it will fit into your team’s existing workflow, and notify them when you make changes
Bottom line: do what works best in the context of your team and your own skills.

7. Be empirical.
Agile methodologies place a high value on empirical data.
It’s the basis for all the continuous improvement practices I talked about earlier.
So, when working with an Agile team, use empirical data as much as possible to provide rationale for your design
decisions.
Whether it’s your own usability test data, results from the research literature, industry best practices, or platform
guidelines from Apple or Microsoft, communicate them to your team when justifying your choices.

7. Be empirical.
So you can make judgment calls when needed.
Now, of course, you might say “That’s nice, but what if I have no time to do my own testing, and can’t find any
data to make a decision?”
Developers (especially Agile ones) are rational creatures and love data.
But they know from their own experience that sometimes design decisions require judgment calls.
Be honest and upfront with them about this, and they will respect you for it.

6. Be both Customer and Implementer.
In any conversation about UX and agile, one question that seems to inevitably come up is whether UX is a
Customer or an Implementer role.
You’ll recall that the Customer is the role that represents the business stakeholders.
Implementer, conversely, means every role that participates in the system’s delivery - Dev, QA, Documentation,
etc.
Having worked in both of roles on Agile projects, I think the ideal is to be a little bit of both.
As an Implementer, you have the recognition of the tasks that you need to perform to do your job. It prevents the
team from asking you to provide deliverables in an unrealistic time frame.
As a Customer, you have influence on what gets built and how. But you may not want to be in this role alone...

6. Be both Customer and Implementer.
Work towards building Team Customer.
In canonical Agile, the Customer role is filled by a single person.
But in my experience, it’s best filled by a team of 3 people: the product manager, the UX designer, and the
technical lead.
This is consistent with the so-called “3 in a box” model, used in companies like Oracle and Cisco, where the 3
roles all have to sign off on major product decisions.
Assuming these people can trust each other and work together to guide the team, this model can lead to the Holy
Grail: a successful balance between the needs of the business, the needs of the users, and technical and
architectural concerns.
Admittedly, this sounds a bit idealistic, but it’s a good goal to aim for.

5. Be the visionary.
Since Agile works at the level of user stories that can be implemented within an iteration, it’s easy for the team to
lose sight of the big picture.
Even when the team starts with some idea of the kind of user experience that needs to be created, this shared
understanding can gradually vanish.
As a result, it’s possible for an Agile team to correctly implement every user story, and still end up with a system
delivering a sub-par experience.
As UX professionals, we can add tremendous value to an Agile team by being the keepers of the overarching
vision, and the ones who keep teams on track towards that vision.

5. Be the visionary.
Weave user stories into themes and scenarios.
The way we can accomplish this is by thinking about the system’s design and user goals at a higher level than user
stories.
Some agile methodologies have introduced the concept of a “theme” to talk about this higher level. From a UCD
perspective, we can also think of them as usage scenarios.
We can share these themes and scenarios through deliverables such as interaction flows and storyboards.
By doing this, we can help the team understand dependencies between user stories and sequence them across
iterations.

4. Be the facilitator.
Agile methodologies seek to empower teams to be self-managing and to make their own decisions.
But agile teams rarely have experience in effectively brainstorming design ideas.
While most agile methodologies require the presence of a coach or scrum master on a team, this person’s
expertise tends to lie in project management or process definition, rather than facilitation.
This is another area where UX professionals can help.

4. Be the facilitator.
Help the team make the design its own.
We can facilitate design brainstorm sessions where everyone on the team can contribute ideas and jointly
understand the implications and tradeoffs of design alternatives.
We can then take these inputs and create coherent design solutions that fit into the overall design vision.
By doing this, we can help the team make the design vision its own.

3. Be the “glue” that binds the team together.
Communication is a key element of Agile methodologies.
In our dual role as Customers and Implementers, UX professionals are often in the best position to foster open
communication in an Agile environment.
With our experience collaborating across functions to get our jobs done, we can act as “glue” both within the team
and between the team and various stakeholders.
The goal is to try to stay simultaneously engaged with the team’s progress and independent of the various
interests at play...

3. Be the “glue” that binds the team together.
And the therapist in times of conflict.
Which brings me to that other aspect of communication - conflict.
As much as Agile methodologies aim to eliminate the “pain” of software development, conflict is still inevitable,
especially when a team is transitioning to Agile.
I’ve been through a couple of such transitions, and in my experience, they tend to expose and bring to light all the
power imbalances and communication breakdowns that had been there all along, in a way that demands
immediate attention.
So, in addition to being the glue that binds an Agile team together, the UX professional may be called upon to be
the resident therapist.
This is not an easy task by any means, but the feeling of helping a team get back on track can be very rewarding.

2. Be the trusted advisor.
I’ve talked about a number of ways in which a UX professional can add value to an Agile team.
But the most important one, I think, is helping the team make better decisions.
As the Agile manifesto states, Agile is ultimately about “uncovering better ways to develop software”, and the use
of UX methods can be one such way.
Whether it’s by iterating through design ideas with low-fidelity prototypes, conducting usability testing, or doing
user research, we can help Agile teams bring a better understanding of their users and contexts of use to bear on
the problems they are trying to solve.

2. Be the trusted advisor.
Help the team make good battlefield choices.
Alan Cooper, the father of interaction design and personas, has a great talk on the symbiosis of Agile and UX
called An Insurgency of Quality.
In it, he talks about the small decisions that software developers face many times every day, the tiny tradeoffs that
can make or break a product, but whose importance is rarely understood by business stakeholders.
Cooper calls this concept “battlefield choices”.
He argues that, while Agile gives development teams the tools to make good technical battlefield choices, the only
way they can make informed battlefield choices that concern their users is by working side by side on a daily basis
with committed UX designers.
I tend to agree.

1. Be committed... be a Pig!
In conclusion, I’d like to come back to the involved chicken and the committed pig.
In my work with Agile teams over the last three years, I’ve seen a lot of skepticism about commitment.
Too many developers still perceive UX professionals as chickens, content to dispense their advice, and then, for
lack of a better term, flee the coop.
I’ve tried to prove this skepticism wrong and work with them, day in and day out, to make their products better.
As I did, I found that developers became more willing to trust my design decisions, and my ability to champion for
user needs and usability improvements increased dramatically.
So, if you’re going to work with an Agile team, or really any development team that’s committed to what they do, I
challenge you to go on... be a pig!

Thank you!
twitter: @dmitryn
delicious.com/prettyusable/agile-ux
Thank you!
If you’re interested in a bibliography of resources on Agile and UX, check out the link at the bottom of the slide.
All photos courtesy of Flickr’s Creative Commons search and their respective creators.