Full Transcript

Adam Churchill: Welcome, everyone, to another episode of the Spoolcast.

Anders Ramsay recently kicked off our Next Step Virtual Seminar Series with his presentation titled Designing with Agile. We're creating this Next Step Series with the help from the folks at Rosenfeld Media. Why? Well, much of the thinking in this seminar comes from Anders's book, Designing With Agile, Lean User Experience For A Successful Product. That's being published later this year by Rosenfeld Media.

So, UX design and Agile can be a frustrating experience when teams are more focused on delivery over the quality of the experience. But, the thinking underlying major agile methods such as XP or Scrum can be applied to UX design, too.

In the seminar, Anders showed the audience exactly how. The seminar has been added to UIE's user experience training library which presently has over 85 recorded seminars from wonderful topic experts just like Anders Ramsay giving you the tips and techniques you need to create great design.

Hello, Anders. Welcome back.

Anders Ramsay: Hey, how's it going, Adam?

Adam: It's going very well. For those that weren't listening during the presentation, can you give those folks an overview?

Anders: Sure. So, one of the things that has been a theme of a lot of UX designers that have been adopting Agile methods is that they've been discovering a lot of dysfunction, a lot of frustration as part of their adoption process.

So, for example, one of the common frustrations that they find is they get stuck trying to deliver all these features for a group of developers who are just building stuff faster than they're able to design it. That, really, is just an example of a dysfunctional dynamic between the user experience designer and the rest of the development team. It just really isn't a healthy way of working.

The source of that really is based on you look at the origin of Agile and the way that Agile methods were designed. They were really designed in a different world where it was a much more task oriented world, enterprise oriented world, and where, quite frankly, user experience really was not front and center.

So, these methods don't really have the UX practice in mind. So, when you try to kind of wedge user experience design into, for example, what I would call kind of a classic kind of Scrum approach, even though I want to be clear Scrum is not about a specific process but it is a framework for a way of working and it is, as such, very delivery oriented. So, it doesn't really have a lot of explicit places for where UX will fit in. So therefore, you get a lot of frustration for a UX designer who is trying to fit their practice into this.

So, in my talk what we discussed was how to step back from the specific methods like Scrum and XP and look at the underlying thinking that became the basis for Scrum. So, Scrum specifically was based on the idea of thinking of software as a kind of a rugby game and this quick intensive passing game.

If you're able to do that or really understand what that means, and we discuss that in some detail in our webinar, then that provides you with a lot of tools that you can use. So, we went through a number of specific tools, collaborative chartering, ideation clearinghouse, a more healthy UX oriented way of using stories, and a number of other methods in this webinar and I guess that's an overview and that will allow UX designers to be more effective in integrating how they work.

Adam: Excellent. Well, let's get to some of these questions.

Robert and some other folks asked about Agile and how it sort of fits into the big picture. Agile seems so focused on cranking things out. How do you leave space for the big picture?

Anders: So, in an Agile approach there's less of a focus on the up front visioning. You still do it, but you do it just more intensively and using sort of, getting back to this metaphor of the rapid passing game, so what you might do is have a number of very short intensive workshops at the very beginning of your project.

What you're doing there is very quickly capturing or involving a shared understanding among your team members but you're also careful about not trying to create what I call too much imagination overhead, meaning that you're starting to generate all these big vision documents or descriptions of this big future project.

Instead, you just do an absolute minimum of that and focus really on just people having a shared understanding of what they're imagining the end product to be. Then, there's much more focus on outcome.

So instead of visioning up front, we have a minimum vision, then we start to build something and then we compare that to that minimal vision we built, and we work in these intensive cycles. It's much more outcome-oriented, goal-oriented looking at the result of what we thought we were designing and how it compares to what we think we're designing. That makes for a much more integrated way of working.

Some examples of these visioning activities is the ideation clearinghouse which we talked about in the webinar as well as other methods like product box, elevator pitch workshops, and so forth which are other methods that have been developed specifically for this purpose.

Adam: A number of folks wanted to know how and when you include the users.

Anders: This is kind of interrelated, similar to visioning. We do do some user research upfront but rather than have this user research phase it's more of something that's more of a continuous part of the design. It's based on an understanding that you can't really understand your users, you can only understand them to a degree, and users aren't really going to be able to tell you what they want or what they don't want or what really is the feature that they're looking for.

You really need to just do a minimum of that work and then actually start to build something that they can respond to. This is a little bit taking a page from the lean start-up movement in which we establish some kind of hypothesis about the users and the establishment of that hypothesis might be based on some user research but we also might just pull it out of thin air. We have a business idea or something.

Then we devise some form of an experiment. That experiment may involve, certainly, going out and talking to users initially and the experiment may simply be a conversation. Then it gets increasingly higher fidelity so it goes from that to maybe presenting them with a paper prototype and then we start to show them a real prototype in increasingly higher fidelity and obviously want to be able to move as quickly as possible to working in an actual product.

This, again, similar to the big picture, it's more outcome-oriented and less reliant on a large amount of upfront, intensive research before we actually start building. The big shift really is you can look at it two ways. You can either look at it as reducing your user research phase or moving development into your research phase. It's just a question of there's more overlap that happens there.

Adam: Tell us about how you run your kick-off style workshops and who's typically participating in those?

Anders: The kick-off workshops in terms of when, obviously you want to run them during a project kick-off, as soon as the project begins, but it's also something that that style of workshop, which we discuss in the webinar in more detail, is something that you probably want to run something similar on a regular recurring basis. For example, in preparation for a new release, possibly in preparation for a new sprint.

Certainly if the business has in any way pivoted, again to borrow a lean start-up term. Pivoted means simply that they have, based on some kind of finding, either from feedback from customers or what the case may be, they've found their initial business hypothesis to not be valid and have made some change, a fundamental change in their direction. Therefore, we probably need to revisit our vision because the purpose of this kick-off workshop is to establish a shared understanding across the team members as well as debugging any differences in understanding.

For example, maybe the business has this one idea about what the product will be and then developers are able to debug that and say, "Well, that's cool, but this one thing that you're planning on doing we don't think that's technically feasible," whatever the case may be.

But they may also be more ad hoc so it's not so much a kick-off style workshop, it's just workshops in general. You have a continuous cadence or just a recurring set of periods where you are doing workshops, intensive group collaboration, as part of how you design, especially in preparation for each sprint but then during the sprint you might do some kind of ad hoc workshop as well.

Adam: So you brought up this idea of the ideation clearinghouse. Can you tell us the difference? What's the difference between an ideation clearinghouse and a design studio?

Anders: An ideation clearinghouse is just a variation of a design studio. A design studio is becoming an increasingly more broadly practiced methodology, sort of a structured, highly collaborative sketching that tends to be more convergent. As a team you're iterating and converging on a single solution that then will become the basis of design for let's say a sprint or something.

An ideation clearinghouse is almost the opposite. You want to capture what is the full range of ideas that are out there among our stakeholders and that's particularly of interest when you are at the beginning of the project and you are just meeting with the business sponsors. It's incredibly valuable to understand what, for example, the CEO and the CFO and the CTO or all the other executive sponsors of the project, what they are imagining the end product to look like at that point.

Because I can guarantee you that whatever you present to them, may be one month or two months down the road, sometimes they may disappear from the project, they will be evaluating that based on this imaginary idea that they have of the project. That imaginary idea may not make any sense, it may not be good design. It doesn't matter. What matters is that you have to understand it and be aware of it. That's the purpose of an ideation clearinghouse.

It's just research. It's an example really of user research but more at the sponsorship level and it's done very intensively sort of in the spirit of a design studio workshop model.

Adam: There were a number of questions about remote or distributed teams. And reality is, that's what a lot of design teams are facing these days, that their multiple people working collaboratively are in multiple locations. How do they adapt these methods for their remote teams?

Anders: One thing that's really important to understand here is that if you are working with a remote or distributed team then you are effectivley... Whoever structured your project is either one of two possibilities. Either the project foundation is based on a very deep rooted, Industrial Age mindset basically saying that people on a team are sort of these interchangeable widgets and all you need to do is go and find the cheapest widget and it doesn't matter where they're located. You know, "Oh, we have cheap widgets in some offshore location."

It's very important to be mindful that when you build a house on a bad foundation no matter how good work you may do that there's a fundamental problem there. But that said, there's still ways that you can work within that kind of flawed framework. One way is just to be Agile wherever you are so each team, wherever they're located, is practicing good Agile methods. They have a really open, accessible team room with open documents and they share information maybe in an Agile way.

One technique that has been used quite widely, especially for teams in different time zones, is the team in one time zone let's say they do a three hour whiteboarding session. At the end of the three hour whiteboarding session somebody holds up a video camera and somebody in that room does a five minute summary in front of the whiteboard of that entire session and then they share that video and that becomes this distillation of everything that was said.

But of course what's lost there is the back and forth between the team members but it's much better than nothing. Other things you can do is strategic co-location. For example, try to have some kind of co-location at the beginning of the project or at whatever point you begin the project try to find a way to get into the budget to bring up this one team member in one direction or another.

You can do what I call sort of a team member exchange program. For example, early on you can have a UX designer or front end developer from the offshore team be co-located and then as you move into development the UX designer basically becomes the specification document and basically travels to the offshore location for a period. You know, these are things that cost money but it's one way to address it.

In my opinion, the only way to be successful if you're remote or distributed is this sort of heroic vigilance and highly, highly adept skilled and experienced team members. That is why, for example, 37signals or somebody like them at that level of skill, they're able to work being distributed because they're all very senior and they're very, very skilled at what they do and that allows you to overcome that.

Adam: Adam and Gabby both ask questions in regards to how these activities actually integrate into agile development and how do they fit in with the sprint schedule?

Anders: So the question itself, how do these activities integrate in, it's a little bit like if you have a musician in a band asking, you know, let's say the bass player asks the guitar player, "So at what part of the song do I play bass and what part of the song do you play guitar?" That obviously would be sort of absurd. The guitar player's like, "We both play the song but sometimes I'm playing, sometimes you're playing, sometimes we're playing at the same time."

It's the same thing with this integration. To use a development term, it's equivalent to the concept of continuous integration. You are working, basically, in continuous cycles of a back and forth passing game. Now initially, the ball may be more in the UX designer's court and as we move to development the ball may be more in the developer's court but there is not this idea of, for example, do you do activities at the beginning of a sprint or sort of a point in time when you do them.

You can just talk about there's maybe a greater intensity of UX early on and a greater intensity of development as you move into sprints but it still is a continual back and forth. The specifics of that, those are things that I talk about, specific examples of how you do that. Those are the kind of things I talk about in the webinar such as cross-functional pairing, design studio and so forth. There are patterns but in general it's a continuous back and forth passing game.

Adam: There are some questions about the designer as facilitator. Randy wants to know who facilitates these activities? Is it the user experience interaction designer?

Anders: It may be and it certainly should be for certain parts. This is, in my opinion, a key shift in skillset from maybe a traditional UX designer who is maybe more focused in terms of being really strong at creating clear, crisp documents and giving good presentations and being able to do really good user interviews and so forth. Those things aren't necessarily less important but there's an increased emphasis on being able to collaborate either individually one-on-one at a pairing level or at a team or group level as a facilitator.

Now in terms of who should be doing this, in my opinion it actually should be encouraged for all team members to, at some point, be the facilitator because whoever is facilitating is required to really have an understanding of the project. So you should certainly encourage, for example, developers to take over and maybe conduct a design studio session or whatever the case may be.

I would recommend that you try to democratize that and not have too much of an expectation that it's always going to be the UX designer. Everybody on the team, ideally, should feel comfortable facilitating. And depending on what you're doing you might have a different person doing it.

I also wanted to touch on another thing that somebody else asked about if this only is something that would work if you're an outside consultant and it's just too much of a culture shift for in-house UX folks. I would just firmly reject that notion. That basically seems to imply that if you're in the organization where you're working in a traditional way then that's it, it's over and you can't then do anything about it.

What you really need to do there, it's a combination of a top down and bottom up shift that you will have to work through. Keep in mind that Agile is, to quote the opening sentence I think it's in "Extreme Programming", I'm not sure, but Agile is about social change. It's very fundamental. You are changing the culture of the organization but you can certainly do that from within and the way you do it from within is two simultaneous tracks.

One is you find a group of energetic, motivated people who really want to make a change and are interested in forming a team, sort of a pilot team, within the company to do this. Then you find an executive sponsor who can give this team the safety that they need to be able to work in a way that may not be conventional within the organization.

An example of that is let's say in this company everybody normally submits a weekly progress report or has to create all these documents or people need to be resourced and allocated in a certain way. You would find an executive sponsor that allows you to work in a little bit of a bubble and to work in this culturally different way.

Then if you are able to be successful, which hopefully you'll be able to be if you really are motivated and energized and really pursue this. Possibly you may also want to have a coach that helps you to get the ball rolling. But nothing breeds success like success or nothing succeeds like success I should say. If others in the company see this team as a living testimonial to this different way of working that can be the spark for generating the momentum within the company and how to make change.

I'd also recommend that you check out Mike Cohn, his book "Succeeding With Agile". He talks about this in depth on how to enable or realize this type of social change. Certainly, it is, to get back to this question, designer as facilitator or if it's something that you can only do from within I just absolutely reject it. It is certainly something that is intended for companies to undergo but it is the transformation. It is social and cultural transformation.

Adam: The fine folks at Deloitte have a question. If user experience is not involved in the pre-work before the sprints begin can you still apply these techniques?

Anders: Absolutely. You need to conduct them when UX does come on board. So the good news is, it's not that challenging to make the case for it because these are very rapid, intensive methods but if you come on board and it's clear that there has not been kind of a shared understanding across the team members of what the project vision is, team members do not feel like there's a clear sense of collaboration and they're just separated people doing the relay race, you can certainly just do it whenever you join the team.

I've done it on several projects where I came on board, it was clear this due diligence work had not been done, and we just did a kick-off at that time. We maybe didn't call it a kick-off. You can frame it and couch it in a way that will be politically expedient but still do the actual activities. Absolutely.

I'm sorry, in terms of how you might modify them that's really hard to say. That's going to be tied to the specific situation. So I would recommend, that's really going to be a judgment call for this particular illustration actually.

Adam: All right, Anders, that was fantastic, as was your virtual seminar, so thanks for circling back with us.

Anders: Fantastic. Thank you.

Adam: To our listeners, thanks for listening in and for your support of the UIE Virtual Seminar Next Step Series Program. Thanks. Goodbye for now.