Delivering website development projects using agile processes, with Rory MacDonald from MadeTech

00:00 Hello and welcome to Perspective. This is a show by founders of small indie creative agencies giving our perspective on starting and running our own companies. The aim is to provide useful advice and inspiration to others as well as learn from each other and others we get to come talk on the show.

00:12 This is our 16th episode. My name is John Dark. I'm a director at Every Interaction and joining me today I've got Rory McDonald from Maytech. How are you doing, Rory?

00:22 Hey, John. Yeah, I'm really good. Thanks. Thanks for having me. Good. Pleasure to have you on. How are you doing today? Yeah, not too bad. It's good to be doing this finally. We've taken us a few goes to get it lined up.

00:34 Yeah, I always find agency founders make great guests but often quite difficult to pin down. Yeah, I can imagine. Always busy, myself included.

00:44 Yep. Cool. So Maytech are an agile development agency. Is that right? Yeah. So we're kind of a software development company. We focus a lot on kind of agile ways of working.

00:56 So helping kind of our customers and running the business using kind of agile methodologies and agile ways of working. So a lot of what we do is actually kind of going into companies who a lot of the time we have in-house engineering teams and kind of helping them to put in place kind of better ways of working.

01:21 So that can cover kind of things like software engineering practices. So using kind of more modern practices that can cover things like how do you kind of dismantle kind of team silos within the business.

01:34 So if you've got like a front end team, a DevOps team and another kind of another area which is all siloed from one another. What sort of things you can do to dismantle these silos because these silos kind of tend to cause problems in a lot of businesses.

01:49 And you generally kind of help these organizations then to get into a good place around kind of shipping software. So looking at these different techniques that we put in place to kind of help these businesses to move forward and kind of start shipping software much more much more regularly.

02:02 Yeah. And you guys you specialize in a certain technology stack? Not really. We have from a kind of marketing perspective. We market ourselves as a Rivian Rail shop for a while.

02:14 But we tend to employ people who are a non, basically polyglot. So engineers, you've got kind of exposure to multiple different programming languages.

02:26 We tend to find they kind of make stronger engineers because you've got an understanding of different kind of ways of doing things because you've seen multiple languages approach things in multiple different ways.

02:41 So you do use Ruby a lot and Rails a lot. It's not the only kind of language we use. And there's a lot of closure and a bit of go going on now.

02:51 There's some PHP. Yeah, there's a bit of a multitude of things. But yeah, from a marketing point of view, I guess we have market ourselves as a Rail shop for a little while.

03:03 Now it's good to have a mix. We also obviously have a specialism and a core that you stick to. Yeah, it is. I think with these sort of things, things evolve. I think there's new ways of doing things. There's better ways of doing things.

03:17 And I think as a kind of technology company, you need to move at times and find new ways of approaching things. And I think it'd be kind of silly for us to just stick with one thing for... And so we're going to stick with that one thing forever.

03:32 Yeah, it makes sense. So today we're going to talk about agile and how you guys use that to deliver website projects in particular. But before we do that, it'd be good to hear just a little bit of a background. How did Maytech come to be? What's your sort of journey to get there?

03:48 Yeah, sure. So my background is a slightly strange one. I started in the kind of web or software or kind of agency land in 2000 when I was very young, when I was 16.

04:03 I kind of always tinkered really with computers and kind of trying to make websites and a bit of HTML and JavaScript and all these sort of things. And it's always been kind of something I enjoy doing. And yeah, when I was kind of 16, I just started like A-level college and I was like, hey, this isn't that great.

04:19 Maybe I can get a job doing some programming. So I read there was a magazine called Create Online, which was a kind of magazine that was kind of popular back in 2000.

04:30 And there was a company that was showcasing that magazine. I got in touch with them and said, hey, I'm 16, I'm looking for some work. And they went in to meet them and they gave me a job. And it was great. I spent kind of a long time, I think about five years working there.

04:48 I guess where I consider that's where I kind of love my craft really started to really learn the process around kind of around the web and kind of delivering kind of projects.

05:01 And then following that, I went to work at a few different companies, primarily kind of creative or well, creatively led sort of companies. So there was a very kind of strong design focus in a lot of the companies I worked at between 2000 and I guess about 2008, 2009.

05:20 And I guess back then, you know, things like Flash were very popular. So I spent a lot of time being a Flash developer and heading up a Flash development team in one of the agencies.

05:32 And then kind of following that, I did a bit of freelancing a few different companies in London, a company in Boston, a company in Amsterdam. And then following that, I decided, hey, I want to kind of turn this thing into a company.

05:48 So started to build up a team, so kind of hired a couple of people, started to kind of get some work in. And I guess during this time, I'd been starting to kind of move into kind of like Ruby and Rails and some of the more modern ways of doing things.

06:03 And I guess I founded Made in six years ago. So I guess it was probably about 2010. Brought some kind of people in, brought another director into the business a couple of years later.

06:15 And yeah, I guess we are where we are now. Yeah, we've got a kind of company based in kind of London Bridge, Blackfriars. Yeah, helping kind of organizations to come to ship software and to kind of do that kind of stuff really well.

06:27 Fantastic. What would you say was the tipping point that made you really want to start your own agency in the first place? I guess it was kind of seeing a problem really. So seeing the problem with lots and lots of companies really struggling to do the delivery of software projects.

06:47 Agencies or the client side struggling? I think when I started the company, it was the agencies. But I think I've seen that kind of problem throughout on both the agency and the client sides.

06:59 So I think that was the kind of thing that made me start the business. And I guess it was a kind of funny one in that I was kind of freelancing and I was providing these sort of services as an individual to two companies.

07:15 And it was a kind of thing. It's like, hey, I can do this with I can do this and turn this into a business was the kind of thing for me. And yeah, I think it's been an interesting journey.

07:28 Cool. And at what point did you get on the whole agile bandwagon? Was that something you were doing from the very beginning? Or was it something you sort of picked up along the route and then really started investing in? So, yeah, not really. I guess it was probably about four years ago, I'd say, is when we started kind of really invested into that stuff.

07:47 And I think it's been going on for quite a while, but I think it started to kind of growing and gain some kind of serious traction probably about four or five years ago. Yeah, I don't know. I can't remember actually how we got into it. I guess just continuously looking at kind of ways to do things better and reading about lots of different ways of approaching things.

08:08 And that's kind of one of the things that kind of just stood out. And I was like, hey, this is this is something we should try and we tried it on some things internally in terms of, hey, we'd be doing a piece of work and it would be it being, I guess, the more kind of classic old school sort of waterfall set up where we fix bids and having to deliver that piece of work.

08:28 We'd start initially started delivering that stuff using agile internally without kind of using them using the actual methodologies with customers. And then at some point, hey, this is not right in that we need to get clients fully on board to these agile ways of working.

08:43 So we started to kind of as we learn kind of better and better ways to deliver software in an agile way, we decided to kind of apply these to more and more of our customers. And I guess we're continuously trying to do that sort of stuff better and learning new ways of doing that sort of stuff all the time.

09:00 And I think it's, you know, I think the agile's got a it's become a bit of a bit of a kind of buzzwords, I think probably over the last half a year. And there's a lot of places who are doing it.

09:13 Maybe it's the right thing to say, but companies who don't understand why agile works. And I think there's people are just using, hey, come on, guys, let's be more agile, not understanding the kind of the principles behind it and some of the things that are really important for agile to work well.

09:31 Okay, let's unpack that a bit. I mean, what are those things that you need to do in order to make it work really well in your opinion? I guess a lot of it comes back to the Agile Manifesto, which is this kind of idea that it's about Agile is about individuals and kind of interactions between those individuals, focusing on that over processes and kind of tools.

09:52 And Agile is about kind of like creating working software over like big sets of documentation and it's about collaboration over things like contract negotiation.

10:03 And it's about responding to change rather than kind of following the plan. And yes, it's the kind of you familiar with the Agile Manifesto? I know of it, yes. I know that there are 12 principles, is that right?

10:17 So yeah, it's basically that, it's like, hey, these are the principles that underpin kind of Agile. And I think it's important to look back at them when you're trying to put in kind of place any sort of Agile way to work and going, hey, it's this thing we're doing, sort of adhering to these principles.

10:34 And obviously, these kind of principles kind of evolve and kind of move forward. But I think kind of basically, I think it's very useful for people to kind of refer back to these sort of things often.

10:44 Right. And often people may conflate that with processes and tools and things like Kanban and other things and think that that means Agile, but they're just tools that are aimed to support the Agile Manifesto.

10:56 Yeah, exactly. Like Scrum, Kanban, Disciplined Agile, or Dad's Safe, all these sort of things are just different kind of things that are put on top of the manifesto and different kind of mechanics you can use to ultimately help you, help you deliver it really.

11:14 And I think, yeah, I'm sure there'll be new ways and new kind of methods that people use. But I think kind of coming back to the kind of the manifesto and the kind of things that it kind of really values, I think is important.

11:29 Yeah, I mean, we've never proclaimed to be Agile ourselves. I mean, we're user experience and design experts. So to us, we don't do much development. And I've always personally felt that the whole Agile methodology process has fitted much better with development on the whole.

11:47 And the experience that we've had is we have worked in Agile with development teams on projects. But in my experience, the ones that have worked really well with when we've been working on an app or a product rather than a website, say.

12:00 Yeah, for me, it's always worked, especially when you're doing something, taking an MVP approach to a project where that initial deliverable gets scaled down a lot more to make it more achievable.

12:12 Obviously, still a viable product. And I guess in the past, we've tried to adapt the process for websites, but we've always sort of fallen back into this sort of hybrid approach that's fundamentally grounded in waterfall, at least until the development part of the process starts.

12:28 Because I just found it very hard to be completely Agile about going through the steps and the processes that seem to naturally sort of flow one after the other in that waterfall fashion, like doing your initial research, then sort of validating some ideas with some wireframes and sketches and then moving those forwards down the chain into higher and higher fidelity versions and doing user testing and doing all of this stuff before you've even thought about doing any design or development.

13:02 And to me, that's always quite well into the waterfall model, and I've found very hard to sort of apply Agile to that part of the process directly. Yeah, so I guess with that sort of stuff, I guess a lot of that stuff is around documentation, right? It's about we want to be able to document what a user's going to get so a customer can see it, so a customer can sign it off.

13:25 And for us, we would take the approach that we'd want to get to the point where we've got a piece of working software much, much sooner than spending a lot of time upfront on these different kind of levels of, or these different wireframes and different levels of fidelity of design.

13:47 Because we kind of tend to find that kind of the working software piece is the piece that ultimately you can test with people and the working software piece is the thing that actually holds the value.

14:01 Because it's the thing that's actually out there and being used. So for us, a lot of the processes we put in place are around, hey, what is the kind of quickest way to get something to be in a piece of working software?

14:15 So a lot of things we try to do are like, rather than kind of PSD-led design, we try and encourage design to be done within kind of HTML and CSS.

14:26 Because we kind of tend to find that's closer to working software then than having a PSD which can be converted into, that needs to be converted into a piece of design.

14:36 And that sounds very sensible for something that's really functional, but what if it's something that's a lot more static such as an e-commerce website, for example?

14:46 Yeah, I'd say like an e-commerce website, there's a lot of function within that. Like I would say if we're looking at, we're saying kind of website is a kind of piece of marketing material, then I guess I can see it more then when it's like, hey, there isn't a huge amount of function to it.

15:06 It's more about just kind of like UI and layout and a very kind of simple piece of marketing rather than a kind of something that's got some utility or some function behind it.

15:19 But like an e-commerce website I think would be, there's a lot of decisions that need to be made within an e-commerce website. And I think, again, the quicker you can actually get key components from an e-commerce website built, I guess the better.

15:34 Right, if you look at something like a checkout process, things that kind of work well in checkout processes that have been, I guess, evolved over many, many years. So you can jump straight into something like that and get something like that built out.

15:48 Yeah, there's a lot of best practice already in place, right? Yeah, exactly. And it's like it doesn't require a big, you know, a two month sort of upfront research piece to actually get a checkout process working.

16:01 But hey, once you've got that working, then you've got some things you can evolve on and you can actually go, hey, is this thing actually working as well as we want? If not, hey, let's look at how we make this more effective or how we, you know, it could be different things you're trying to achieve.

16:18 But hey, if you want to increase the conversion rate, you want to add more fake features, depending on what the kind of business is trying to get to. I think there is a line to be drawn between products and services and kind of like marketing websites.

16:34 And I think if you're looking at a kind of pure play sort of marketing website, which has got no real kind of utility apart from marketing a piece of something.

16:45 And I think it can be more difficult to apply some of the kind of agile principles to something like that, because I guess it's more like a classic piece of graphic design, I guess.

16:58 Mm hmm. Yeah, yeah, absolutely. So even on the projects where you prefer to sort of do the design in the browser when you're working on something with more functionality, taking the agile approach to that, how do you go through sort of validation and user testing with that part of the process?

17:13 Do you build it first and test it or does it make sense to prototype stuff in a lower fidelity manner so that you can sort of decide where you're going to invest that engineering resource later on?

17:28 I think with a lot of these things, I think it depends, right? It depends on the kind of particular thing you're working on. So like for us, a lot of what we do is we, an organization will come to us and say, hey, you know, we need your help to say to with some e-commerce or we need your help with some tools for the business.

17:51 And we will kind of work with them to flesh out what are the problems, actually. So using something we're doing at the moment as an example is that, hey, we're working with one business which has got a customer service team who the customer service team spend a lot of time manually kind of processing orders and manually kind of handling, you know, filling in spreadsheets and send these back and forth between about 20 different customer service people.

18:20 And with something like that, you could approach that with, hey, we're going to do some wireframes around what is going to be the kind of optimal sort of flow to improve this and we can look at a few different things.

18:30 Or we can go, okay, what are the big problems? Let's build something quickly. So, hey, let's build a tool that will say initially will generate automatically kind of generate spreadsheet for them.

18:42 Get that tool in front of these customer service people. When these customer service people become effectively our product owners and get them to test it and go, hey, is this thing kicked in the problem that we were experiencing as a customer service team? And that's the kind of the approach we kind of tend to favor.

19:00 Hey, let's do this. Let's set aside a week to work on this problem. Let's get something within a week. We'll learn about the problem, find a very simple solution to that problem.

19:12 And then within a week we'll showcase that solution to the product owner. So the customer service team in this example, get them to use it and go, hey, how is this thing feels?

19:23 Does this feel right? Is this solving the problem? Capture some feedback and then iterate on that. And then spend as much time iterating on things as necessary to ultimately solve the problem.

19:35 And when that problem can solve, you can invest a load more time into it and kind of making it better and better and better. But hey, you could also just try and solve another problem that the business has.

19:47 And that's kind of broadly the process we take really is that it's very, very short cycles where we're working with the people who've got the problem we're trying to solve and getting something out of them as quickly as possible and then iterating on that and then moving on to another problem. And across these different types of projects you're working on, how often are you guys doing everything in-house and just exclusively working with the client?

20:12 And how often are you sometimes working with another partner who may be doing the design in UX for the client as their own sort of specialist delivery?

20:23 In those scenarios, how does that sort of process work from them doing their deliverables, you needing to start yours? Is it pretty start and stop or do you collaborate quite a bit and do quite a bit of crossover?

20:37 I think it changes depending on which customer it is. I guess fundamentally it changes depending on how experienced a particular business is at agile deliveries. I think some of our less mature customers, when I say mature, I mean less mature agile customers, they tend to favour having a big kind of design up front piece and then throwing that over the wall to dev and then us building some stuff out and then going back and forth cycling through it.

21:15 But our more mature customers, they will bring design in-house and then they will typically basically bring the design into our team.

21:27 So we'll have maybe two engineers and a designer and the designer could be part of the customer team or it could be a freelancer working for the customer or an external company who's working with the customer.

21:40 And then it will kind of broadly follow that kind of same process we were talking about before and it just got a designer embedded in the team rather than a designer doing another kind of work up front.

21:51 And then that person would contribute quite heavily to the whole research and wireframing and designing directly in the browser phase of the project with you? Yeah, exactly. So we'd start building things out and there'll be HTML and CSS stuff and then they'll start contributing to that and starting to write from the CSS and starting to make the kind of UI work.

22:14 And also then to evolve the UX behind it as well because that sort of stuff I think can gradually evolve but doesn't have to be defined up front. I guess there's pros and cons to doing it up front and not doing it up front.

22:29 Yeah, I'm really interested to know how on a web project when we meet a lot of... I mean we work on lots of different types of projects. We work on websites and products and the same is true for you guys I'm sure. But when it comes to the website side of things people tend to prefer to work towards some reason a more fixed deliverable, fixed budgets, fixed deadlines.

22:50 And when you're working on the product side of things it always seems an easier sell to convince people to go agile. And then you're sort of talking about sprints and how many of those you're going to be hoping to invest in to achieve a certain amount and get to an MVP or a certain target deliverable.

23:10 So how do you balance that with clients who sort of really want to work to fix deadlines and budgets with agile? Is that something that's possible? So I think fixed budgets certainly possible. I guess the challenge is when customers want a fixed budget and a fixed scope.

23:32 And I think we generally wouldn't commit to fixed budget, fixed scope because it's a wonderful idea to have a fixed budget and fixed scope. So we generally say at that point that hey this customer might not be a great fit for us and potentially kind of pass up the opportunity.

23:48 I think sometimes we get customers who are kind of fairly new to agile and who are kind of open to kind of agile ways of working but have not yet experienced them.

24:04 So they do struggle to understand or to work out how best to approach these sort of things. But what we tend to find works best is to say to a customer hey okay so invest in a very short iteration.

24:20 So invest in a week or two weeks and we can work with you during these first two weeks to work on the highest priority thing that you've got.

24:34 And we can constantly give a cost for the first week or the first two weeks because we know how many effective we build on a basic kind of time and materials basis. So we've got two people or three people working for a customer. We know for two weeks it's going to be 10 days or 20 days or however many days it is based on the team size.

24:58 So we can give them the cost for them two weeks and we work them during them two weeks and make sure they feel comfortable working in that way. And I think it's a good way to kind of test out if they are ready to work in an agile way.

25:12 They minimise the amount of investment they're putting in and therefore the amount of risk. We can kind of test out the water and say hey is this going to be a good engagement for us?

25:23 This is the sort of thing we want to be doing. And then for the customer within the two weeks they get something delivered and shipped and right through to production. It's like hey they see that you can actually kind of work with me through a short cycle and actually get something out.

25:39 I think customers who want kind of a hey to sign off a kind of big budget for a statement of work and to know that all these designs have been delivered in that period of time generally wouldn't work so well with us.

25:52 And I think it's about fit really. It's about making sure that there's good alignment there about between the ways of working. And if you know that when you go into something that's not going to be a good fit then it's probably not something worth the start in.

26:05 You mentioned earlier about the more mature customers from an agile perspective. The customers who are used to working agile and really know the benefits of what it can bring and so it's obviously a much easier sell to them.

26:16 Do you find that those types of clients with that agile maturity, do you find them in terms of the scale of the company and the budgets you're talking about? Are they on the larger end or the smaller end?

26:26 Because my stereotype of my mind is that the largest of the companies are always a little bit slower to adopt these new practices and methodologies and therefore more used to an older school way of doing things.

26:39 But does that mean you're always working with smaller clients or smaller budgets? How does it seem to balance for you guys? I wouldn't say we've seen the same thing there. So I'd say that for us probably our two largest clients over the last year and one of these is particularly large.

27:03 Probably the most mature agile customers we've got. Yeah, it's actually I don't see a kind of direct correlation between these two things actually. I think it's big organizations can be, you know, they can make up their challenges for sure and I think they can be kind of fairly open minded about these kind of ways of working and in our experience, yeah, it has worked very well.

27:26 And I guess for me, I think it's like the customers who come to us who are from a pure play marketing background are the ones that really struggle with agile, right? And I think it's, you know, I think it's customers who come to us from any size organization that are from more of a more of a tech background.

27:46 So it's basically a part of a kind of either part of some sort of transformation team, part of the CIO stroke, CTO stroke, IT sort of director's team.

27:59 Or they've got an engineering team in house, they tend to be the ones that have got stronger sort of agile understanding and are actually, we tend to find these sort of customers are actually keen to work on a kind of basically kind of a time and materials sort of basis for, you know, that works kind of well for agile.

28:27 And we tend to find that if customers are from a marketing background and particularly when they're from a fairly old school marketing background, that kind of the idea of agile and kind of these kind of new ways of working tend to be more of a struggle and it can take a long time to get these customers to really understand the value in it.

28:50 Yeah, makes sense. So if someone comes to you with a fixed budget and timeline, but they're willing to be flexible in scope, but obviously they have in mind what they want to achieve.

29:01 How do you manage to scope things out enough to say, given that budget and that timeline, using agile, we can deliver this project? How does that work for you?

29:11 We try to not scope things out at all, basically. Because I think it's... Because that's just waterfall, right?

29:21 Exactly. Because the idea of scope is irrelevant when it comes to the kind of agile project, right? You've got priorities and you've got things that, you know, the business that is important for the business.

29:34 But these sort of things and go, hey, this looks feasible or not. But going, hey, there's this list of 100 things that are what we call within scope.

29:44 And this list of 100 things which we think are out of scope doesn't make sense because it just sets some expectations from the upfront. Those are, hey, these 100 things are definitely going to get done. But also, I guess the thing it also doesn't matter is that there's always stuff that comes up in projects, right?

30:00 When you're working on something, the thing that a customer thinks is most important in June is suddenly the least important thing in July.

30:11 And it's like, I think when you've got this kind of idea of, hey, this is our scope of work, having the flexibility that you want within this sort of agile way of working, like the ability to be able to kind of respond to change is immediately removed if you've got this idea of scope, like a scope or scope that's been agreed within the delivery.

30:32 We try to not agree to any sort of scope. We try to go, hey, let's set aside a period of time. So let's say, hey, we're going to work together for the next six months. We're going to work together for the next three months. And you want this number of people working on this engagement.

30:48 So based on the kind of the appetite that the customer has, if a customer is talking about doing a lot of work, then we go, okay, maybe you need kind of two teams or three teams working on this piece of work, or on these kind of multiple pieces of work for you. Then we say, hey, we'll put these three teams in for six months or three months or whatever the kind of period of time is.

31:12 That's how we get to the cost. We'll go, you know, it'll be the team of three times how many weeks. And it's kind of as simple as that really.

31:22 And then, you know, we do work with customers to help them understand complexity of things. And I think that's very, very important is that, you know, when a customer wants to do this thing, you need to work with them to go, okay, what's the most sensible way to approach this?

31:38 But we tend to find the way to do that is to jump into shipping software and go, okay, so, you know, coming back to the customer service example, customer service team are spending half their time filling in spreadsheets.

31:51 What's the fastest way to improve that? And it's like, let's get some software written so we can improve that kind of rapidly and then iterate from there. And that's kind of how we do things.

32:02 So with a client who's never done agile before, they're sort of agile curious, let's say. And what kind of challenges would you find selling in agile to them in the process when you can't guarantee them a scope?

32:14 Is it just through doing the test pieces and saying that we'll do this for one sprint and you can see what we can achieve and get used to the process and if you're still liking it, then let's carry on in that vein and extend the relationship further.

32:26 Is it always done that way or is there some special sort of presentation you give that blows their socks off every time and they're just like, I'm sold, let's do it. No, yeah, there's not a special presentation that we've come up with, yeah, it's...

32:39 There's no magic bullet. There's no magic bullet. I think it's a difficult one. If customers are so insistent on having a fixed scope and fixed variables, then they're not a good fit. And I think we kind of walk away and I think it's taken us a while to learn that's the right thing to do.

32:56 That's kind of what we do now. In a couple of years ago, we would have spent time, a lot of time trying to convince customers of the value and invest a lot of time into that. And I think it's hard to do.

33:09 I mean, how can people convert them to as a sort of agile, loving clients? I mean, what will it take? Is it just impossible for some clients, do you think, to make that step or do you think someone's going to have the process to be able to turn them?

33:24 Is it impossible? I think there's little things you can do like, hey, let's agree to a one week iteration up front and go, hey, we're just going to do a very short iteration. You've got a fixed amount of risk you're holding here.

33:38 We've got a fixed amount of risk we're holding here. And let's see how that works. If customers can get comfortable working in that way, then they can slowly really kind of understand the value in it and seeing the value they're getting very like on a weekly basis.

33:51 Then you can get customers to kind of fully embrace it. But I think it just takes quite a lot of work in terms of like, you need to really hand hold them through the process. And I think that's okay. It's okay to do that. But I think I guess I've seen some customers who are very strongly against the idea because they feel like they're holding so much risk.

34:13 And I think that's not the case often. Like when you if you structured it sensibly, so you know, you're doing things in small enough chunks, then the customer wholesome risks and the customer should hold some risks because it's their piece of work you're doing, right?

34:25 And the customer should hold some risk. And so should the company delivering the work holds some risk too, right? Their neck needs to be on the liners. Hey, if you can't ship this thing, then ultimately, you know, you should lose that client.

34:37 And I think we're happy to take that risk and go, hey, we actually offer a thing where it's like if a customer isn't happy with the amount of stuff we're delivering within the first two weeks, then they don't have to pay us for the first two weeks of the engagement.

34:49 Oh, wow. We know we're going to ship lots of stuff in the first two weeks and they're going to be happy with that. So it's a risk we're very comfortable taking. Oh, yeah. I mean, you have to be confident, I guess, in your own abilities and the agile process to really turn them around. And I can imagine that that can really help sell them in.

35:08 Yeah, and that does help. You're sort of de-risking the test, essentially, aren't you, for them? Yeah. Basically a free test you can do with us. And if you're happy with the results and you want to continue, then that's great.

35:19 Yeah, I guess I hadn't really thought of it as a free test, really, because I think we offer this to every customer we've ever worked with on, even if they are kind of mature, agile customers. And none of them have ever gone, hey, yeah, we want that money back. They've always gone, hey, yeah, let's continue.

35:39 And I think it's a nice gesture, I think. And I think it does help to reassure customers who are less sure about the process. I guess the other thing I see changing a lot as well is I guess things like all the Gov UK stuff and the stuff they're doing there around kind of agile and this sort of transformation pieces, the way they're kind of trying to change the departments.

36:03 And I think that also helps because I think you can actually go, hey, you know, this process is the process now that the government is moving to. And it actually helps to kind of when businesses are seeing the government is now actually using more modern practices than they are, it helps them to go, oh, wow, okay.

36:21 This kind of validates the kind of whole way of working, really. Yeah, it's a great case study in saving billions of pounds of taxpayers' money. And government are often the last people to adopt new or potentially interesting technologies or practices.

36:36 And yeah, I guess that's a good point. If the government are doing it, then you definitely should be too. Otherwise you're way behind. Yeah, exactly. Well, yeah, certainly at the moment, the GDS and the various kind of sort of modern government departments are doing a lot of innovation around tech delivery.

36:53 And I think it's really great to see. And I think it's, I guess I hope that more and more business, big and small, start to kind of to work in this way.

37:04 And I think it's happening. That's the kind of change we've certainly seen over the last few years. More and more businesses are very comfortable in working in this way. Yeah, it's becoming a lot more common. Businesses really got to adopt it from within. I think it's quite hard to, as an agency, as an external supplier, to really convince someone who isn't convinced that they should be doing agile.

37:24 Just because it takes more than a third party supplier to make it work, doesn't it? You've got to have them completely on board with it and heavily involved throughout the process, or it's just not going to be a success.

37:35 Yeah, I think it depends on the different stages of the engagement. Because I tend to find you run into blockers with businesses which are not, you know, businesses which are not willing to or not comfortable adopting agile tend to be kind of fairly old school thinkers.

37:54 And it's generally around the kind of financial side of it that they struggle. I think once you can find a way past that sort of hurdle, then I think you can do transformation on the ground within teams.

38:06 So we tend to do a lot of that, where we will go in and we'll kind of work with, you know, kind of team of people to show them how they should be approaching kind of agile delivery. So we'll look at things like, hey, the way communications happening, we'll look to kind of pull people from within the business into the team that's doing delivery and start to kind of do a bit of a sort of ground up sort of transformation piece within businesses.

38:33 But I think it's that first, it's that kind of being able to get in there and on the ground, I think is the first thing you need to be able to do it as an external company. If you can't get past, you know, the people who I guess are holding the money and people who are holding the budgets for a piece of work, if they are not comfortable working in an agile way, you can't go anywhere then really.

38:54 But I think once you're in there and on the ground, I think you can transform a business who isn't comfortable doing agile into one that is.

39:05 And I think it takes some work and it takes a lot of just a lot of kind of like prodding in the right direction and looking, you know, seeing what kind of showing people how it's working and just kind of generally kind of nudging them, nudging the right direction.

39:21 But I think it definitely can work. And we've seen it working particularly well in some organisations. Do you put teams in house and do you find that a better way to help communicate that to them or do you find it works equally well doing everything remotely from your own offices?

39:35 Yeah, we tend to find if you're looking particularly around the transformed businesses who are not used to working in agile way, should be in agile. I think it's really useful to be on the ground in their offices. And we do that quite a lot, particularly early on in engagements where when we don't know the business that well and the business doesn't know us that well, it's useful to spend a lot of time then just really just sitting with people and kind of understanding what their role is.

40:03 So, you know, if we've got the customer service people was talking about earlier on like sitting with them for two or three days a week, just looking at hey, this is what they do, right? This is that this is this is the kind of what they're doing on a daily basis, you understand their role a lot better.

40:17 So you can then start to kind of support them to actually kind of transition into into a more, I guess, a kind of more effective. I think you can just kind of have the conversation to have a bit more, a bit more freely, I think when you're when you're on the ground.

40:30 But that that brings out the that creates a whole other set of challenges for a business. And when when everyone is on the ground in customers offices, it creates some some interesting challenges. Yeah, yeah, I can imagine for management alone, I guess, and you guys being able to manage your your staff and their deliverables.

40:47 Yes, I guess it's I guess it's the cultural thing that we have seen an impact on in the past when you have most of the company on site working with very closely with customers. And it's like, you know, a couple of people back in the office.

41:01 It's like, very quiet in the office. And I think I know those employees joined your company to be part of your culture, not not sort of being planted into someone else's all the time. Exactly, exactly. And I think it's definitely some challenges there. But I think it's like, hey, what's what's if you're going into a piece of work and your your role in that piece of work is to is to kind of modernize the way they're doing software delivery.

41:22 And I think the right thing to do is like find that is to approach that in the best way possible. And if that means spending time, certain amount of time on site and and trying to find the balance between working from your own from your own office or whether that means, hey, bring in bring in all the all the keeping from from the customer's office into your office and getting them to work within your office, things like that can help.

41:45 Just having access to the stakeholders on a regular basis does make the world of difference for all aspects of a project. Yeah, it does. Cool. So any any final tips for anyone who might be trying to sell agile to their clients and struggling a little bit? What would have advice can you give them?

42:02 Yeah, I don't know what advice would give start small. Try and try and just do a very kind of small piece of small piece of work in an agile way and kind of really get them on board with that piece of work.

42:15 So I guess a little bit I was talking about for find a week long iteration where you can go work very closely with them for a week. Make sure you've got a showcase lined up at the end of the week where all the key people involved in the project are going to be who are going to attend and then make and get a kind of nice small kind of chunk of work that you can kind of work with them on and get it kind of shipped in a week. And then basically agile is that process applied over over kind of longer periods of time. Yes, that'd be there. That'd be kind of one of the things I guess the thing I'd probably look at is more agile principles. Can you apply to more widely across the business? Can you apply kind of agile principles to your performance reviews or other things like that? Like it's all about I guess agile is about kind of lots of lots of collaboration and kind of short feedback cycles. And it's like, hey, there's other areas of business this can be applied to. Maybe try some of the principles out in other areas. Excellent. Good stuff. Cool. Well, thanks for joining us today, Roy. Thanks for having me, John. Yeah. If people want to find out more about Made Tech and yourself, where can they find you? Just visit our website and it's just www.madetech.com. Thanks to everyone for listening. If you'd like to contact us about this episode or find any of our past episodes, you can do so on our website at perspective.fm. Or you can send us an email directly on get@perspective.fm. We're on Twitter, underscore perspective.fm. You can find us on iTunes. We always appreciate ratings and reviews. You might leave us there. Tweet about the show, share it on Facebook, tell your friends. It all helps. We're easy to find in your podcast app of choice. Just search for perspective.fm in Google Music, Apple Podcasts app, Overcast, Pocket Cast, whatever you're using. All the links are on our website along with the show notes for this episode. Thanks, everybody, and we'll see you next time.