The Bookster Podcast: Are we agile?

Transcript

Hello, I am Simon and welcome back to the Bookster podcast from inside the SaaS holiday rental software company Bookster based in Edinburgh, Scotland.

Follow along as Bookster, discuss their journey and their inner workings.

Thank you for joining us, and we hope you find these conversations insightful and ultimately helpful.

Now, I'm joined today as always by CEO and Co-founder of Bookster, Robin Morris.

Minute 1

Robin.

Hello.

Hello.

How are you doing? Uh, I'm fine, thank you.

Yes.

Um, good to see you again.

Uh, also today we're joined by Bookster's technical director Colin Guthrie.

Colin, thank you for joining us.

Uh, not problem.

Delighted to be here.

Thank you.

Um, I think as you're new to the podcast, Colin, it'd be great to just hear a little bit about, uh, what you do and a bit about your background, perhaps with Bookster.

Yeah, sure.

So, um, myself and Robin founded Bookster many years ago.

Um, well, in previous incarnations we've been working together since, um, early 2000, really.

Um, yeah.

Um, I am essentially in charge of the, the technical side of things at, at Bookster.

Um, I am the sort of, uh, senior, uh, architect and developer.

Um, I'll be the one that sort of does all the, the main integrations with third parties

Minute 2

and works with APIs.

Um, we're a small team in terms of, uh, headcount, so, um, a lot of my role is also in, uh, operations, um, DevOps, I suppose.

Um, so I'll be looking after servers, making sure they're running as smoothly as they can, um, making sure everything's secure and updated.

Um, and yeah, generally sort of steering the, the development, uh, process and, um, along with my colleagues, the direction, uh, in terms of the technical development.

Fantastic.

So a busy man then, in short.

Uh, yeah, it seems so Good.

Uh, well, great.

Here we are looking episode eight already.

Um, so what we're gonna, we've talked about many things so far, Robin.

Um, it's been a good conversation.

And have we, we have, yeah.

Uh, and today, let's, Let's stop That here.

Let's stop right there.

Yeah.

Quite While we're ahead.

Um, yeah, so today

Minute 3

for this episode, we're gonna talk about, uh, how agile book star Bookster is.

Sorry, um, book star's a whole different podcast.

Uh, so I guess like the Best offer you play you of the month as the book.

I guess it would be useful just from, I guess maybe Robin, you could help us out with this one, is what you mean by sort of agile, uh, when you say that.

Yeah, I mean, what, uh, what we mean by agile might, uh, not necessarily line up with some industry ideal, um, but I can explain what we do or roughly what it is that, how, how we work basically, I suppose.

Um, and yeah, what we think is, is a sort of agilely process.

So broadly speaking, uh, agile is really about when you try to do very short, uh, cycles of development or work, uh,

Minute 4

and then get it out the door quite quickly with, um, you know, and get in front of real users as quickly as you can, um, with small sort of hops in a direction of where you're trying to go.

Um, rather than the, the alternative to that is you set out a plan right at the start and you say, these are all the features we want.

And you just develop and develop and develop until you get to that point where you've developed the features.

So instead, you put up what agile is, you're putting a sort of time limit every, you know, month or six weeks or something where you're saying it doesn't matter what you've done.

We need to be in a process to get it out the door and get it in front of people.

And you try as much as is possible.

This isn't always possible, but as much as it's possible say, right, we've got something that works, let's release it to our users, or some user base so that you can get some testing

Minute 5

so you can get some feedback on if the direction you're going is good or, uh, insane or has some, uh, you know, horrible flaw or something.

So you're just trying to constantly try and make these little steps forward.

Um, so that's broadly what I think of as agile.

Um, so yeah, that's what we're trying to do.

Yeah, I think, I think one of the key things as well is, is making sure that you don't get stuck with your original mindset too much.

So if you're, if you're doing a sort of traditional waterfall model, um, if you've got a product that has a sort of, I suppose a sort of defined scope, you can sort of sit down, have a big architectural meeting, design all the sort of subsections of the whole platform, um, and then go away, lock your developers in a room and, and, and just do it, um, over a, a number of months or, or however long it takes.

Minute 6

But what that does is it, it sort of removes you from the actual marketplace.

It removes you from your customers.

Um, and it might work initially in some products and some, some, uh, platforms, but for us, we find that there's always a customer request that's, that's coming in.

Um, and then we obviously can't do every customer request.

Some of them don't actually make sense.

Um, but getting that feedback and, and, you know, we might come up with a really great tool that we think is the bees needs, but actually only like 1% of customers are using it, and they might be a very important 1%.

Um, and, you know, we might be a very valid development, but then if there's another thing that we could develop that's used by 50% of our customers, then you know, that that reaches a, a, a sort of wider audience, as it were, and might become a, a more broadly useful feature.

So keeping that feedback loop with the customers, not getting too tied down with one big thing that takes you forever to do and, and making these incremental improvements and, and,

Minute 7

and listening to customers is probably a good reason to stick to that agile process as well.

So it sounds like it's quite a sort of collaborative process between yourselves and the customers as well then? I mean, to a degree.

Okay.

I, I, it's, oh, sorry.

I was gonna say no, no, carry on.

I would say we, we listen to our customers, but we don't pander to them.

Maybe, maybe that's one way of putting it.

So we try to, um, yeah, obviously our customer, our clients are the ones that are doing the job that we are trying to solve, you know, give them tools to do so.

Clearly their input is extremely valuable and critical.

Um, but as Colin sort of alluded to there, a lot of the time people come to us with a solution to something, they don't actually, uh, necessarily articulate the problem that well, they'll say, I need a button to do x

Minute 8

rather than saying, um, I have this problem where, you know, my customers are or are, you know, I'm, I'm trying to solve this problem.

They very rarely articulate it in that way.

They'll say, can you build me a button on this screen that does this thing? So you, you're listening to them and you're listening for signals from your clients, you know, when, especially when lots of them are saying similar things, you have to think, look, they've probably got a point, but, um, yeah, but you don't want to just pander to them as well.

Yeah, I mean, like two or three clients might come with different solutions, but ultimately they boil down to the same problem.

Mm-Hmm.

And our job is really to sort of unpick that, find out what the actual problem is, um, that might involve speaking to the clients in in more depth.

It might involve just sort of broadly sitting down and discussing it as a team.

And then we come up with a solution that we think works, um,

Minute 9

the best way for everyone.

And it might not be exactly how some customers had it in mind, but it does solve their problems.

And if they actually sit down and use it, they'd be like, oh yeah, that works.

That's great.

Um, so, so, yeah, exactly.

It's, it's not necessarily doing exactly what a customer wants.

Um, I think it, there's a lot of software out there that has so many tiny little nooks and crannies, um, of options and, and configuration and, and special tools, and it makes the, the user experience the UI of using that tool almost impossible.

And, you know, we can have the feature to do it, but customers won't find it themselves.

They won't know how to use it, you know, because it becomes this complex kind of mess of, of controls and buttons and widgets.

So we have to very think very carefully about keeping the balance between the functionality that they need and having the capabilities that they need versus the simplicity of use

Minute 10

and the discoverability as well.

So it's, it's, yeah, it's a big balancing act of, of, as Robin says, listening to the customers, but not necessarily doing exactly as they've requested.

So I'm, I'm intrigued then.

Has there ever been a, a time when a customer has sort of suggested they want something and then you find that actually that's, it's been helpful for, for other customers rather than you guys say, this is what we're gonna do if someone says to you, let's do this, and then you found that other people really find that sort of idea, uh, a real useful addition? I mean, yeah.

Yeah, I would say so that's, it happens, I would say quite often.

You know, I mean, it's rare that, you know, we work in a particular industry where the problems that the clients are having are, are relatively broad.

But again, as, as sort of mentioned previously, some clients have got a pretty fixed view of how they approach certain things.

Um, but certainly one of the features that we have that was sort of, um, very much sort of driven from,

Minute 11

from clients was, um, owner statements, um, where we know that, you know, we are a B2B company, we deal with other businesses, but, um, our clients are dealing with, with their customers and, and guests.

So one of the things that a lot of our clients have is, is a need to do monthly reporting for, for their customers on the, you know, the performance of the properties that they're managing for them, uh, how the, the bookings are stacking up, what's, you know, the occupancy rates, et cetera.

So one of the tools that we have in Bookster is a, um, owner statement.

So it's a monthly statement, uh, for owners that say for any given month, how many bookings they've had, what revenue they've taken, um, how much they're earning versus how much they're paying to the, to the agency to, to manage it for them, et cetera.

So our owner statements is, is a sort of platform that has been built from multiple customers input,

Minute 12

and again, different customers do it slightly differently.

We have to essentially sort of break it down to the, the sort of common denominator of features, um, and make sure we implement it in a fairly generic way, but, um, still providing enough flexibility to, to be a, a broad appeal to, to multiple different customers.

So I would say that's, that's probably one of the features that has had most client input, um, in terms of, of how it operates and the features that it's capable of, of, um, sort of, yeah, it it's individual features of that subsection of Bookster.

Yeah.

Yeah.

I think one thing as well that, uh, that's quite important is when you're speaking to clients about things, to remember that they have terminology that might be quite specific to them.

So they talk about things in a certain way, and it's quite tempting sometimes that terminology might end up in the software and it's quite, you're gonna make sure that you're spotting

Minute 13

that they use certain terms for things or phrases for things that aren't actually that easy to understand what it is.

They've just come up with it inside their own team or their own company.

Um, but yeah, so we do that In boots as well, So we do that as well.

Yeah, exactly.

All the time.

So yeah, we sort of reinforce that or we use, uh, acronyms and things, or we think, uh, you know, just common knowledge, you know, like what an OTA is, for example, which is online travel agency.

So we, or a channel is basically the same thing.

So like we, we talk about these things internally a lot, and then they end up on our website or in our software, and it is quite dangerous, really not dangerous, but like people don't understand what it is that we're talking about.

So it's, yeah.

Anyway, um, uh, but yeah, I suppose, I suppose, uh, yeah, We, we've, we've gotta be careful with adopting customer terminology into the product when actually we've

Minute 14

not really given it any thought.

It's, yeah, they've come up with their term, it sort of sounds okay, but actually if we were to go out in the wider industry, we'd find it's generally referred to as something else, and that that's not, not a good idea.

I think, Um, use I terminology and stuff.

Yeah, if you're starting a, um, so like we did really, we started Bookster because two or three of our clients, we had a broader software system that did other things, and we had two or three clients that were doing the same thing.

So, um, I think if you're happen to be listening to this podcast and you're starting your own software company because you've solved the same problem for two to three clients, and you're like, oh, there might be a product in this, that is one of the dangers that, um, that you assume that your clients are doing it in some industry standard e way or that they're doing it using terminology that's industry broad.

Um, and so yeah, just to be careful to sort of say, right,

Minute 15

actually, are they doing this in a way that is logical or reasonable, or how are the people are operating? And I think, as Colin says, with owner statements, it's kind of in a way that's one of the most difficult areas because it's sort of every company, not that they do it in a unique way, but there are lots and lots of different ways you could do that.

Um, and it, it's also hidden.

So what, it's an internal process, so we can't just approach prospective clients and say, oh, could you, you know, we're just researching how you do your owner statements anyway, so, yeah.

Um, So in terms of, you know, you, you've, you get this feedback and you get this development and you, you add on features, et cetera.

Um, I mean, are there been times when you've had to, um, sort of kill off features, for example?

Minute 16

And if so, what would they been? Yeah, Yeah, I mean we've, we've sort of developed Bookster over a number of years.

As Robin said, it was a, a sort of a previous platform before, um, we sort of focused on the short term holiday, lets, we did a bunch of other kind of industry sort of semi-related stuff.

But yeah, there's, there's been features in, in the platform that, that we've had, uh, that was used, uh, for some clients that, um, have since wound up their business.

And, you know, we've, we are sort of carrying that, that code still around.

Um, we don't need it, but whenever we're doing sort of larger refactors, we, we sort of still have to go in and make sure that that works.

So we want to get rid of that code that, that none of our customers are using.

We, we want to look at sort of features that we have that maybe one or two customers are using, but not necessarily effectively, or it's not really got broad appeal or, or whatever.

So yeah, we have, we have deprecated, um, older features.

Minute 17

We had a kind of brochure request system, for example, where you could upload PDF brochures, um, and customers had to fill in a form before that was released to them.

Um, that, that really only fits in a sort of advertising model, um, where you're really capturing your customer leads.

Whereas now we're very much pushing for the online booking model.

So those kind of features have been slowly sort of removed.

Uh, similarly, um, reviews, we've, we had a sort of quite extensive reviews platform.

We still use it to a degree, but, um, in terms of, um, sort of Google and search engine recognition of, of reviews, they tend to favor third party systems, sort of accredited systems.

Your your sort of fifo, uh, FIFO and, and other kind of platforms for reviews because it's, it's kind of taking it to sort of third party system that has a bit of oversight and it effect, it, it basically, it,

Minute 18

it helps stamp out something called astroturfing.

Um, so astroturfing is a terminology that essentially means you're faking grassroots support.

Um, so what it meant was that you could build a review platform yourself and fill it with five star reviews.

Um, and yeah, this sounds great, fantastic, but it doesn't mean anything 'cause anyone can put a five star review on your own website.

Um, so using these third party systems, which, you know, is, is meant to very least attempt to get real customer feedback and, and sort of validate that it's coming from a customer, um, rather Than, we had, um, we had a banner ads display system.

Yep.

Right.

Remember that? Yep.

That was, that was, that was great.

Yeah.

That was a great banner.

A system.

Yeah.

Again, long, long time ago we had this very complex method of targeting banner ads to different regions and, and so on and so forth.

Um, because that was actually quite a, a money maker at the time.

Yeah.

Uh, selling these specific, um, adverts.

Minute 19

But again, now we tend not to, most of our clients don't want adverts on their website detracting from the actual booking pipeline.

So again, sure.

That that went the way of, uh, of the bit bin.

So, Sorry, there's Quite a lot.

Yeah, quite a few.

I mean, I think, yeah, uh, we connected to various payment gateways that clients wanted us to, that we don't anymore.

There's, there's a, there's actually probably quite a lot stuff that we've ditched.

Um, Does that ever cause any, uh, sort of arguments within the business yourselves? You know, somebody wants to keep something going and other people don't, et cetera.

Sometimes, sometimes things are a bit slow.

We've, we've improved our, our UIs over the years.

Um, so we have, you know, we've got what we believe is quite a nice way of entering your pricing information and your extras and, and, and, you know, your availability information.

Um, but over the years,

Minute 20

some clients have preferred the older UIs, and so we sort of try and steer them onto the new ones.

But if it's a bigger client and they're like, Nope, we refuse, then you kind of have to keep it dribbling along for a little while.

So I think that that kind of thing can sometimes cause a bit of of traction.

And mostly it's just people being used to what it is.

You know, they've got a muscle memory for how they click and set things up, and it's understandable.

Um, so yeah, there's, there's sometimes a bit of tension when we finally give up and say, right now we're gonna have to do it now, sorry, and move them across.

But, but generally speaking, it's, it's a transitional hard, you know, hardship rather than a actual relationship hardship that that comes from it.

It does, there's an initial bit of pushback, and then there's a initial bit of grumping, and then eventually there's acceptance.

You know, it's the, the four stages of grief, um, scenario going on there.

Um, so yeah, sometimes that takes a lot longer to, to phase out than we would hope,

Minute 21

but it, it does happen over time, so, yeah.

Okay.

So in terms of, you know, Bookster being agile, I mean, can you sort of describe what you're doing on sort of a daily, weekly, you know, basis to, to keep yourselves agile for the clients? Yeah, so I mean, it's not, uh, two clients per se, but it's agile in terms of just generally what we're doing.

So, uh, we have weekly kind of little mini sprints.

Uh, so we do a little bit of planning every week where we decide what we're gonna do the next week.

And that's kind of slightly governed by, we do a six weekly, what we call an epic planning.

So we, that's where the whole team gets together and we decide, broadly speaking what kind of things we wanna do in the next six weeks, whereas the week we tend to split each other, speak, split ourselves down into more little departments, I suppose.

Um, and then, uh,

Minute 22

at least once a year we do have a kind of bigger, like, state of the union, right? What's going on? Where are we going, what are we doing? Uh, we have a kind of annual think about, you know, what kinds of things we really would quite like to do at this point.

Um, but certainly in terms of the annual side, it's not like a checklist of things that we are gonna do because that would be essentially waterfall pla, you know, like non-agile.

It's just more of a case of Right, what direction do we want to go? What, what kinds of features are we looking to build? What kinds of things, um, are, are possible? What things, you know, from a, sometimes from a maintenance perspective.

So some, I especially as we're you get, you know, uh, longer, uh, in the tooth basically as a company, um, a lot of the stuff that we need to do isn't necessarily building new stuff.

Minute 23

It's maintaining old stuff or making sure we're got security patches in place, and so we do have to factor a lot of that stuff in as well.

Um, but yeah, that's the broadly how we work.

Um, and we've actually got our own little internal tool for doing our weekly sprints.

And we have, uh, you know, we, we put them into little tickets and say, this is what we wanna do.

Um, we assign planning points to them, um, so that we, you know, essentially we try to get some idea of the amount of stuff we can put on the board in a week.

And if we see that the points are just getting ridiculously over what we sort of usually do, they can sort of say, look, we're just not gonna achieve that, so let's take some stuff off or let's just not be anything else on.

So yeah, that's kind of how we work on an ongoing basis.

Um, and it generally seems to work reasonably well.

Minute 24

Yeah, I mean we have, we have sort of daily standups as well, just little check-ins just to make sure everyone sort of doesn't have any particular questions about the direction isn't stuck on anything, um, that kind of thing.

But also just as a social thing, Mm-Hmm.

Um, you know, a lot of us are working remotely.

We're not like, it's rare that we're all in the office.

Um, you know, so the daily standup's just a little, little bit of water cooler chat, a little bit of checking in on work chat.

Um, it's quite relaxed.

Um, you know, it's, it's generally up to people to bring up issues that they've got rather than go through a checklist and, and ask if there's any issues on this topic or that topic.

Um, but yeah, the board is generally the, the, it's effectively a kind of Kanban board, um, that we, we sort of use as our kind of daily checklist to see if we're getting through the, the weekly sprint or not.

Um, But yeah.

Okay.

Great.

No, uh, interesting stuff.

Minute 25

Uh, one thing I will have to ask you about, you've mentioned it a couple of times and I'm pretty sure it's quite obvious, but you've mentioned waterfall, uh, development.

Is it as opposed to sort of agile? Yeah.

Yeah.

So this is Just Explain, yeah, so I mean, there's a couple of different, different development models.

Um, you know, these, these go back to the, the sort of uni days of, of being taught about them all.

But, um, but yeah, waterfalls a a more sort of traditional top down approach.

You, you are sort of reassessing at times, but um, it's, it's more of a, it's, it is probably more applicable when you have a concept, um, you know, you've got a product that you think, this is the product and here are all the parts that I need to make my product a success.

Um, and there might be a sort of breakdown to an MVP, you know, a sort of minimum viable product part of it where you're sort of getting rid of certain features and functionality just to bring something to market.

But Waterfall is, is more of that sort

Minute 26

of traditional top down approach, um, where you're, you're having a sort of a global view of your product, your, your, your, your platform that you're building and you, you're able to design all the sort of components of it.

Whereas Agile is, it's, you know, you, you can sort of, if you're starting from scratch, there'll probably be an element of, of that top down approach to get the, the sort of the minimum viable product out.

And then at that point you're probably switching over to more of an agile approach to saying like, get the feedback from that, that minimum viable product.

Find out the bits that are used, the bits that work, you know, it might be a, a UI thing, it might be, well, from our testing customers aren't really getting the hang of this particular bit of, of, of workflow, so we need to rethink about that workflow and change that.

It might, might be fundamentally doing the same thing, but you're just changing the approach to it.

And just, yeah, generally working off feedback and, and those, those features that you may be thought of initially that you've put to one side to get your,

Minute 27

your minimum viable product out there, maybe you'll revisit them, maybe you'll be like, yeah, the customers will want that, but, but by that point you might have customers that you're able to actually leverage for getting knowledge about whether that really is a useful feature that you've come up with.

Is that something they would use? You maybe can't ask them that directly because nine times outta 10 they'll be like, yeah, yep, I would use that definitely.

Um, whereas actually they wouldn't.

Um, so you do have to, to jump through a few hoops to actually get real insights.

But, um, but yeah, um, I would say that's, that's sort of the, the sort of more fundamental difference.

Um, because Bookster's a relatively mature product now.

Um, you know, it's rare that we would go into that sort of big top down design approach, um, unless it's a, a particularly large sort of subsystem that we're, we're sort of introducing.

Um, but yeah, so generally speaking it's, it's more, more reactive, more, more agile, more that, that kind of model that generally works for us better,

Minute 28

especially being a small team as well.

Great.

Okay.

No, thanks for that.

I think, uh, because of time.

So maybe one final question, um, which would be, uh, because you are this, this agile way of working, does that, uh, help you deal with, um, sort of technical debt, uh, and what is technical debt to you guys? And could you just explain a little bit about that? Yeah, so, so technical debt, because we've been going for a long time.

Um, the, the code that we have, the coding style changes, how you approach, uh, working with things, the libraries, uh, and software tools that you use might become outdated and there's maybe more modern kind of frameworks in place that, that might, might be, um, more beneficial to use.

So technical debt builds up over time.

It's a natural part of any sort of software product.

Um, I think yes, an agile process can help with technical debt, but again, the more

Minute 29

of it I would say is, is partly social.

It's partly making sure that customers, you know, do you have clients that are using bits of the system that are, that have not been touched and you know, they've maybe got a, an older ui, maybe we've got better designs for approaching certain problems, but this particular part doesn't adopt those principles.

You, you can kind of get a feel for the bits that customers aren't using as much and aren't needed as much, and then you can think about trying to transition away and, and essentially just delete that code, delete that feature.

You can approach it in stages.

So quite often what we do is if we have features that only a couple of customers are using, we'll hide them from new customers so that nobody can sign up for that particular tool.

No one can use that particular tool, but the customers that are using it still get to use it.

And that, that sort of, you know, helps to put it into a sort of state of deprecation.

Minute 30

Um, maybe those customers will work with them to find out how they're using it.

Maybe there's a better approach to that particular problem that they're, they're solving.

Do they really need to use it? Is it actually useful to them really? Um, and at which point we can move them off of it and then eventually just delete the code and, and, and move on.

Um, so, so yeah, there's that aspect, but there's also a general part of, of development is just keeping up with the, the, the, the platform code.

So we, we use generally a, a platform framework, PHP, uh, which is used by a lot of websites out there.

Um, it's, you know, it's a very mature product.

It releases new versions all the time.

Older versions are deprecated, certain new features are added to the, to the programming language, um, that people can utilize.

Um, certain features are deprecated in their programming language that, you know, if we use them, we would have to migrate our codes to, to use the more modern approach.

Minute 31

So that's another part of it is just ensuring that we're keeping up to date with the base platforms, making sure everything is secure because older versions, any bugs or security issues with them are, are not gonna be fixed 'cause they're, they're past their, their end of life.

So, you know, we have to constantly make sure that our, our code is on the latest versions and, um, is kept up to date.

Um, so that's, that's a big part of it.

That's just something that we have to schedule into our, our general development process.

So it's not, it's not all about boots to features.

It's not all about front end facing client led things.

Um, it's also about maintenance.

It's about keeping the underlying platform up to date and secure.

So that's just another part of the scheduling that we have to do in our agile process is making sure we allocate time and effort, uh, into to those areas as well.

Okay.

No, great.

Thank you for explaining that.

Um, I think, uh, yeah, looking at the time, we should probably wrap this episode up.

Minute 32

Uh, it's been, uh, very interesting.

Thank you both for your time.

Uh, thank you for everyone, uh, out there listening as well to the podcast and watching it on, on YouTube.

Uh, a quick reminder that we have our, uh, sister podcast, which is smashing, uh, your holiday rental goals, um, that is out there in the world as well.

Um, if you'd like to go and listen to that, please do.

And please leave a favorable review.

If you have any questions for this podcast or for that podcast, you can send them in to podcast@booksterhq.com.

Uh, that's podcast@booksterhq.com.

Uh, and if you'd like to leave a review for this podcast as well, that would be very gratefully received.

Um, thank you Robin, again for your time.

Thank you.

No problem.

And thank you, Colin, for joining us on today's episode.

You're very welcome.

And in that we shall wrap up and we shall say thank you very much to everyone listening,

Minute 33

and we'll see you all again very soon.

Bye-Bye bye.