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.
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.
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.
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 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 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)
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?”
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?
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.
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.
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.
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.
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...
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 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.
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.
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.
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.
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.
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.
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...
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.
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.
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...
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.
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 :)
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.
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”.
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.
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.
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.
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.
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)
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.
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.
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.
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...
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.
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.
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.
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.
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.
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...
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.
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.
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.
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!
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.
dmitryn
sugiyama_sukedachi
hirokazu_oda
wattlaa
abcmisuzu
okazakityo
kasumidyaya
nextbeat
amishiratori
root_recruit
minamitary
recruitengineers
bkeepers
iamctodd
zakiyama
eitanlees
addyosmani
brianwarren
jnunemaker
colly
maggiecrowley
eileencodes
chriscoyier
3n
