Episode #167 Hugh Beyer - Getting Started with UX Inside Agile Development
Change is always an interruption. For those switching to an Agile process, the transition doesn’t always go so smoothly. Suddenly, with things moving so quickly, the role of UX gets lost in the shuffle. User experience is often disregarded in Agile development.
The easiest explanation is: it’s called Agile development. It’s about development, not design. This was the mindset around the time Agile emerged. There wasn’t an appreciation for the challenges of user experience. But now there is a greater understanding of the need to integrate UX into the Agile process.
Hugh Beyer is the Founder and CTO of InContext and author of User-Centered Agile Methods. He coaches teams on how to work UX into Agile development. One important thing to remember is that Agile is relatively new to everyone. Design and development are coming from two different backgrounds and have different approaches. Communication between the two sides is key, both to uncovering those problems with existing solutions, and in working together to tackle those that remain.
Check out Hugh’s full-day workshop from UX Immersion 2012, now in our All You Can Learn Library.
Jared Spool: I want to welcome everyone one more time to the SpoolCast. Today I have with me a friend of mine who I've known for a really long time, Mr. Hugh Beyer from InContext. He's going to be speaking at the UX Immersion Conference April 23 to 25 talking about putting UX design inside of Agile development. I'm very pleased that we have a chance to talk today. Hugh, how are you doing?
Hugh Beyer: I'm doing good. How are you?
Jared: I'm doing great. The reason I wanted to talk to you today is that I know that a lot of folks are really sort of struggling with their transition into an Agile process. I mean they were doing really well. They had their workflows really down. They were producing great designs. They were doing these fabulous deliverables that the teams seemed to really be happy with.
And then everybody shifts to Agile, and all of a sudden everything is much faster. The deliverables don't seem to work anymore. There doesn't seem to be any way to have a coherent thinking about the design process. This is, of course, compounded by the fact that Agile is new for everybody, so the development teams are just getting their feet wet at the same time. Is that a struggle you see a lot of folks having, or is that just an unusual thing?
Hugh: Oh, they're in very good company. Actually, I first became aware of this as a problem, and it was a surprise to me, when I ran into Catherine Courage at a KI Conference, which now must be like six years ago at least. She was at Salesforce still at the time. At that point you weren't seeing a lot of Agile in the work place. Salesforce had started using it. They were one of the early adopters and really went in whole hog, but not a lot of other people at the time were using it.
And I had been following Agile since the very early days and thinking, "Wow, this is a really cool development process. Finally, they've come up with something that actually might work and might make sense," and hoping that I'd be able to get involved one of these days.
When Catherine Courage said to me, "Oh, OK. This is what we're doing," and I said, "Oh, terrific. Wonderful. Is it great?" She said, "No, [laughs] it's horrible," and she started to describe exactly the problems that everybody has. "We had a way of working with the engineering team. Now we don't. They respected us for what we could do. Suddenly now they're doing this new stuff, and they don't know how to listen to us anymore."
So that was my first introduction to why this whole thing might not be as smooth as I'd thought it might be, this whole integration of the two approaches because my attitude was they go together like, I don't know, bread and cheese, and everybody ought to be happy as a result. So it was a surprise to me, but it's very common.
Jared: My understanding of the basis of Agile is that there's a lot of iteration that happens, and we've always in the UX world been really happy with iteration. We like trying an idea out and refining it and trying it. So theoretically it should work together well.
Hugh: Well, yeah. And of course, everything works well in theory, but in practice it's a different story. The thing is there's two things which you have to separate. One is there are theoretical conflicts between Agile well done and UX well done, and they do have to be reconciled. They're real, and it's not useful to anybody to pretend that they're not. So that's one thing.
But the other thing is Agile as it's put into practice is not Agile in theory. Agile as it's put in practice, typically, introduces a whole additional layer of issues and problems, which we also then have to deal with. So when you say Agile is based on iteration, yeah, well, sort of. But mostly not. In other words, nearly everybody is doing short sprints of two, three, four weeks, and that's good. And people are keeping within their time boxes pretty well, and that's good and disciplined.
But iteration, which means going back and re-working a particular piece of the system until it's right? That is just as painful as it ever was. One of the things I enjoy doing when I'm talking to a group of Agile practitioners is I tell them, "OK, so you guys, how many of you get to iterate a particular piece of functionality through three sprints until you get it right?" No one raises their hands.
"Two sprints?" No one raises their hands. "OK, one sprint?" Right? OK, now I get some hands. So the idea that you're going to go back and re-work functionality is hard--organizationally hard, emotionally hard, and practically hard because then your schedule slips. So yeah, we like the idea of iteration. The actuality of iteration, not so much.
Jared: What does a UX person have to start to get their head around in order to start working with these Agile teams and this sort of new way of thinking? What is the magic that has to happen there?
Hugh: Well, there are two things. One is to have an appreciation for the merits of the technique, and then to have an appreciation for the difficult situation that your developers are in. Then you can start to see how you can actually contribute to the solution from their point of view, which is different from contributing to the solution, right? You have to actually solve problems they know they have in order for them to start listening.
Let me take those in order. One, I got excited about Agile because it's an approach to development that makes a whole lot of sense. First, it's people oriented. Second, it is based on the idea of iteration. Third, and actually most important, it's based on the idea that on every iteration you get real customer feedback and you change your direction based on that feedback.
If you're really doing those things, then this is a terrific approach to doing development. It keeps you from getting very far off and it gives you a way to include the customer feedback that can actually affect what happens in development. A lot of very important products have been built this way, in fact, without knowing that that's what was happening. I'm thinking of things like VisiCalc, WordPerfect, and so forth.
Jared: Right. The problem with iteration, is it a problem of the teams aren't following the Agile process as it was intended, and therefore they're not doing the right things? Or is it the case that we're missing some sort of cues or moments to get that iteration to happen?
Hugh: They're following the Agile process, they aren't following the Agile intent. So they're doing all of the steps, right? But the steps say you're going to get real, valid customer feedback, and then you're going to change based on that. Because people are coming out of a traditional development paradigm, the easiest way to switch over to Agile, Agile in quotes, is you timebox everything in two, three, four, weeks, or however long you make the sprints.
You work out your functionality ahead of time, like in a PRD, just the way you always did, and then you plan that functionality into your sprints, using some vague idea of velocity, and then you go. It's just like traditional development except for you've got a base level every sprint. What that mentality leads to is, if I don't get all of my functionality implemented in this sprint that was planned and pushes into the next sprint, I have slipped. I am bad.
Jared: Yeah. I saw this. I had a team I was working with. They had a chart on the wall that had already spelled out the functionality for all their sprints for the next four months, and there was no room for slippage. If the sprint didn't do what it was supposed to do, it screwed up everything that followed it.
Hugh: Exactly. Not only that, but there's no room for discovering that half your stories weren't actually needed by the users, and a couple of stories which you didn't think to write, are actually critical. You could reduce the work you have to do to have a successful product by 75 percent if you just refocused your efforts on the things that are most important.
That was the whole point of Agile, was that you discover more about what you need to do as you go. If you're not doing that, OK, you may have a more disciplined development process, which is not nothing, but you won't get the full benefit of going to an Agile approach.
Jared: So it seems to me that that conversion process, from the way you were doing it to this new Agile thing, that's a really tricky period for people on the development side, and no wonder on the UX side, it seems like just chaos to us.
Hugh: Yes. Exactly. It shouldn't be chaos. At least it should be a development process. I talked to a client recently who has a very strong UX group, good relationships between the UX side and the development side. They described their Agile process to me, which was pretty much what I had just described to you, and they said, "What should we do?"
I said, "The first thing to do is to figure out if you're broken, because you have a well disciplined development process, you've got a well disciplined user experience process based on real customer data, and if it's working for you, then fine. You're not Agile, but, you know, there's no sin in that."
It shouldn't be chaos, right? If it is chaos, it's because of the transition, because of trying to adopt new ways of doing things. That's the problem of not changing your head. The problem of changing your head is, you don't really know what you're changing it to until you have experience with it.
You go, "OK. This is Agile. It's not traditional development. We throw out all the old rules. Don't really know what the new rules are or how to apply them, but the old rules are gone. Therefore, nothing that we did before applies anymore." This is the kind of problem that Catherine was talking to me about, and that so many people are experiencing.
Yeah. I know you, UX group, you want time to design, but we don't do up front design anymore, so be Agile with the rest of us and just give us something with no real time to do it because we're not thinking about how much time it takes to do it.
It doesn't help, by the way, that a lot of UX activities are totally invisible to the development side so they really don't know what it takes to develop a UI. They really don't know what it takes to gather customer data or to develop our information infrastructure. All of that looks like invisible magic and of course if you aren't an expert in a domain then you are pretty much guaranteed to devalue the amount of work and expertise required to do things in that domain.
It's very easy to go, "yeah, yeah, just throw something together, OK", and not realize why that doesn't make sense. The other thing that we have to do is we have to listen for where they're reaching for the new rules and help them see how the UX activities are actually critical to implementing agile in any rational kind of way.
Jared: That's interesting that you mention that because my understanding was that the original world of agile really didn't think about UX. That, you know, if you read through the documents it doesn't talk about it. I remember talking to some instructors and Scrum masters and folks and say how do you get the user experience parts of this in? They really didn't understand how to do that.
Every so often someone mumbles the phrase Sprint Zero under their breath but there was really this confusion around that because it felt like Agile didn't take user experience into consideration because it really was about sort of getting your IT process down.
Hugh: IT or even if you're developing a product the purest statement of this was given to me by Ron Jeffries, who is one of the early Agile pioneers, and I'm in love with Ron. He is the programmer's programmer, the custy, old coder architect type.
Jared: He's a great guy. I met him once.
Hugh: Yeah. And he said, "You know what? Agile development is about development. It's not about figuring out what to build, it's not about designing pretty UIs, it's about writing code. If you want to design something else and call it Agile something else, fine, go away and call it agile something else. It's not agile development."
His idea was, "tell me what to build, I'll build it, and I'll build it in short iterations with quick checks against users", he didn't have a clear sense of who users are but that's OK, developers don't, and make sure that what we produce is useful. But in the end the whole design question, using design in our sense, of the function and structure of the thing that we're building, simply wasn't apparent to him as a problem or at least not as a problem that he needed to solve.
Now that was, you know, five years ago. Things have evolved a lot since then, but that's where Agile came from. It simply did not appreciate the whole UX problem as a problem in their domain at all.
Jared: So given that, are we just spreading UX on top like icing on a cake or is there a way to infuse it like a good Boston cream pie?
Hugh: Yeah. One of the fun things about Agile is back in the waterfall world you could spread UI/UX on top like icing on a cake and you know, it was still a lousy cake but you could do it. The thing about Agile is you can't even do it anymore and that's what people are running into. You have to be integrated into the development process or you're just completely broken.
Jared: Is it the case that we actually had flaws in our old process but Agile is like a magnifying lens, just to keep adding metaphors to this conversation?
Hugh: Yeah, yeah, and we know it, right? We all ran around saying we're too late in the process, we're putting lipstick on a pig, they should get us involved earlier, they should get us involved during functional specs, they should get us involved in the PRD.
Jared: Oh yeah, I remember those days.
Hugh: Yeah. We were always trying to push ourselves upstream. The thing about Agile is there is no upstream. Upstream is downstream. Here we are. Our problem is that until we get to the point where people recognize there's a piece of design that simply has to happen as a chunk we will continue to be broken and that's a problem we will continue to have to try to solve.
One of the interesting things that's happening right now, actually, is the whole introduction of lean techniques, Kanban and so forth. Just as Agile's original conception of UX was crude at the beginning, their conception of work flow was crude. Their conception of work flow was you have a sprint, you put a story in a sprint, you work on it, it pops out of the sprint, you're done. That's work flow.
What Kanban gives us is a more sophisticated way of thinking of the stages of design that a particular feature, say, needs to go through. A traditional Agilest, of course, gets chills down their spine as soon as you say stages of design because that implies waterfall but, in fact, what Kanban does is it lets you think about how to have stages and still be Agile. Since what we do definitely wants to be one of those stages that helps us talk about how we can fit into this Agile process.
Jared: When you say stages of design what do you mean?
Hugh: In our case it will be do the customer research, figure out what the customer really needs at this point, do the high level design in terms of what's the function and structure which can be tested and iterated using our rough prototypes, do the UI design which can also be tested and iterated using our more fine detailed prototypes, and then doing the transition of that engineering which then has the engineering tasks in it.
There's multiple tasks and Agile folks have known this, they just haven't known how to think about it. Every user story ends up getting split up into multiple engineering tasks and those engineering tasks can have dependencies on each other. But up until now they all get thrown into the bucket called sprint and that's all you know how to think about.
With Kanban, you can go OK these get thrown in that bucket and have to be done before those which get thrown in the next bucket which have to get done before those which get thrown in the bucket after that and, by the way, you want to minimize waste which is to say work in progress in all of those buckets. You've got many more tools to think about how you're planning your development string.
Jared: Where does this Kanban thing come from?
Hugh: This is another Japanese thing. I will admit that I am prejudiced ever since total quality deployment or the total quality movement and quality function deployment and all that stuff. The Japanese love huge wall charts and many, many detailed processes which require tracking every last little tiny piece. So I was suspicious of Kanban. You can use it that way. You could indeed use it, and I have a suspicion that the Japanese do, but you don't have to.
The basic concepts are actually quite interesting from an Agile approach.
Jared: And so typically when folks are bringing their user experience part into this this idea of integrating with the team's Kanban process and helping them integrate that process into their development process, that's a way in.
Hugh: Exactly. Another thing I always tell UX folks is your tasks have got to be on the engineer's charts because if they are not then they are invisible and you're not part of the team and nobody cares about you and they shouldn't because who are you? Right?
Jared: These are things like the burn down chart?
Hugh: The burn down chart and a work in progress chart. Usually what teams will do is when a story gets accepted into a sprint they will break it down into shorter tasks for engineering planning. Some teams will just take the story as a whole but usually not. The UX tasks need to be part of that. And this usually means that you actually have to get your team to look a sprint ahead so that you can start your work a sprint ahead.
As soon as you start talking about Kanban, now you've broken down those sprint boundaries so it becomes much easier to say OK, we've got to start the UX tasks here because if we don't the story isn't going to be ready for development here. So it's easier to see how all of that lays out.
Jared: And so once you get your head around that, how do you keep the big picture of the design in play? Doesn't all these breaking things up into little stories and sprints focus people on the micro tasks without keeping the whole in play?
Hugh: Maybe a little bit like totally, absolutely, yeah. Yeah, no question. And it was extremely helpful that at Agile 2011, the big agile conference, one of the big agile gurus stood up at the key note and said, "You know what? You need to be a Spring Zero," which is their way of talking about upfront design which doesn't sound scary to them.
"You need to do a Sprint Zero and it's probably going to be a couple of months. It is not going to be two weeks. If you don't do that and think about what you're building and how it's going to be structured you are going to be in trouble down the road." So there is beginning to be some acceptance in the Agile community for that. It will take a while to trickle down and you still have a lot of people running around talking about big design upfront.
There it's important to remember that they are working against a real problem, what was a real problem. Spend six months, nine months, a year developing gigantic specs, half of which are obsolete before they're written, which require a huge amount of work and time investment which is not value for the customer and which end up specing something which isn't useful anymore. That's the problem they were addressing and it was a real problem. We were addressing it in our way but they were a different community.
They have no appreciation for how we were addressing it or what we bring to the table because different community, developers, it's always been the case, it will always be the case. From our point of view we have to understand that the big upfront design isn't even really addressed at us. We were just caught in the backwash. It was addressed at the product managers and the project managers and management in general who were mandating these huge, difficult documentation sets that, in the end, weren't really doing anything good for anybody.
Jared: In this Sprint Zero, I'm really interested in this idea. The thing you said, the not value to the customer. How do we make sure that everything we're doing in that Sprint Zero is getting close to value for the customer?
Hugh: If you're talking to me, because you keep going back to the customer. If what you're doing doesn't need to be tested with your customer then ask yourself very seriously why you're doing it. In contextual design the process starts with a bunch of contextual inquiries and then there's what we call consolidation envisioning which is analysis of your data and then you go back to the customer with paper prototypes of your initial ideas.
For us, that's the big danger place, that consolidation and visioning because we're not talking to the customers during that period. We're always flogging ourselves to go how do we shorten that time? How can we go back and test our concepts? How can we test sooner? As long as you're going back to the customer and testing something new you must have been designing something that was valuable or figuring out something that they're doing which will be important to you so you can design later.
The real thing with Agile is that never ends. From the moment of your first very rough conceptual prototype to the moment that you ship code you can sell you're testing all the way through. You're checking with your customer all the way through. That's the end state that we're working towards with our clients is the point where you don't even have to wait for working code to do the iterations with your customers.
Jared: All this customer involvement, this is stuff that the user research world has been really good at. Suddenly they're really valuable all the way through the development process.
Hugh: That's right. They can be. The trouble is that the developers are working very hard to solve problems we have solved 10 years ago only they don't know. The first Agile conference I went to the keynote speaker, who I won't name, stood up and said, "You know, it is beginning to be apparent that there are some issues around dealing with the customer on the team and the best way to talk to them and to encourage their involvement and we don't know how to solve those. That would be a good research project."
We're already in this millennium. It's 2000, 2001, 2002, somewhere in there. We've had the solution to this problem for 10 years at that point but it's a different community and they simply didn't have the same background. So you know, we've got to introduce it not like they're stupid, because they're not, but like this is news to them and, by the way, it should be good news. Not to get all evangelical on you there.
Jared: No, I think this is a real opportunity because suddenly they have this part of their process that dovetails nicely with stuff we've been trying to do for a long time.
Hugh: Exactly and we solve problems that they don't know how to solve. The good engineers, anyway, at this point are aware that a user is not a customer and a stakeholder isn't either. They're aware that doing a two hour demo at the end of a sprint really isn't getting them good feedback. We now have experience reports on the Agile side, on the development side, saying you know what? No stakeholder was ever unhappy at our end of sprint demos and yet our product failed.
So there is enough experience out there at this point for a listening for better solutions. Since we have those solutions if we can show them how they can actually fit into their development process and they don't have to abandon all the good things about Agile in order to use them then we've got a good story and they'll be willing to listen to it.
Jared: Well, this is all really, really neat. It seems to me that the beginning of a project, this Sprint Zero time, what we do as UX folks actually changes as we move through the project and when we get towards the end game it's gotten very different by the time we get there so we have to be very adaptable through the sprints. It's not just keep doing the same thing in these three week cycles.
Hugh: That's right and we always did. The difference is that now we have more of an opportunity to because we have to be more involved throughout the process. If you're talking to me about designing a process then you're talking about an upfront phase in which you're learning about the customer I call, teaching the customer representative on the team how to be a customer.
That's your field research, that's your analysis, that's your high level conceptual design of the solution because in the end you always have an idea of what you want to build. Dan Bricklin had the idea of what a spreadsheet should look like well before he started VisiCalc and it took 20 years to actually produce something close to his vision but that's another story.
So we always start with some concept of what we're going to build at which point agile development can start, but at that point we're still doing the detailed UI design, we're still doing the last rounds of iteration with the customers, and at the same time we're still coaching the developers on the exact meaning of the designs that we produce and we're still having to test what they've created with customers.
So we've got way more to do. We've got to do it all at the same time. By the way, one of the things about that is what we produce also has to change. The communication with developers, remember, itself has to be less about documents and more about sitting down with people and talking through the design and saying look, this works this way and this works that way and expecting them to call you up and say, "Oh, I have a snag. What should happen in this case?"
Then you have to come up with an answer off the cuff because if you don't they'll come up with an answer off of their cuff and their cuff's not as good as yours. So what we do in terms of our interaction with them has to change as well.
Jared: The challenge is for a UX professional moving to Agile, at the one time there's this whole new language, there's this whole new way of thinking, but at the same time it feels like there's a lot that's familiar. There's a lot that we know how to do and we just have to hone it and understand how it plugs in and understand how to change our vocabulary to match the agile speak that goes out there but at the same time know how what we do brings value to the game.
Hugh: That's right. One, we do have to look very hard at our own practices. Some, not all, UX teams are very invested in their product where their product is the pretty picture measured to the pixel and the full specification and so forth. That's not going to survive in an Agile environment. In an Agile environment the product has to be your understanding, your design, and your conversation with the developer.
One of the fun things about agile and one of the reasons why I like it is because this is the first time you've got a development community which is talking about the human practice. You go to an Agile conference and fully half the sessions are about how people talk to people. Right? For the first time you've got these tree huggers who are really getting into how do you make people effective. And this means that they're going to be more willing to talk to you, they're going to expect to talk to you, they're going to expect you to be visible, and they're going to expect you to be underfoot.
You have to live up to those expectations if you want to have influence on the team.
Jared: That implies that we have to be able to focus on a specific team and not do this sort of generalized one UX person to 7,000 team thing that I see in so many organizations where everybody's spread so thin they can't do any good anywhere.
Hugh: That is the big problem, yeah, and a couple of things about that. One is if you can, so you've got a few UX people supporting way too many teams but those UX people are the people who can have a view across the whole product suite.
Jared: Oh, good point, yeah.
Hugh: If you can actually make them a team, pull out some of their time, declare an architectural spike, that's Agile terms for go away and don't bother me for a sprint because I'm thinking. If you can declare a UX architectural spike where all the UX people come together and look across all the products and make some coherence that can recover some of that holistic view that we miss otherwise.
The other thing that you have to do is you have to go look, I'm a member of the team, I'm a legitimate member of the team, and therefore my problems are the teams problems. You have to show up to the meetings and you have to share your status. If your status is I simply cannot produce a dozen different UIs in the scope of this sprint then that becomes the team's problem.
What you might need to do is do triage. You might do the most important UI so you might say engineers, you know what? Do it like that other product, copy this, do something simple, and let that go. You may need to do some coaching of them as opposed to doing everything yourself. In the end you're not going to be able to add all of this to your plate and support all the teams you're currently supporting and do it all yourself and stay sane.
Jared: Right. Well, I'm really looking forward to your workshop. I think it's a great chance to learn what I need to learn and for other UX professionals to learn what they need to learn in order to really do a great job of design inside agile development and it really sounds like you're going to help us walk through what that really means in an effective, positive way. So I'm really looking for that. That's going to be April 23 in Portland, Oregon at the UX Immersion Conference and it sounds like it's going to be a lot of fun.
Hugh: I expect it to be.
Jared: Excellent. Hugh, thank you for taking the time to help me understand this agile thing just a little better.
Hugh: My pleasure.