Episode #155 Anders Ramsay - Applying Agile Values to UX
The Agile development process is accused often of being too focused on delivery over the user experience. But that’s not to say that Agile is the bane of UX. Anders Ramsay believes it’s important to distinguish between Agile methods and Agile values. Many, such as fast prototyping and shared understanding are also valuable in the user experience world.
The Agile development process is often accused of being too focused on delivery over the user experience. But that’s not to say that Agile is the bane of UX. Anders Ramsay believes it’s important to distinguish between Agile methods and Agile values. Many, such as fast prototyping and shared understanding are also valuable in the user experience world.
In general, the difference is a fundamental one. Agile development is very solution-focused and user experience practitioners are more interested in the problem. But it’s the commonality that is important and the realization that they are out to accomplish the same thing. Weaving UX into an Agile process and emphasizing the shared values leads to greater collaboration. Ultimately the goal is to arrive at better designs and better products, faster.
Of course, this isn’t an easy adjustment to make. Coming out of the heavy document and detailed wireframe world, Anders says that it’s more a matter of recognizing what aspects of the documents are waste and are things you could easily just have a conversation about. He admits that it can be a shocking transition to make:
“...this is people who have ridden a horse and buggy their entire life, and now I'm going to put you in a car. That's just not going to happen overnight. It's a new way of getting from point A to point B.”
Jared Spool: Hello, everyone, and welcome to another episode of the SpoolCast. I am very happy and excited today, because I have a chance to talk with Anders Ramsay, who is delivering a virtual seminar, in conjunction with Rosenfeld Media. We're doing a bunch of what we call the Next Step Series, and he's doing our first one. It's called "Designing with Agile: Fast, Effective UX Methods that Work." And that'll be on January 24th. You probably don't know this, but Anders is also working on a book for Rosenfeld Media, called "Designing with Agile: Lean User Experience for Successful Products."
Anders joins me from New York, I believe, yes?
Anders Ramsay: Yep, I'm in New York.
Jared: Excellent. Anders, how are you doing?
Anders: Good, good. How are you?
Jared: I'm doing very, very well. So, I've got some questions about your work with Agile. You've been in the business for quite a long time, right?
Anders: At least 15 years. I built my first commercial website in '96.
Jared: OK, yeah, so just after the web had started to really take off. So, given that you've been around, Agile hasn't been around, at least the values were all written up in about 2001, if I remember correctly.
Jared: And so, when did you start working in Agile?
Anders: Well, I think I was practicing techniques probably already as early as 2004, 2005, but I wouldn't have called them Agile because I hadn't really become familiar with Agile at that time, and so I would say more explicitly adopting Agile methods more closer to 2008 or 2009, and since then having, obviously, been practicing that. But that's one of the interesting things is that it's a way of working that it's not necessarily tied to that you have to follow, for example, these very explicit values. That's one of the important things to understand about Agile, I think.
Jared: Yeah. I mean, what's interesting about Agile is that there are all sorts of different layers to it. It feels to me sort of like an onion, in that you're always seeming to peel things back, and at the core of it are these Agile values that really, I think, speak a lot to what people are trying to do and why this really is something more than just a fad or just a re-branding of something we already were doing.
Anders: Yeah. So what's interesting and maybe confusing for people who aren't aware of the history is that even though the "Agile Manifesto" you know, was formulated in 2001, that was something that was many, many years in the making. And it's really sort of turned upside-down, because the methodologies that people are familiar with, they actually existed before that term "Agile" was coined. And, in turn, those methods originated from what was generally referred to as lightweight software-development methods.
So I see myself as being more of an adoptee of these earlier, original elements that became the basis for Agile. And Agile is more just like a brand, a term. It's something that we can all refer to. We can just talk about Agile. We're referring to this kind of way of thinking about design in general and software specifically.
Jared: Right, right. So what would you consider to be the project that would be the, accomplishment, you know, the UX/Agile accomplishment that you'd be most proud of?
Anders: There are probably several, but one that certainly comes to mind is a project I worked on, I guess a couple years ago, in which we had done a lot of maybe what we might think of as more traditional UI design work for this project. And it was a very complex enterprise project, very domain-specific. And there was really sort of a morality struggle in the project, in which the product owner and the team in general felt that, one, they felt overwhelmed by the user interface. Also, despite all our efforts to present these various wire-frames and other more traditional UX documents, they were just very concerned about, "How are we going to be able to get all these various features? I don't really understand it. It's not making sense to me."
There was really a struggle, low morale with the team. And at that point, we were finally able to bring on software developers, front-end developers, onto the team, which we had been wanting to do all along, and so be able to shift then to more of an Agile approach, in which there was an intensive back-and-forth between myself and the developers, so that rather than, for example, me having a meeting with users and then coming back with some wire-frames and trying to communicate the design concepts and get their approval on that, we instead would incorporate a construction of the actual tool.
And so, what that resulted in was that we took this one concept that effectively involved the system sort of responding to the various window sizes of the tool. And this was a really critical part for these particular users because some of them needed to work on small screens, some of them needed to work on large screens. And we were able to have them actually interact with this feature. And suddenly all this hand-wringing that they had been experiencing about, "Oh, all this complexity! I don't understand it. I don't get it," suddenly just melted away, and they just kind of grokked it, to use a nerdy term. It just made sense.
That was a truly powerful example of the idea of cross-functional pairing. So we're taking pair programming and adopting or adapting that to, or extending it to, include UX. In some ways, unofficially at least, it saved the project. The morale just was boosted, and suddenly people really believed in the product and believed that this was going to be a success.
Jared: Say a little more about this pairing-up thing. How does that work in a UX frame? Because I understand how it works in programming, right? Basically, you have two programmers sitting next to each other, and they're actually coding together, and having the two brains sort of focused on the same activity, they spot errors and defects and they come up with ideas faster. Right? That's the idea behind it when it's programming, but what is it when you're talking about it from a UX perspective?
Anders: So the difference there is that we're doing the same thing but we're doing it across disciplines. So, in this particular case, the way that it worked is we would both start at a white board and white-board a little bit together. And then the critical part there was that the developer was very actively engaged, and he would say, "OK, I feel now that we can add more value and evolve the design more effectively by moving to starting to build." That was a critical part.
So we made a critical shift there, when we moved to the white board and moved from sketching to sitting next to and sitting in front of the computer. And then he would start doing some construction, and then I would just kind of continue to sketch, sitting next to him, because he may need a little time to build up certain pieces, but have some quick questions, like, "Did you mean this? Did you mean that?"
And so, the debugging that's happening there is not so much in terms of code quality but in terms of experience quality. And one of the reasons that this works, this particular instantiation of cross-functional pairing that we were doing is something called "designing in the browser," if people want to Google that. The reason that you can do it is because, in a modern kind of software front-end development world, where we have so many patterns and things like jQuery, a lot of highly abstracted tools--jQuery, obviously Python, Ruby and so forth, and Rails--they're able to work at a very high speed. So we're able to actually sit next to each other and actually build, almost like building blocks.
So it's very powerful. And it certainly does not replace pair programming; pair programming has its own place. But it's something that is great to do for highly detailed design work, particularly when the team already has established somewhat of an interface language, so that I, for example, can say, "Yeah, let's use that list table, and let's use that compact dashboard and so forth." And you're able to work very intensively back-and-forth and really do atomic-level design work, right directly in the browser, or in your mobile device, as the case may be.
Jared: So you're taking advantage, if I'm understanding right. You're taking advantage of the code components that already exist and the elements that are already there. Plus you're using these languages, like jQuery and, potentially, Ruby or things like that, that let you get things done very fast. And as a result, that means that, sitting next to the developer, you can see the interactions and those little, subtle nuances that can't easily be explained, like, "No, wait. When you click on that, it has to fade in a little slower. Otherwise someone may miss that it's appeared." Right? That type of thing. You're able to sort of work through that and say, "No, that's too fast," "No, that's too slow," "OK, that's just right."
You can have that conversation. And because you're having it with the developer at that moment, it sounds to me like that gives it an advantage. Tell me if I'm wrong here, but that gives an advantage. Later on, when you're not sitting next to the developer, that developer understands your intent and can make decisions, saying, "Oh, I bet you what Anders was talking about was this," and can make a decision, is more likely to make a decision that matches what your intent is when you're apart because you had that time together.
Anders: Exactly. And so, things you want to do, then, is do what in some circles is called "pair stairs," where you want to make sure that, as a UX designer, you kind of tour the entire team or tour all the developers and actively make sure that you are actually going to be pairing, not just with this one developer, but you want to make sure you're pairing with everybody. What happens then, which is the same with pair programming, is you're distributing knowledge. You get knowledge distribution across the team, and eventually I don't even necessarily need to be as much a part of the picture. Like you said, they pick up the language on their own.
But I wanted to pick up on something else you said, which was the whole reason that we're able to do this is because of a higher velocity, of being able to kind of build faster tools. What's interesting is that's really the origin of Agile in general.
One of the reasons why Agile has become so powerful is because we are able to deliver working software at a higher velocity. There was a time when you could make a case for big specifications because coding was slow, time-consuming, and expensive, and that no longer is justifiable. So it is, the whole reason we can even talk about doing two week sprints or one week sprints or hour-long sprints, if you're doing a hackathon or something, you can be turning things around in very short cycles of time, is because developers are basically able to speak in a more succinct and eloquent way with machines, use more words that have more richer meaning. Back in the early days of the [indecipherable 11:11] , it was like you're in third grade or first grade and you have only a few words that you know. Now, we speak this very rich language. So that has then cascaded into we're now wanting to adopt the UX practice to that new world.
Jared: This must have been really different from the ways you were working when you were doing Agile. I mean you said you started in '95, '96 and you had that block of time in there where stuff wasn't Agile. This pair programming and using these components, were those the big differences or were there other big differences that sort of stand out in your mind?
Anders: The fundamental difference is really just looking at and thinking about what is valuable and effective. So in those days, to me, well let's be clear. In the very early days, everything was just chaos and ad hoc. There was no process. So, around '98, '99, we started to develop and formalize specification documents and so forth. At that point, the holy grail of UX design or information architecture or whatever term was used at that time was the perfect specification document, the perfect wireframe, the document that would just absolutely crisply communicate what needed to be built, and then you know, you could hand it to somebody and they would build it.
The problem was always with the document and if it wasn't working, then we need to make the document better, and they need to be clearer and need to add more detail and so forth. So there's been a fundamental shift there where, rather than a document-centered model, now it's a conversation- and human-centered model. It's a fundamental paradigm shift.
Jared: And so by having this human-centered model that you're focusing on, I mean this is where a lot of folks get freaked out, right? If we don't document the overall design, how will we make sure that it all fits together?
Anders: Right. Yeah, this gets to the core of what somebody who's coming from a very document-centered world - somebody who's really been indoctrinated into the design document as the culmination of one's work, of one's practice - it can be scary to think of a world in which you're really centering your communication around conversation, direct interaction. For me and as for most people who adopt this, it's something that is gradual. It's not as if one day you're doing heavy, big specifications and, the next day, flip the switch, and now we're just going to talk and use barely sufficient artifacts. It's something that is progressive.
So, early on, somebody who's adopting an Agile approach, they're probably going to continue to create fairly detailed wireframes. Over time, they'll discover, they'll think of it more and more as waste. They'll think of it as, "Why am I adding all this detail? Because we could just have this conversation." So it's more that you have an increasing understanding of what elements in the documents that you create are waste. That is something that is, as your practice matures, your ability to perceive what is waste in the documents or whatever artifacts you're producing increases. It becomes more acute.
Additionally, it's not the simplest thing. It's not a cut and dry thing as far as either it's waste or it's not waste. It's highly contextual. It's specific to each team, each project, and who you're working with. So, for one project, it may make sense for me to maybe crank out a very detailed wireframe which has all kinds of annotations or whatever in a certain point for a certain project. Then, on the next project, it doesn't make any sense at all. There's much more value in me just scribbling a few lines on a whiteboard and then talking to those scribbles with a developer. It's highly contextual. But it's also certainly not something that happens overnight. We're talking about basically this is people who have ridden a horse and buggy their entire life, and now I'm going to put you in a car. That's just not going to happen overnight. It's a new way of getting from point A to point B.
Jared: I think that a lot of people feel, though, they're sort of thrust into this world where they have to not only go from the horse and buggy into the car, but they go from the horse and buggy to driving in NASCAR. [laughs] That that's what's expected of them. That's a hard transition I would think.
Anders: It is. So part of what I'm trying to achieve with the webinar, with the book, and all the workshops and everything is to provide UX designers with a combination of thinking tools, basically a mental model to understand Agile, how to think of it, to see it, to give them a clear mental model of it. Then, a readymade set of tools that they can use as a starting point to be able to function in this very different world. Then hopefully as they understand Agile thinking under Agile values, they can customize and create their own tools and shape them to their particular situation. Certainly it is challenging, but that's one of the reasons why I feel it's important to be doing what I'm doing.
Jared: It seems to me that getting your head around those Agile values really helps a lot, because when I first saw them, I looked at them and I said, "You know, that's sort of what we were doing all along." This idea of individuals and interactions over processes and tools. That to me feels like focusing on the users, focusing on the way that we talk about our users, everything from having good personas so that we can talk about users and what they do in a realistic format to working along with the developers directly and having them see usability tests, all that stuff. That's one of the core values is this individuals and interactions over processes and tools, right?
Anders: Yes. So one of the things there that's important to understand is that those values are the equivalent of you reading a description of Rome in a guidebook versus going to Rome. [laughs] So it is an attempt to convey the most key attributes but, at the end of the day, it's just something you have to do it to really understand it. Once you've done it, suddenly these statements take on a whole new meaning.
At the same time, I feel as if they are very, very high-level and it's almost an understatement to call them the tip of the iceberg. I mean it's just the very, very ultra-distilled representation of what we mean by Agile and there is such a universe of this entire culture, you know? So here I go, I read this one paragraph blurb about Italy and visiting Rome and Italian culture. And what have I understood if I've never been to Italy? Well, not a whole lot. But if I go Italy and I spend time there and then I come back and I reread that same blurb, it's going to have a whole other much richer meaning, as with anything else. This isn't anything particular to Agile. With anything else, it's helpful but you have to do it.
That is why I try to take a very active, kind of workshop-oriented approach when I can when I talk about this stuff, to actually get people engaged and in some fashion experience what Agile means, or provide instructions, to say, "Now that we did this, here, go out and try and do this activity, activity X, activity Y." So it is in some ways its own culture, its own set of values and norms, and that has both a good side and a bad side. There's a dogma that is called a sort of negative side of Agile. It's a curiosity in my opinion because the idea of dogma in itself is antithetical to Agile values, but it's there. You have to just be accepting of that reality and then work through it.
Jared: I was talking to somebody just yesterday about that dogma. What occurred to us was that it seems that when you're new to something... Of course, a lot of UX people who are new to Agile are actually working with entire teams that are new to Agile, so everybody is new. When you're new to something, you almost require that dogma to be there in order to be successful because you're sort of taking it on faith that the way you've been doing things needs improvement. That dogma is really important to having that faith-based approach to things until you've had enough time to know that you can break the rules and which rules are really effective and which ones aren't. You need to have solid rules and be really dogmatic about those rules in that period. That's sort of getting used to something.
Anders: So one of the problems is that the rules that have been devised by methods such as Scrum and XP are intended to achieve a different set of goals and a different set of objectives in contrast to what a UX designer does. A case in point is a user story is one that is solution-focused. Basically, it's one where it's been designed to find the most effective route to get the customer or the client or whoever it is to tell the developer what to build. Tell me what to build.
Jared: You know, as a doctor, I need to find my patient's X-ray.
Anders: Yeah, so that's design. You're asking them to do the design. Now in UX, a core aspect of UX is that, in many cases, what we do as UX designers is we effectively give the customer what they do not know how to ask for, right? So in that regard, what we want to understand is not what the solution is. We want to understand what the problem is. The developers are not really interested in that. Just tell them what to build.
Jared: The problem for that particular story might be more complicated. Like, as a doctor, I want to discover that there have been tests that just came back that I didn't realize were ordered because they were ordered by another doctor in the ward. And therefore, I want to take that information into account when I'm doing my rounds and diagnoses.
Anders: Yep. What's interesting is for any one problem there's, of course, any number of possible solutions. That is where the UX expertise comes in. It's in helping shape and determine which the best solution for the particular context is and so forth.
And that is not something that Agile methods... And I want to be really clear about distinguishing between Agile methods and Agile values. Agile methods, such as XP, extreme programming, Scrum, other methods, are focused on delivery from the perspective of a developer. I'm being very simplistic. I'm being very generalizing. But from a very generalizing, simplistic perspective, those methods are delivery-focused. This is about shipping, shipping early and often. Once it's out the door, I'm onto my next feature. I'm building my next feature.
But, from my UX perspective, at that point, sometimes that's where the real game begins. Now we've got to validate this thing. We've got to make sure was it really as good as we thought it was going to be and so forth. Then, of course, there is the question of what are we going to ship, what are we going to build, what is the product going to be, and that requires sometimes a much more holistic perspective than this more incremental model that many Agile methods tend to lean toward.
Again, I am generalizing in some regards, but that has been my experience, that the well-established Agile methods are focused more on being told what to build and then finding the most effective way to deliver that. That's a very good and important thing, but it does not in itself make a whole practice.
Jared: That's a really important fact that I think gets glossed over a lot. One of the realizations that I had very recently - I hadn't considered this - was that a lot of the stuff that we see for Agile, the practices that have evolved, they all have a heritage that comes out of internal system development where the customer is somebody who often works down the hall and eats in the same cafeteria. So the teams when they say, "OK, we're going to have a customer on the team," they don't really have a customer on the team. They have someone who is pretending to think about the needs of the customer but who may not have any more information than anyone else on the team has.
Anders: Yeah, I mean, some interesting things that may be sort of shocking to a user experience designer is actually that Agile in its original methods are actually not user-centered. They're client-centered.
They're all originating from an enterprise world, and they're originating in the early enterprise universe in which it wasn't so much about, "Oh, is that button right or does it feel right?" It's like, "Does it work?" Allow me to click on the button and build it so that the thing that I need to get done when I click on the button happens happens, and that's it. So that is why, in the early days of software development...and I mean early. In the day when... I guess this would be in the 90s, mid-90s, 80s. Obviously software development goes further back than that, but as far as when we were just getting into GUIs, graphical user interfaces, at that time, particularly in an enterprise context... I don't want to talk about Apple and all these things that were happening at the same time where we were getting much more into formalizing human factors and so forth.
In the context of an enterprise, the user interface design, that was just another task that the developer would undertake. So they would select a drop-down or a radio button, whatever the case may be, and what most pragmatically and effectively would achieve the feature that the customer had asked for. And so that has then continued on within Agile methods and, in a pure XP model, the user interface is just another task that is part of delivering the story. Now, of course, there's an awareness, obviously, with the evolution of more advanced user interfaces and so forth that that is not sufficient, but that has been part of the growing pains of Agile and part of the changes that have been necessitated by that and part of what the Agile UX movement is all about.
Because we've gone from a world in which, if Agile were a restaurant, it's gone from being this institutional cafeteria where basically whatever you get is what you get to a food court where if I want to get a to-do app on my iPhone, I have at least 50, more than 50. So which one do you think people are going to pick? Well, they're going to pick the one with the highest, best experience quality, because they all pretty much have the same features. So it's this new world where experience quality is a fundamental factor determining success, and that was just not really part of the equation when Agile, you know, originated.
Jared: To me, it seems like UX folks who are new in this environment, they can benefit a lot by sort of understanding this history of it and being able to talk the language of Agile and say, "Look, what I want to do is exactly what you want to do. I want to get us closer to those users so that the things you're building are the right things and really are valuable to the people who we're trying to design for, and I want to do it as quickly as you can." And so having techniques and methods that aren't so documentation-focused but are really, like you said, pair programming, sitting down with people, talking about them, getting everybody on a common ground, and having tools like fast prototyping, things like that, all of that becomes really essential to making this work.
Anders: Yeah and for me, one of the core attributes of an Agile UX practice is the idea of active collaboration. So we're replacing this intensive rapid kind of "passing game". I like to use rugby as a mental model for an Agile approach, and we're rapidly passing the ball back and forth between team members. We do that, for example, through various workshop-oriented activities or pairing or other types of activities. And by doing this intensive collaboration, we reduce the need for writing things down, and that's actually a very good thing because what's interesting is, as software development philosophy has increased, traditional documents simply are unable to cope with that type of velocity. They were not designed for that pace of change.
I mean for a while, wikis, trying to use wiki pages and so forth, and that certainly had its place, that allows for somewhat of an increased velocity of change, but even that is in some case falling to the wayside. Ultimately, one of the few communication methods that can keep up, can cope with the everyday chaos of a software project, is direct conversation and human interaction. That's something that's implicit in the value statement. When it says, "We value direct interaction," it's really saying it's more than we value it. We must have it in order to survive and be successful. So there's an element of urgency that is not explicit in the Agile manifesto but, for anybody who has kind of lived and breathed an Agile project, it's there.
Jared: Cool. Well, you're going to be talking about how to do this in our January 24th virtual seminar called "Designing with Agile". I'm looking forward to that. That's going to be a lot of fun.
Anders: Yeah, I'm looking forward to it as well.
Jared: And I'm also looking forward to seeing the book, "Designing with Agile: Lean User Experience for Successful Products", which is going to come out from the wonderful publishers over at Rosenfeld Media. And so I'm sure that's making its way through the gristmill.
Jared: Fabulous. Well, Anders, thank you for spending time with us today.
Anders: It's been my pleasure. It's been great.
Jared: I want to encourage everyone who's listening to check out the books and to join us for the virtual seminar on the 24th. You can find all that out at uie.com, and thank you very much for taking the time to listen to us today, and, as always, thank you for encouraging our behavior. We'll see you on the SpoolCast later. Take care.