Agile 111- Balancing UX with shipping fast in scrum? A deeper look int Agile 111- Balancing UX with shipping fast in scrum? A deeper look int Agile 111- Balancing UX with shipping fast in scrum? A deeper look int Agile 111- Balancing UX with shipping fast in scrum? A deeper look int Agile 111- Balancing UX with shipping fast in scrum? A deeper look int Agile 111- Balancing UX with shipping fast in scrum? A deeper look int

Agile 111- Balancing UX with shipping fast in scrum? A deeper look into each box of the Lean UX canvas

How do we balance UX with shipping fast in scrum? It’s a loaded question really because it’s suggesting that we need to ship, that we need to build anything.

a lot of ideas should never be built.

Ellen Gottesdeiner has a book by the title, discover to deliver and it’s a bit oversimplified but I like the strapline because a lot of ideas should never be built. And you can use discovery to discover maybe more than 70% of your ideas that should never be built. You can run cheap experiments.

How about this? You can actually talk to people. You might think that certain personas or proto personas would use your product and that they’re looking for these particular outcomes, but maybe you’ve got the wrong people.

Maybe you’ve got the right people, but they’re looking for something different. Maybe they’re not willing to pay what we’re looking to charge. It could be all sorts of things.

How do we balance UX with shipping faster in scrum?

First of all, how does UX and scrum work together?

The first thing we need to do is we need to get rid of the family feud, the UX’ers have some assumptions about the non UX’ers and the non UX’ers have some assumptions about the UX’ers and most of these assumptions are wrong, primarily because the level of transparency between the UX’ers and non UX’ers is quite low.

UX is not UI

I see a pattern of people working in some kind of UX center of X sensors, some central UX team, and we’re dividing up those people as though they are pizzas, 10% over there and 5% over here. And then that leads to the misperception by non UX’ers that UX is UI. UX is not UI. UI is about the user interface. You can have a user experience without necessarily having visual user interface.

So the first thing we do in scrum is we say, hang on a second, we need a UX’er in each team. There’s loads of UX work. As soon as we make the UX work visible in the product backlog, and we should make it visible on the product backlog, the non UX’ers will realize how much work there is. And some sprints, we will do mostly discovery because we discover something, that we’re on the wrong track.

So we need to pivot. We need to go back to the drawing board to do some new experiments, to build up some evidence about what we should build next.

In scrum, every sprint you have some increment, but at the sprint review, you’d be looking at the results of the experiments, maybe the results of interviews you’ve had as well as looking at the increment itself.

There are three options for managing the product backlog with UX in scrum.

One of them is have separate backlogs, which I would say never do that. Never say never and all that, I did find an exception yesterday, where there was a team working on the design studio for the whole company.

So they were designing the tool where you grab little widgets, here’s this menu and here’s that button and all that kind of stuff. And it was branded with company’s brand style guide and so on. And so that’s something that they were dedicated to for a while, but in almost all situations you want all of the UX work to be in the product backlog.

And within that, you’ve got two options striped or blended.

STRIPED PRODUCT BACKLOG

Striped essentially means that the whole backlog would be like a barcode of UX and non UX work. So maybe, we need to do a customer interview, or we need to do a wire frame.

We need to do low-fidelity prototyping, we need to do a high-fidelity prototype. We need to do a wizard of Oz experiment. We need to do a concierge experiment. We need to recruit some people that match the proto-personas that we think might be using our products. These should all be in the product backlog.

When the backlog is striped, it leads to a problem that you don’t know what you’re going to discover, but that’s going to be the situation anyway. When you’re trying to discover you actually don’t know who’s going to be using this and you don’t know what they’re looking for. So we need to be comfortable with not knowing stuff anyway. So striped for me is actually fine.

What I like about striped, this is my personal opinion, we get rid of this execution bias where we think everything needs to go from discovery to delivery, which is not true.

BLENDED PRODUCT BACKLOG

Blended is the other option where you have product backlog items that are a bit bigger, you’ve got some discovery and then you’ve got some delivery and you need really good capability in the team, almost telepathy within the team so that we’re not reviewing the designs like 10 times.

It’s almost like I say something like to Vanesa , she just gets it. She turns it around and it’s perfect. It’s even better than I would’ve thought. Unless you have that kind of telepathy and skill level in the team, blend is going to be difficult, but you could also do a mix and match between blended and striped, but you would have one product backlog.

Daily Scrum

And we’re going to be putting UX on the agenda for each of the events, the daily scrum, does anybody want to come along to our customer interview today? And does anybody want to take notes? Because if I’m doing the interview, I want to be focused on the customer so maybe non-UX’ers are willing to do that.

Is anybody willing here? And that’s really nice. Cause a lot of non-UX’ers think, oh, I don’t want to see the customer. I just want to put on my headphones and all that. Not all non-UX’ers are like that, but a lot of them are.

But what they realized as soon as they go along and they watch the customer interacting with the prototype, they realize ‘oh, wow. I didn’t know you were using the product like that.’ Yeah dude we’re using it like that. So light bulbs go off really for the non-UX’ers and the key message is that UX’ers will be coaching, teaching, mentoring, willing non-UX’ers on the scrum team all things UX because there is too much UX work to be done.

In my personal opinion, the learning’s going to be one way, the UX’ers will be teaching, coaching, mentoring, the non-UX’ers, all things UX. I don’t really see it going the other way cause there’s actually too much UX there. UX is never finished.

So then in the daily scrum every day, like I mentioned, UX is on the agenda if you like.

For me, there’s two questions at the daily scrum, this is my opinion:

  1. What do we need to work on together today? That includes UX.
  2. Is there anything that we forgot about? That’d be, we started, we didn’t finish it and there’s some things blocked or something like that.

Sprint planning we’ll be talking about what do we need to discover this sprint? What increment do we need to deliver? And by the way, if you’re trying to decide, some items, how do you know whether you need to do any experiments? But if you’ve got loads of evidence, just build the bloody thing.

Learn humility.

But if you don’t have evidence, maybe there is high value, but maybe we’re not so comfortable with our ability to harvest that value. So maybe you need to do some experiments. And a lot of the time, even really confident people, I did this with 228 people at a London university earlier this year, a lot of people really cocky about hybrid learning, what we meant by hybrid learning was people are on teams and zoom and people face-to-face at the same time, that working how well that would work and people, oh, we’re going to use metaverse. And then when they did the interviews, they found out no one would want to use Metaverse. I knew that, but like they learned humility.

That’s what it’s all about. Learning is the first citizen when you combine scrum with UX. At the sprint review, we’d be looking at the results of the experiments, the results of the customer interviews, as well as looking at the increment. At the retrospective, we’ll be talking about, how can we be more effective as a team?

The scrum masters’ game has to jump up as well because she needs to understand more about UX probably should be trained. I see a lot of people come into my scrum with UX workshops, what happens is they send one person from the team. I’m thinking of doing something like the mob programming crew does, maybe have a team price cause the whole team should come. You don’t just learn as one person, then that person transfers that knowledge.

You need to experience it. And we use the lean UX canvas. We go through the lean UX canvas, a very simple eight box canvas.

Box 1: what problem are we trying to solve?

You can write it in free form text. You can use the elevator pitch from Jeffrey Moore. We like to use the business problem template because it’s very clear. Really clear and also expresses what problems we’re trying to solve and how do we know that, some goals aren’t being achieved and how would we measure success and so on.

Box 2: Business Outcomes

And then we look at what are the business outcomes? What would change for the organization? How would we know that we solved that problem?

Box 3: What proto persona will you use?

Box three is, what proto personas will we use? Proto persona doesn’t mean prototype of a persona. It’s just a made up word actually for our best guess at who the persona might be. There’s no point really in going into six months of high polish, high ceremony, research into who the personas might be.

If you have it, you can take it as an input and it might be very useful input, but really, the scrum team collectively would take a view on what would be the best guesses in terms of who might be interacting with us.

Box 4: User outcomes & Benefits

And then our best guess as to what outcomes they’re looking for, the customers and the end user, customers are someone who pays and an end user is someone who uses for example, there’s a car downstairs, Magda owns the car, I’m a user. Magda is the customer.

Box 5: Solutions

It’s only box five out of eight that we start talking about solutions. So yesterday I was doing wire framing. We did crazy eights from Google design sprints, where you fold a letter page, or an A4 page if you’re in Europe page in half, you fold it in half again, fold it in half again, you fold it back out and you’ve got eight squares, if you like, or eight rectangles. And every minute you do a new sketch And it’s really nice to just brainstorm some ideas, your ideas get crazier as you go along. That’s why they’re called the crazy eights. The politically correct people call them the active eights.

And then you might do some wire-framing, some prototyping. You might even do a service design, McDonald’s restaurants, I believe the people who got that going at the start, you can see that they were actually trying different designs for the restaurant on a tennis court.

So check that out, the founder, I believe it’s on Netflix.

Box 6: Hypotheses

Box six, after collecting all of those assumptions, what problem are we trying to solve, what organization outcomes are we looking for.

Who might we be targeting this at?

What outcomes are they looking for, what solutions might we offer those?

They have a lovely, simple template in box six. It’s like clicking together Lego bricks, it’s really very well done.

Fair play to Josh and Jeff for putting this together in the Lean UX, the third edition book is out by the way, Lean UX.

Box 7: What’s the most important thing we need to learn first?

Box 7 you say, okay, what’s the most risky of all these assumptions that we have here, you might pick the riskiest hypothesis and the hypotheses by the way, click together the assumptions from boxes one through five. They’re all assumptions that need to be tested.

In box seven, we’re saying, okay, which one of those is the most risky and do you really want to wait until the end of the year to find out it is a big risk and it’s going to kill us?

You probably want to tease that out earlier. So we do that in Lean UX canvas box seven.

Box 8: What’s the least amount of work we need to do to learn the next most important thing?

Box eight, this is really where the penny drops for people. I’m looking forward to this in the class tonight with some people where you say, okay, what’s the smallest effort to learn the next most important thing?

And they think of wild ideas. What can you do in 30 minutes, 30 minutes? What can you do? What can you do in a day? What can you do in a week? What can you do in half an hour? Pick up the bloody phone, talk to a customer, you dream up all this stuff, just talk to someone, find out will they actually use it. And a lot of the time….

you’ll find they won’t.

You should never do a proto persona by the way, on someone you know.

I had a class last year with people from the Netherlands, it was hilarious. You should never do a proto persona by the way, on someone you know. Anyway, they decided to do it on me, they said, okay, you’re Irish. And they said, I’m cranky because I’m cranky most of the time and they made some assumptions about me. They had this persona, I had some exec MBA students as well last July, they did the same thing, they did this proto persona, her name is Caterina, she does this and she does that, these are her needs and these are her wants, and this is her friction.

And then I said did you recruit a Caterina? Did you actually pick up the phone and talk to someone like that? Really?

So anyway, after the course, I said, gals, guys, would you mind interviewing me on Monday morning? It was a weekend class.

They said, yeah, okay, let’s do that. So they had a chat with me and they assumed that I was a BMW driver, that I drive like crazy, that I break all the speed limits, that I have this little gadget over my visor for detecting the speed limits, the speak ons and all that from the cops and so on.

I said guys I’m not like that. If you met me 15 years ago, I was like that. You drive fast in a BMW cause you can, you’ve got the power, it’s got brilliant machines, but now I drive a Land Rover. It takes two seconds from the time I hit the pedal before the thing bloody moves. I said to Magda last week and she said, you should’ve moved there.

Magda, this is a Land Rover. It’s a little bit slower. Make allowances here. And also there are cameras in the UK. I used to live in Ireland. I used to get away with lots of things, but you’ll just get fined that, you can drive on the road, you get five fines within two miles and you’re done.

So I don’t drive like that anymore. The cameras have changed my behavior so their assumptions were all wrong about the persona. And then they discovered that I would never have bought the product. So they were thinking of building something for someone who’d never buy this thing.

So the Lean UX canvas is lovely.

Where’d you review that? You review it in product backlog refinement. Product backlog refinement becomes the nerve center in scrum it’s an activity. Good scrum teams would actually have it almost as an event, in multi-team scrum, it is an event. Nexus, unless it’s an event, you have to do. It would be chaos if you didn’t.

And so within product backlog refinement, you look at the Lean UX canvas, you say okay. We interview these people. When I had students earlier in the year going through a canvas for four days, they went through the first time, they found out their assumptions are wrong when they had interviewed people. We need to go back to the solutions, other teams had to go back to the personas.

You’re learning all the time

Some teams had to go back to the business problem statements. They had the wrong business problem statement. That’s the thing, it’s iterative. You keep going back. You’re never done. You’re learning all the time. Learning is the first citizen, think you’ve got enough evidence, you should build this thing, build it.

what is quality if you don’t know who the customer is?

For me combining scrum with UX deals with the fundamental flaw of the lean startup. With the lean startup, give Eric Ries some credit, he said, what is quality if you don’t know who the customer is. Fair point, genius comment actually.

what’s the point in delivering good stuff when you don’t even know who the customer is?

When I was at a lean startup conference in 2013, streamed into London from San Francisco, there was some company rented a room, 30 people in the room and I looked around and we were chatting and all that kind of stuff and I said, look me in the eye and tell me that when you validated your assumptions that it was the right product, you had the right personas, you had the right outcomes, you have the right solutions, they would pay for it, look me straight in the eye and tell me that you turned down the quality switch, cause in Lean Startup startup, you deliver crap because what’s the point in delivering good stuff when you don’t even know who the customer is.

scrum has this definition of done and that’s your quality stamp right there.

With lean UX and scrum, when you get those experiments converted into evidence, then scrum has this definition of done and that’s your quality stamp right there.

It’s genius. The combination is beautiful. And actually, if you ask me, you also need to combine it with Kanban. Some people just do Kanban with UX actually. What I like about scrum is at the end of the sprint, you do look at what stuff has finished. Kanban looks at stuff that is maybe gone over a boundary if you like, there’s no boundary if you like from one time horizon to the next.

How do I balance it? I don’t want to ship fast necessarily. I want to discover fast. I don’t want to deliver fast and I want to deliver what we discovered is maybe the right thing to build. Let’s go back to Russell Ackoff, that famous consultant who taught at a number of universities in the United States.

I would love to have been in his class while he was teaching. Must’ve been such a privilege for the people who were taught by him because he was like a storyteller, you’d listen to the guy all day. He had this statement, I’ll say it twice.

‘The righter you do the wrong thing, the wronger you become”.

I’ll say it another way.

The more right you do the wrong thing the more wrong you become. So do you just want to be a feature factory, delivering sausages that are completely wrong? Delivering stuff and shoving it out to the market completely wrong, or do you want to be figuring out what the right thing is to do?

So if you’re doing the wrong thing, you’re kind of screwed. If you do the right thing and you’re doing it a bit wrong, you can use these retrospectives to correct your team effectiveness and you can use the sprint reviews in scrum to course correct in terms of what we should pivot next. You have to make decisions ‘do we persevere?’, which is what most people do, they go into execution bias, or should we pivot, which is the smarter thing.

Scrum with UX, is looking for value. It’s like, where’s the value? Where is it? It’s not over here, it’s over there.

But it’s really really cool, and I hope you check it out.

That’s the question for today, I’ve got loads of other questions coming in.

If you want me to deal with any question on your mind, just comment on whichever channel you’d like, whether it’s on Instagram, Twitter, YouTube oe Medium, wherever you’re watching this, I’d be delighted to get your questions and answer them.