DU010 – When Agile Goes Wrong

Transcript

The Design Untangled Podcast

Episode: DU010 – When Agile goes wrong

Host: Chris Mears and Carla Lindarte

Length: 22:06 minutes

February 19, 2018

[00:17] Chris:  Welcome to Design Untangled with me Chris Mears, and with me once again, this time around is Carla Lindarte. Hello.

[00:24] Carla:  Hello Chris, how are you?

[00:27] Chris: I’m good. The second time we’ve recorded this because what happens Carla,

[00:31] Carla:  Because my bloody laughter was in the recording. I don’t know why. It wasn’t me. The button was disabled. Sorry.

[00:41] Chris: This podcast is basically just a series of technical errors on our part, in terms of recordings and mikes and stuff.

[00:49] Carla:  Yeah, well we should just do it more often, like together face to face, but then when we do it, it’s really windy and noisy. Well I hope our listeners can still enjoy or at least not hate what we say.

[01:03] Chris: Well, we’ll see. So far the comments haven’t been too bad, but you wanted to do some plugs before we get started.

[01:10] Carla:  Oh yeah, because we always say at the end and then I think maybe people can be bothered to listen to the end, so if you have any feedback for us or want to hear more about what we have to say, or just want to shout and say something. Do you hate Christmas music in the introduction of the podcast, just follow us on at Design Untangled, and that’s it. I’m just going to leave it to that one, because I think Twitter is where we have it the most active members saying stuff. Right now we have new followers.

[01:45] Chris: Yeah, we’re definitely picking up a big following of about 20 people on there. So come and join the party.

[01:52] Carla:  That is an amazing achievement. . So we are talking about Agile today, not because we don’t have anything else to talk about, but because we wanted to kind of follow up after the amazing interview that Chris Mears did for the last podcast.

[02:13] Chris: You don’t need to use my surname, Carla.

[02:17] Carla:  Oh, I don’t know why I always say Chris with Mears.

[02:23] Chris: So formal.

[02:23] Carla:  I am very formal. I am very formal. I learned English in England, so that’s why I’m very formal when I speak. No, I didn’t, but anyway. So we are going to talk about what’s the role of Agile in design, and what do you think about it? But if we think Agile is not the right methodology to do our design project. We can still say that. At this moment everyone talks about Agile and sprints and blah, blah, blah, but in my opinion, sometimes you don’t to go Agile. If you needed to be more creative will explore more options because the pressure of Agile sometimes pushes you to just ship stuff without really thinking about it really well. I used to work with a guy who used to say that fast moving shit is diarrhoea. So basically you could go really, really, really fast but actually it could be very shit what you’re designing. So I don’t know, sometimes a little bit of thinking time helps.

[03:31] Chris: Yeah, I think that’s one of the big challenges UX designers and researchers have with working in the agile framework. I mean, ultimately it was invented to deliver software kind of before UX became much of a thing and UX has had to fit within that structure somewhat, which I kind of spoke about on the interview last time, and the problem with that is you don’t get a lot of time to think outside the box. So an eCommerce example might be the product page or whatever, and because you’re working in a two week sprint, you wouldn’t have time to explore, maybe do we even need a product page? Are there other ways that you could show product to people outside of that? It’s kind of almost a done thing before we start that that’s what you’re going to do and then you’re just kind of trimming around the edges rather than really exploring the problem space.

[04:31] Carla:  Yeah, exactly. I mean that’s a very good example. In eCommerce project, you can start with the product detail page, but then that could be your first item in the development plan, which doesn’t make any sense. I’ve actually experienced that in the past and when we did that, we actually changed it a little bit. So we started planning with obviously the BAs and the project managers around templates or chunks of features, chunks of information, and then we moved away from that and started looking into journeys. So even if it was a long journey, for example, in the shopping in eCommerce context, it was add to basket was one journey that we could tackle in one or two sprints, and it was okay to do that because we were going a little bit ahead from development and that could be a solution as well as something that I call WAJOE. So basically just start design before development starts. So then you have a little bit of lead time to explore more options, to think about things in a journey, rather than an isolated template or feature.

[05:43] Chris: Yeah, so we did touch on that when we were chatting in the park a little bit and Clive calls it the runway. So it’s basically identifying when you are thinking about tackling a certain thing that you know. Adding to bag might be the end goal and you then kind of plan backwards from that what your research and design activities will be to kind of explore that space and get to a solution before it gets to the developers so that you’re not kind of chasing your own tail to get them something to build. You’ve had a bit of time beforehand because you knew it was coming up to do the necessary research and design you needed to do.

[06:22] Carla:  Yeah, exactly. Another big mistake that I see now apart from the eCommerce example is that sometimes, and I can say that from experience, that sometimes we call things Agile without really being agile. So what I want to say is that sometimes we just stuck to a design only project where we say we do our job because we used two week sprints, but we are not really developing anything. We are just basically prototyping and designing stuff and I think there is value to go a little bit ahead, but I don’t think that even if you go through an agile process to deliver a prototype at the end of the day, this prototype which isn’t built, the end product could be really bad if design ends there because it’s basically being waterfall, right? If I just spend three months building a proof of concept, but it’s just an Invision clickable prototype or an actual critical prototype and then hand it over to development so they can go and build it, that’s basically waterfall, isn’t it?

[07:34] Chris: Yeah, pretty much. It’s really important that you are involved during that build process and that you have good relationships with your developers so you can trash things out. They’re always going to have particular viewpoint on sort of feasibility of stuff and how much effort stuff is, and you just need to make sure that your design, the user needs aren’t compromised by those compromises, and if they are, it’s a discussion you need to have with your product owner.

[08:00] Carla:  Yeah, exactly. There’s a lot of talk these days about Agile and sprints etcetera, but sometimes they don’t really reflect what the actual methodology is. I think you touched very briefly on spikes in the interview that you did, so I think it would be good to explain people what spikes are and how can they be used.

[08:27] Chris: Yeah. So a spike is a little piece of work, which is outside of the main delivery part of the sprint. So a development example might be, I need to go away and figure out how to integrate paypal or something like that. So it’s not something they’re delivering as part of that sprint that would be releasable codes or product. It is basically a research task essentially, and that gets estimated as well as a piece of work that needs to be done but there’s no actual code or product delivered at the end of that.

[09:02] Carla:  Yeah, we’ve used it as well in our teams to do research pieces even if it is with actual customer research, or a lot of competitor analysis, or we just build something very quickly to see if some kind of interaction can be done. So it could be from any nature. It’s just a little bit of time that allows us to explore a hypotheses that we have, and to try to inform the development in the following sprints. So that’s quite good. We use it all the time. Another good best practice when you run an agile project around research, especially if you have end users involved or customer research is obviously try to do every sprint, if possible. Actually this is something that I was trying in one of the mobile projects I was overseeing, if you’re going to do lab testing, you can actually do, for example, in an hour, you can do half an hour of usability testing of something that you are building or about to build. But you can also use the other half an hour to do some kind of what we call generative research. So some interviews or some concept testing, or sometimes we even put it in front of users different types of taglines and copy just to get peoples’ thoughts, and the idea with that is to inform the following sprint. So we already have some insight from customers, so we don’t use the sessions just to do usability testing, but also to learn more about peoples’ mental models to inform the following sprints.

[10:48] Chris: That’s a really good technique, and I think the other thing that we didn’t really chat about in the interview is kind of re-prioritizing stuff. So it could be that during some of that generative research or even the lab based stuff, it kind of affects your view as a UX research team about how important stuff is. So something you kind of thought might be a minor thing, we’ll leave it till the end of the project actually becomes a lot more important and you need to shift that up as a greater priority against something else. So it’s important to keep that in mind as well when you’re doing these pieces of research and feed that back to the team as well.

[11:28] Carla:  That is actually really, really important. I was listening to the podcast from… because I also listened to other podcasts, not to ourselves.

[11:37] Chris: Oh traitor!

[11:40] Carla:  It’s the Designed Better podcast, the Invision podcast. It’s really good actually. I highly recommend it. There is an interview with Jake Knapp, who is the creator of the sprint, the book Sprint, and he talked about obviously how he came about the idea of writing that book. Oh, well first of all, to create the methodology. So when you are in a big, big program for example, or do you realize that there is something that you still need to explore more, or a new question that you already have answers for. Sometimes running a design sprint, if you have the right people obviously, and if you have the commitment from the people, the important decision makers, running a design sprint is actually quite valuable because, it could be… obviously it has to be outside of the development sprint if you are building something, but it could be a very good way of going very quickly through a series of hypotheses, deciding which one is the potential solution, and testing it with customers very quickly to kind of move forward into the sprint and feed that back into the development sprint. He actually said he created it because… and he actually called it a sprint…. actually, it was more attractive for developers because of the are obviously following the agile methodology, but it was a way to get everyone together to come up with a potential solution to a problem. So of course sometimes there are time limitations and peoples’ limitations, but it could be good also to use that as another way of making sure you have enough knowledge and enough insight to make decisions on something that’s going to be built.

[13:23] Chris: And I think that touches on probably one of the main benefits of Agile from my point of view. It’s not shipping codes. It’s more that you are bringing the team together and kind of sharing the knowledge, working on problems together. So you are all moving forward with the same idea of what you’re trying to accomplish, and in waterfall world, it’s pretty much one person writes the thing. They pass over to the next thing and never speak again, and it just goes on like that, and no one’s really taking ownership of the entire product.

[13:55] Carla:  That is so true. I think that’s what one of the most powerful things, because they’re self-organizing teams who make decisions and are part of the same team all together. That’s why I find it really hard when you have different parties, especially on a development project. My experience is mainly on developing stuff, but if you get a third party doing the research and a third party doesn’t do design and another third party doing the development and then you have the client, I mean it gets so bloody complex that unless we all kind of representing the same purpose, it could get really slow. Even if you go with two weeks sprints, you could go there for years, because there’s just the complexity of it. Sometimes big clients have that kind of complexity.

[14:49] Chris: One of the other problems found with agile is because maybe I’ve just never worked in an organization that’s just been agile from the start. It seems that you spend 50% of the week talking about how you would do a particular thing in agile rather than just doing it. So it’s meetings about okay, we want to do this, but how do we break that into stories? How do we put that in Jira or this stuff? Whereas you could just used that time to kind of done the task and move on.

[15:21] Carla:  Definitely. There’s a lot of Agile talking in an agile project. Everyone talks about, oh, how long should it be the retrospectives? So we have a meeting to talk about how long the retrospectives should be. It shouldn’t be that complex. I think you’re right. A lot of organizations, especially when we work with big companies or the government as well, they’re going through that change trying to adapt new ways of working, which takes time, and it takes also a lot of courage because they are used to one thing following after the other and then suddenly everything is just mixed up and it’s really hard to control. So, I think that’s why people talk about agile so much.

[16:03] Chris: And I guess the dream state is that you don’t even sort of realize that you’re using agile anyway. You’re just working in a particular way and that’s just how it is. So that’s kind of the end goal probably, but many places are not quite there yet unfortunately.

[16:18] Carla:  No, but we’ll get there. I think more and more organizations are adopting it, and also sometimes you do just like, if you just need time and then you have to be in a more senior position or at least being able to influence the delivery plan, but if you could just say, look, we just need a month or two weeks or three weeks to actually go deeper into this problem before we even start with this development or the sprints or whatever, I think it’s fine as well. We don’t have to be Agile obsessed, which I think people, especially the designers are becoming like that because everyone talks about it. We all need to do it. Sometimes it’s okay to say, look, we don’t have enough information about this. We need more time as a design team to explore more options, to go deeper into customer needs, etcetera. So my point I’m trying to make is that you didn’t have to say, Oh yeah, Agile is the only answer because it’s not

[17:18] Chris: Even, you know, just don’t be scared of asking that because from a project point of view, there may well be stuff that can get brought forward that maybe doesn’t need that much design or research input to it that can be got on with whilst you explore that other area as well.

[17:35] Carla:  Yeah, definitely. I mean, back end integrations could take a long time, maybe also more discovery from a tech side. There’s a lot of things that could happen. Developers can start doing a lot of work, without just getting all the designs down very quickly. I think, well, as a designer, what we need to do more and more is just try to first involve engineering in the design process as quickly as you can, and second is just try to be the representation of why design is important. Sometimes it’s depending on the engineering teams that you work with. Sometimes they see designers as road blockers, the people who’s going gonna slow down the process, but actually I think more and more we all need to have the responsibility to try to bring the value of design to them and get them involved. Invite them to the user testing sessions. That’s something I started doing as well and inviting everyone including BAs and engineering teams to gain peoples’ needs, and I think as design thinking methodology says everything that we have in common, like engineers, clients, designers, everyone is working for a type of user or a number of users. So the only thing that we have in common is the user. So we should use that as designers to kind of bring everyone together, and I think that’s why it’s so, so valuable to keep doing research and bringing our customers into the process.

[19:09] Chris: Yeah, it’s a tricky one because everything about our job is trying to understand as much about the design problem and the user as possible, and everything about agile is about delivering stuff as often as possible, so there’s a tension there. I’ve seen it work, I’ve seen it not work. It’s difficult to kind of pin down exactly why it went one way or the other. Sometimes you just get the right people in the right place at the right time and they just make it happen. Other times, if there’s any number of different things that can cause things to go off track, but yes, by no means an easy feat. So if you are in an agile project and you’re finding it frustrating, I’m sure you won’t be the first person. but equally if you’re in an agile project and it’s working very well, it would be great to hear about your experiences on Twitter or wherever else you want to get in contact and yeah, be good to share those, I think.

[20:08] Carla:  Yeah, that’d be really good. Especially when you do agile projects, then you have an offshore development team that’s really hard as well. But anyway, there’s a lot of agile, painful audio projects happening currently, but I’m sure we’re going to get to the point where we get it sorted. I think we are just still exploring and learning from it.

[20:30] Chris: Yep, definitely. All right. You got anything else?

[20:33] Carla:  No.

[20:34] Chris: Agile 2.0. ?

[20:35] Carla:  No, I think I’ve said what I wanted to say about Agile.

[20:38] Chris: Shall I finish doing the plugs then?

[20:40] Carla:  Yeah, finish it to see we could get more followers this day. Let’s get to 22.

[20:50] Chris: I’m sure I can convince my mum and Dad to follow us.

[20:53] Carla:  Oh yeah. I’m going to get my mum and dad to do it as well, They won’t understand.

[20:56] Chris: We have got 24 already. I saw it. Okay. So remind you of the Twitter, which is @designuntangled. We’ve got a Facebook page as well now, which is also design untangled. A website. Can you guess what that is, Carla?

[21:11] Carla:  designuntangled.co.uk

[21:13] Chris: Wow, you’re listening! Okay, and you can get in contact with us individually on Twitter as well. So I’m @Chris_mears_ux. You’re @CarlaLindarte. LinkedIn and also…we all love LinkedIn. You can always find out if someone’s a good job candidate by how they treat the receptionist. You see that one on LinkedIn?

[21:37] Carla:  No

[21:37] Chris: That’s posted like every single day by 50 different people, and subscribe on Apple podcasts as well, because then you don’t need reminding that new episodes are out. They will just come straight to you.

[21:51] Carla:  Yeah, we will come straight to you. Okay. That’s it. So I’ll see you in … Is it two weeks?

[21:58] Chris: Yeah, it is two weeks

[21:59] Carla:  Yeah. See you in two weeks.

[22:01] Chris: All right. See You.

[22:02] Carla:  Bye. Bye.