How to Implement Agile at Your Inbound Marketing Agency with Chris Hodgson

Hey there. Welcome to episode 101 of Inbound Agency Journey. This is Andrew Dembsky. I'm so excited to have you here this week where I am chatting with Chris Hodgson from We Mean Lean. If you remember, a few episodes ago here on Inbound Agency Journey, we had Jeremy Knight on from Equinit and he talked about their transformation into an agile inbound agency. Well, Chris was the guy who helped them pull it off. And before Chris started working with Jeremy and Eric over at Equinit, he didn't know anything about inbound marketing agencies and, and how they operate. So it was a learning experience for him, wrapping his mind around the business. But when he did that, he really got excited because he knew that Agile could help them change the way they work and deliver better results to their clients at the end of the day. So in this episode, we go behind the scenes on how that transformation happened. It is a really cool view on things and I just, I'm really thankful to Jeremy and Eric and Chris for opening up and sharing this with the Inbound Agency Journey community here. Before we hop into that interview, the this episode is brought to you by Do Inbound. And to celebrate our 100th episode here on Inbound Agency Journey, we are in the middle of a massive agency training giveaway. We are giving away $10,000 worth of agency training courses. If you go to doinbound.com 100, just 100- you can enter for your chance to win one of four courses that we are giving away right there. All you need to do is rate and review the podcast here on whatever platform you choose to listen to the podcast on. Share that review there, fill out the form and be entered. Multiple people can enter from any agency, so send over those entries there. We can't wait to hear from you. And we're super excited to give away this training and really help change the way that agencies are operating, help you get to where you want to go. Enough of that, guys. Let's get to the show and my conversation with Chris. Here we go. Welcome to Inbound Agency Journey. This is the show where inbound agency.

Leaders share the strategies, shortcomings, and successes.

They'Ve experienced in their journey toward building their dream agency.

Now, here are your hosts, Andrew and Gray.

All right, Chris, welcome to Inbound Agency Journey. So excited to have you here to just kind of get your perspective on implementing Agile for inbound agencies. We had Jeremy on the podcast just a few months ago, so this is a really cool follow up on that. Before we get into kind of the details of that story. Would you mind just introducing yourself to the listeners, sharing a little bit of your history and what brought you to where you are today?

Sure. First of all, thank you for having me on. I hope it's useful and informative to your listeners. Okay, a quick background or history on me is I started into the digital world quite early on. I started a digital production agency back in 2006 and we built websites and mobile apps for advertising agencies and creative agencies and marketing agencies based in London. And we had, it was a sort of what's called an onshoring model. So we had. One of the business partners was Pakistani and we had an officer in Pakistan which had all our tech and developers in IT and then a front office of account managers, consultants, project managers and all the rest. In London I was the head of operations and so as part of that business I was responsible for implementing the Agile process, which I'll mention now because it's ultimately what we're talking about. We ran that company, it was me and three founders for about 10 years and in that time we moved from delivering campaign based projects to agencies through to adopting the agile processes and principles across the entire company to then building sort of products and user engaging digital tools for direct to consumers. So that finished around. It was actually a year and a half ago we restructured the company and I left along with a few others and have gone into the sort of digital consultancy side of things where I'm now focused on helping businesses and agencies deliver digital products more effectively. It essentially works off the premise that a lot of people spend a lot of time working on things that aren't going to deliver them any value when they finish with it. And if they were able to understand that and identify that earlier on in the process, they would either stop what they're doing or end up with a much, much better product at the end of it. And so therefore getting a better, more value for the money, time and effort that they are spending on their, on their projects. And I do that through an agency called we mean Lean. So that's where I am today. Do you want me to get on to Equinox or do you want to lead on the Agile stuff to lead on without yourself?

Well, I think it's a great transition here because folks who are familiar with the Agile concepts, they understand it in the realm of software development. Now the principles there, you've had first hand experience implementing that at Equinet through kind of the inbound agency scope of services. So let's kick that off there. First of all how did you guys start working together, you and the Equinit team? And then what were your first impressions? Looking at Inbound as someone who's, correct me if I'm wrong, but hadn't been exposed to Inbound before that.

Yeah, that's correct. So I knew Eric, Eric Swain, who's the COO of Equinit from the days of my software development company. We worked on a number of projects together so we went quite a long way back. He called me up because Equinit were looking at. Eric was very familiar with my experience and the fact that he'd been around when I was implementing Agile into my agency, which was in all honesty quite a tough and painful process because we completely self implemented. So I went away and taught myself Agile by sending myself on a few courses and then basically tried to implement it myself into the agency, which was ultimately successful but was a very hard and tough road and that was specifically for software development. But anyway, so Eric and the Equinit team were looking at implementing Agile into inbound marketing and because he knew that I had done this before, he called me up to ask if I'd be interested in helping them. Now you're quite right. I'm almost familiar with the act of inbound marketing and have worked with marketing agencies, but I really didn't know that much about how it was done or the details of the process of delivering inbound marketing. So I said, well, okay, I'll have a look and let's see if I can help you or what the deal is. So went in and had a chat with Eric and Jeremy, Jeremy being the CEO of Equinox and had a little bit of talk about how they work and what's going on and whether I could help. We decided that I probably could without getting into the detail of it, without me really getting into the detail of the inbound marketing. They were pretty adamant that it could deliver them value.

Okay.

And they, and they were also adamant that they really wanted help doing it. So I was of the opinion that I'm pretty sure it will deliver value, but I can't guarantee it. And they said, well, we're pretty confident it will. We've looked into it quite a bit, so we want to go for it and we want to make sure that we do it properly, so we'd really like you to help us do this. And so that was kind of how we started. So it was even really at the very start slightly blind in terms of exactly how it was going to work. Do you want me to go into how it did work.

Yeah, well, first of all, from a sales perspective, how great is the sales conversation where you can tell your prospects, I mean your friends, but you can tell your prospects, I'm not sure this is going to work. And they say, oh no, trust us, it'll work, let us hire you so we can go do this together.

You say that, you know, as a consultant I really only feel like you're as good as the quality of the work that you're delivering. So it's slightly nerve wracking at the same time because you're like, I have no idea what's going to come out of this. But having said that, I am a massive agile advocate and so I am confident that it can work in almost, I'm not going to say any scenario but certainly most team working, you know, agency environments, Agile, if you're not doing it, will provide some sort of value. So I was confident but nervous. Awesome. So it was, yeah, go on, walk.

Us through the discovery here. When as you were getting acquainted with how they do business and the structure of inbound contracts, how they deliver their services, what was like the light bulb moment for you where you said, yeah, this is really going to work for these guys and, and here's how we could begin to implement in an organization like this.

Yeah, yeah. Well, so the first thing that I did was I went into Equinit and spent three days just completely engulfed in what they do. So I had to go from zero knowledge to understanding all the different processes and how everybody in the team works and what roles they have and jobs and how they, and just as important how they manage their calendars and the workloads and what they're doing. And it was kind of during that process, I don't know at what point it was, but it was certainly during those three days that it was evident that it could help. I think the primary things that jumped out at me that were clearly a huge value add in terms of how Agile could help that you know, the inbound marketing activities is that the team, as far as I could see the team that's delivering do inbound there everyone has a particular role that they're doing. There's a few, you know, cross functional people. But you know, we had a, they have a content writer, so copywriters who are writing a lot of the content, they have people who are making the videos, they have developers who are building the website and all this digital assets, they have designers who are creating the visuals and then they have people running the social campaigns as well. As the re engagement campaigns and all this sort of stuff. The way that they were managing their workload was on a task based basis. So they have a certain amount of work that they need to do in order to deliver the contracts that they were providing their clients. And the contracts they were providing their clients were also based on tasks. But what was clearly what the clients wanted and the inbound marketing equinit to deliver them was performance. Right. So the quality of work that the inbound marketing agency or equinent would deliver was down to how much traffic they delivered to their client, how many contacts they were going to get them and how many what they call marketing qualified leads they were going to get them. But everything that the team was doing was about activities and there was a complete disconnect in terms of how the agency is judged from a client perspective and how they are working from a day to day perspective. That was a clear, clear advantage. So with Agile it's all about one of the core concepts or principles is having aligned goals. So everyone working towards the same goal and making sure that that goal is the right goal is a really critical part of that. And so that was going to be a clear advantage in order to implement the team. And the other one was bringing all these different skills into one cohesive team. So everyone was delivering their own work and of course they were communicating. It's not a massive company. And so they're all between two or three different rooms. So they're having social conversations and having chat and they all get to know each other very well. But there wasn't very much coherent communication in terms of how their work affects the other people in the team.

Okay.

And that given that the performance that they're going to deliver to their clients is really completely interlinked in terms of how they all work together. That was the other part for me that really stood out as a value add that Agile, the Agile is going to close that loop. Because another principle of Agile is about cohesive teams having a team that has all the skill sets. So with software development, while it's applied to software development, when you try and form an Agile team, you don't try and segment it, you don't say, right, well we just want front end developers here, we just want back end developers. You try and have input from all the skill sets necessary to deliver your end product. And so in inbound marketing our end product, you know, if I take it back to the aligned goal is performance. So of your inbound marketing, so you need in your team all the different skills in order to deliver, you know, a high performance inbound marketing campaign. And so they had, we wanted to bring them all together. So those were I think, the two things that really jumped out at me in terms of how they were working. So they, to summarize, they were working this siloed way where everyone had their own task list. They all managed their own tasks in their own ways. They were working according to tasks and activities as opposed to performance. And they weren't all working together and measuring themselves on ultimately the right goals that their clients were going to measure them on.

Okay, now it sounds almost overwhelming to think about that situation and then to say, okay, how do we write this ship and change the direction of how this whole team works and functions together without, you know, dropping a client off or missing a key deliverable in a campaign? So once you identify this gap there, what was your first step in kind of beginning the process of instituting change without disrupting delivery?

Yeah, yeah. And that, that is pro. That was probably my, my biggest concern as I was going into it because, you know, an agile way of working is an all encompassing it, you know, it's company wide. You can't just do it in one part and not another. You have to do the whole thing. And so it can't be taken lightly. And also while when you get there in the end it's far, far better than what it was before. It's very easy. And this is a mistake that, you know, I had personally made with my agency. We actually lost a few clients because of some, you know, taking steps, taking too big of a step too soon and dropping the ball with clients. So, which is a mistake you can make when it's your own agency, but not when you can make when it's someone else's, you know, so the way that we had structured the. I think I lost you there a second. Hang on.

No problem. I can still hear you.

You still there, Andrew?

Yes, I'm still here.

Sorry you dropped out a second. The way that we had structured the program was we planned to do it over three months. So it was a three month transformation which was aggressive in hindsight. However did give us plenty of time to get all the elements in there. So what I did is I went away having spent my three days immersed in Equinit and I put together a sort of 12 week program where every week, so I was due to go in there once a week for essentially a whole day. I took all the different elements of agile and I broke them down and I created this priority list of how I was going to introduce it into the company. Every week I would go in and introduce one concept and with that concept there would be a few activities to be done, a few new activities for the company to take on board. And then the next week I would go in and we talk about how the last one went and were there any problems, were there any challenges before we then decided to move on or I decided to move on to introduce the next one and with that decide how that was going to affect, what activities that was going to affect and what it wasn't going to affect. And by doing this very carefully. So in a way, the program itself was agile because we were delivering it week by week. So the concept of sprints is one that agile revolves around. For those that aren't aware, it's a time boxed period, the cycle that you go around. So I was essentially delivering a sprint of agile work each week. And we would review how the last week had gone, we talk about it before deciding whether we were in a position to move on to the next concept or not. And if we weren't in a position to move on to the next concept, we wouldn't. We would discuss what went wrong with the previous one, how it might be affecting the clients and how we might correct it, and then we would run another week where they would stay on that concept or those tasks before I came in the next week and then introduce another one. That gave me the ability to keep a very close eye on how the different concepts affected the way that they were working. And also to. I'm working with both the team and Jeremy and Eric for the management team to understand how it's affecting their client relationships and whether any clients are being potentially poorly treated or having some problems or left by the wayside. In this way. We kept a very, very close eye on it to ensure that that didn't happen. But essentially it was this prioritized approach to not doing the whole thing at once, but just picking and choosing what concepts were going to be most easily absorbed by the team at each step and only moving to the next concept when we felt like the team was comfortable with the one that they had been given before the week before.

Okay, so you're layering on over time, little by little, kind of moving towards and then adjusting as you need to as you go.

Yeah, exactly, exactly.

So I have so many follow up questions here, Chris. I don't really know where to start, but let's start with kind of the tools that drive everything. How did the process of implementing a tool to manage the new Agile flow, go for the team. Is that something that you implemented slowly over time or was that kind of a.

To be honest, it was. It was the very, very first thing that we did. So there was an element to the process that was an unknown, as in I knew what the principles were and I knew what we needed to maintain when we were delivering it, but I didn't know exactly how that was going to end up looking by the time that we were finished with the process. And so there's a tool that I use that I absolutely love and I pretty much use for everything, which is called Trello. It's a free tool that essentially, it's essentially it was built for Agile, but it's a to do list or a management board for Agile sprints. And you can pretty much do anything, anything with it. It's incredibly flexible and it's very easy to run and everyone can have it on their computers. And so it's a very, very, very simple. It's as malleable as you want it to be and you can use it for any purpose. So actually the very first thing I did was introduce Trello and say, this is now where we manage all our tasks. I can actually tell you that the first step that we did was to say, okay, from now on we are going to put down what we're working on into a shared location so that everyone else can see what everyone's working on.

Awesome.

Because this is something that they were already doing. Sorry, they were already discussing what they were working on, as any good team would, you know, so they'd sit down, I think they do it every Monday and talk about, okay, what are we doing this week? You know, what's the, what copy are we, what content are we creating, what re engagement campaigns are we doing, what web development are we doing? And you know, the team would discuss it, but it was just in a discussion. It wasn't really logged or held anywhere. So I was like, right, I want to get this all down so we can actually see what it is. Because things change during the week and you also forget what people say, but it's still important. So I said, right, we've got to have everything down in one place so that we can all see it. I then introduced Trello and said, right, this is a tool that I think we should use in order to manage that.

Okay.

Interestingly, they still use Trello and to great effect. And it's now grown and evolved and developed into much bigger than just the board. They use it for a lot of other parts of the business, all kind of feeding into the Agile process.

Okay, awesome. So did you have them set up a new board for every client and manage it that way?

No. So the way that you want to run your. Well, to be honest with you, I wasn't sure how that was going to end up being. However, I knew the ideal. And the ideal is that you have a board per team as opposed to per client. Now, what I didn't know is if the reality of inbound marketing was going to allow that to happen. As it turned out, it did. And so they have one board per team that they have now, Equinox, small enough to have one quite large team. So they have one Sprint board and it has all their clients on it.

Okay.

Now the reason why you do that is because the board allow is a lot of the value of the board is planning and not overloading a team. So understanding how much your team can deliver in each sprint or in each week. And if you have a separate board for every single client, but all clients are delivered by the same team, it becomes incredibly confusing to know whether you are overloading your team or not, which is inevitably what happens. You know, you tend to. There's very few agencies that underload their teams, and overloading your team has a lot of consequences to it. Not only does it hit morale because your team's never delivering what they're being told they need to deliver, but two, it's incredibly difficult to then communicate to your clients about what you're going to be giving them because you're always missing something because you're overloading your team, or even worse, you are delivering poor work to get it out the door, and that then affects your performance, which obviously ultimately affects your relationship with your client as well. So the ability to know exactly. I say exactly, the ability to have a very good idea about what you are going to be able to deliver each week or do each week is very valuable. And so it's important to have all that in one place as opposed to in lots of different places.

Gotcha. Okay. I love that perspective. I think that makes a lot of sense from, I guess, taking a step back, the Agile model for inbound agencies. How do you. How do, like, documented processes or tasks that are recurring on a regular basis. How. How did those fit into a structure? Because that's a big part of what agencies do, or inbound agencies do. How did you guys work through that process?

So what we did again before we started, I didn't know. I didn't know how. It's going to pan out. But what we ended up creating was what we called a backbone of work. The backbone of work became the things that you had promised the clients. I know that Equinit wants to move on to performance based pricing and contracting so that they can, you know, work with clients according to the quality of, you know, the value that they're delivering them in terms of traffic, leads, contacts. But they're still working, you know, for all the time that we've been, that I've been working with them, we're still very much on client contracts that are, that are based on activities still, which I imagine, you know, most inbound marketing agencies have to do that because that's probably what clients want. Right. So what we did is we created a backbone of work and the backbone would be what you had promised your client and then that would be the recurring tasks. So let's say it's a blog post a week, a video a month or a quarter, an ebook a quarter or every six weeks, whatever it was, that would form the backbone of work. And then our sprints, which is our, you know, our time box periods of work, at which point we would, we would review, they get fed into the sprints as known quantities at when they are due to be done.

Okay.

And then we can play around with the other activities around them. So you have this sort of core, as I said, the backbone. And then what you do is you feed in the other activities that you can do that the team can do in order to affect performance around that backbone of work. So with one blog post, there's still a lot of other work that needs to be done. But the backbone is that the client's expecting a blog post this week or two weeks or whatever it is. So that needs to be done. So that goes into the sprint. And then what else can we do around that? You know, can we do some keyword research? Can we do some, you know, CRO analytics? Can we do, you know, optimization? And those are the tasks that aren't necessarily visible to the client, but will absolutely enhance the work that you're doing. And we try and, you know, discuss how we feed those in and what we can do, you know, and that becomes your sort of flexible or, you know, your agile element.

Okay, gotcha. So it's almost like kind of Stephen Covey's big rock, small rocks theory where you've got your vessel that's, you know, the size of your jar would be the size of the contract or how many hours you can put in each month for your contract. You put in your backbone pieces first as your big rocks, like these things need to be done. And then it's like, what are the smaller rocks that we can fit in around here with the remaining margin that we have to deliver value, like leveraging what we've already created and just giving more to the client, but doing it within that time box?

That's exactly it. Beautiful. Because also the reality is that the backbone is. You need to know where the backbone is. But the beauty of the Agile process is that. Or, sorry, the reality of life is that you might not be able to deliver what the backbone says you are. And what you don't want is for that to then break your system or break your process. And so with this Agile process, you can see where the back but what's happening to the backbone as it's happening. But it's not like, oh, we missed that, the whole thing's broken. It's okay, so it's a week late, but we can deal with that because the process allows for that flexibility and it allows you then communicate with that with the client as well in advance of it happening. So you can be much more proactive about how you're delivering to your client as opposed to reactive.

Okay, how did you guys decide on a sprint length?

Well, we, well, obviously we're talking about it regularly, but we kind of let it decide itself. So a week sprint was the natural time to have a sprint at the very start, because I was in there every week and so it kind of happened just by me being there each week. So that was really the second concept that I introduced, was this concept of working in sprints. And the way you frame a sprint is by having, for those that aren't familiar with it, is you have a planning and a review point and the sprint starts and finishes according to time, not according to activity. So you don't say, right, when we are finished with this work, then the sprint finishes. It goes. The sprint starts, if it's a week and it starts on a Tuesday, it always starts on a Tuesday and it always finishes on a Monday, no matter what. And it just keeps on cycling around like that. So the fact that I was there every Monday naturally created this sprint cycle.

Gotcha.

Okay, so, so we started with, with Monday to Monday sprints, just one week. And I was, and I was introducing this, this meeting that we have, which is the sprint review and planning. So you kind of, you do it at the same time, you review how it went the week before and you plan how it's going for the next Week. What was happening to us is because this was a new meeting and we were covering discussions and topics and ground that the team hadn't done before. The meeting was becoming way longer than it was supposed to. I mean, we were having three hour meetings or I think one of them went to three and a half hours. It was crazy. But one of the things that I was doing is I was making sure that we did the meeting properly. So that was one of the. I was kind of being this, you know, the agile ambassador. I wouldn't let them have a shorter substandard meeting. I would force the, force it through. So the pain was in the, was in these long meetings, but at least I knew that we were doing it properly and we're having the correct meeting anyway. The side effect of it being a three and a half hour meeting is that it takes up the entire team's time for three and a half hours. And there was a real concern, especially from Jeremy and Eric, from the management team, that we were losing quite a lot of our working week for these meetings. Yeah. So what we said was, okay, why don't we go to two week sprints so that we have the number of meetings sprint meetings we have for each sprint. Let's see if that affects our productivity. So that's what we did. So about six weeks in, we changed to two week sprints. And I would still come every week, but in the interim, one, we wouldn't have sprint meetings. We'd have. I'd do other things with the team. And so we ran that for a while and then there came a point about actually three months later. So we've been running two week sprints for quite a while now where Eric. So this is actually past. So I still see Equinox, but I only see them once a month. So this is past the time that I've been going every week. Okay, I'm going once a month now. And I was chatting to, we're running through things and they were saying, do you know what? We think that we're going to go back to one week sprints. And that was because they were now so slick with their meetings that they brought them down to an hour maximum, sometimes 45 minutes. So they solved that problem. And the ability to talk about what they were working on more regularly gave them more control of what the team was working on and more flexibility and ultimately gave them more power over the work that they were doing.

Okay.

And so we went back to one week sprints, which is what they're. We're currently on which is now working really well.

Gotcha. So it's like it's putting in the work early, going through the dredging, through those longer meetings where there's more work to be done and they're still learning the process, but doing that knowing that there's light at the end of the tunnel, so to speak, because you're learning the, you're internalizing the process and the, the agenda flow for how you make through things.

So that would be, my perspective, wasn't necessarily theirs. I would say that that probably was one of the more difficult times of the, of the, of the process, of the transformation was my insistence upon these meetings because they couldn't at that point, don't forget they're learning something new. So they don't necessarily understand why we have to, you know, have these meetings in this way, why we have to sort of point stories at that time. Can't we do it after? Can't. Why do we have to do as a team all this kind of stuff? And I was insistent upon it, so there's a bit of back and forth, but obviously I had to be insistent upon maintaining this approach. So hence we went to the two weeks and then once they became better and better and better at it, they then made the choice to go to the one week. So I was saying in my head, I was like, this is great because they are definitely learning the fundamentals of Agile and the principles and as we continue to do this, they'll become more and more familiar with it from their side. It was, my God, these meetings are taking forever. Why are we doing this?

And you're just sitting there saying wax on, wax off?

Basically. Basically, yeah, exactly. Love it.

Okay, so I guess a big part of the process here is like setting, setting the stories that fill your sprints and pointing those. Can you talk about how, what was the typical line between a story and an inbound deliverable and how did you guys organize those?

Well, we made, we treated them in the same way. So our backbone of work was all structured as stories. So if we have an ebook that is due for a client that is, you know, that's not one story that is made up of. I don't, I can't remember how many stories make up a single ebook, but let's say six or seven. Right. You know, you have research, you have writing the first draft. You know, one of the things about Agile is you don't want stories that are too big in a single sprint. So for people that don't understand what a story is, it's Essentially a task that the team needs to deliver. When we talk about big and small stories, what we do is we attribute points to the stories and the points are a measure of how much effort it will take to complete that story. And if we have points to all our stories, we're then able to see we end up getting a team velocity. And the team velocity is how many points does this team deliver in each sprint. So it's simple when you think about it. There's a certain level of normal efforts that a team can deliver in a week. How do you quantify that? And by applying points to stories, you're able to get a quantification of that. Now, this is not an exact science. You have to understand that these are estimates, but it's a hell of a lot better having those estimates than it is not having anything at all.

Oh, definitely.

So to go back to your question about the size or sorry, to make a point about the size of stories, again, knowing that agile. One of the things about these agile sprints is about planning and being able to know what's, you know what you're going to deliver or not. You don't want a story that's too big in your sprint, so it doesn't have too many points on it. Because the bigger a task or activity is, the less sure you are that you're going to be able to complete it. The more, the more risk there is that something will happen that stops you from completing it. And the less you know about what's going on or the less you can be sure about what's going to happen, the less control you have and the negative cycle starts. So you want to try and break down your stories into manageable sized stories. Hence when I say, so you have an ebook, it might be made up of six different stories that if you do all six of those stories, you end up with an ebook that has been published and released. And so the backbone of work is everything's a story. Everything that we're working on ends up being what we call. I say story is the agile term for these pieces of work. Whether it applies, story doesn't really apply to the way that we did it for Equin and inbound marketing. It refers to the wording that you use for a development story. But we don't actually write stories. We don't say for anyone who's familiar with agile, you go, as a user, I want to do whatever, so I can. That is the structure of a development agile story. We don't follow that. So they're not Technically stories, but we still refer to them as stories. That's just to clarify it for anyone who's getting confused. So everything ends up being one of these, I'll call them story cards. Being in a story card, whether it's backbone activity or not, the benefits of having backbone activity is that you can apply points to your backbone activities and those can apply to all every time that activity is being done, which is an advantage for inbound marketing versus the development world, where everything you're doing is essentially new. So you have to point every single story every time you create it and write it and put it into your workflow. Whereas in inbound marketing, you actually have a whole host of stories that are already pointed. So that helped us reduce the meeting times once we had that in place.

I see.

To answer your question, everything still remains a story. So you have your backbone activity, which are all managed as bite sized stories, manageable stories that we can deliver in sprints. And then we have our, we don't have a term for, let's call it our ad hoc stuff or the other stuff that fits in around it, the small pebbles. And those, some of those will have points attributed to them as well because they might not be backbone tasks, but they're certainly repeatable tasks. They're stuff that you do regularly as part of an inbound marketing strategy, but you just don't know when or where things. So you have all those tasks that are repeatable tasks but aren't necessarily repeatable according to a schedule. And then finally you have other tasks which are the ones that are probably your ad hoc tasks, the ones that are unique and haven't been done before or are different depending on each client. Those are the only ones you end up pointing as you are going through the process.

Okay, so a story with the inbound marketing application, is there, is it like one owner? Is it equated directly to a task? Or could there be multiple tasks, different people completing different things inside of one story?

So a story is owned by one person, but a story is not written for one person. So you don't create your stories according to people or individuals. You create it according to the ultimate, ultimate task that you are delivering. And the reason. So there are lots. In fact, most of the stories that we have in our board will require inputs from multiple people. The only ones that don't really, as far as I can think, are probably the web development ones. But even then you probably have a bit of input from, you know, we have input from the designer. Pretty much every story requires multiple people. To input into it. Now you have one person to own it so that there's some level of accountability.

Okay. So they're responsible for bringing everything together and getting it ready for meetup.

Correct. And they might, depending on, in some circumstances, you can have one person own the card at the start of the sprints and then someone else owning it by the end of the sprints. Because the two tasks could be one follows the other. So then the first person does the task that they need to do to get that card through and then they assign it to the next person who then takes it on to finish it off. So you can have that sometimes as well.

Okay, so it's like passing the baton, essentially.

Well, yeah. In those circumstances, the whole reason why you only have one person on it is because. And this was learned, this is actually learned by trial and error. When you have multiple people on it, it's harder to know who's supposed to be. So there's just, it's just a natural human reaction to go, oh, well, if Bob and Anna are on it, both on at the same time, Anna's going, oh, well, I think Bob's going to do the first thing there. And Bob's going, oh, I think Anna's going to do the first thing there and no one ends up doing anything. But if it's discussed, I go, right, Bob, you own this. And so he does his first task or he goes, okay, what this means, I will schedule the meeting that both me and Anna have to have in order to solve this. That's my responsibility. But it's completely a joint effort. Card could be something like that.

Awesome. Okay, so we've covered so much ground here, but wrapping up, if there's anyone who's listening here, an agency who wants to give Agile a try after going through this process with Equinox, what would be some advice that you would share with them before they hop in?

I would probably. Well, don't undertake it lightly. It's a massive thing to do and it's all encompassing. So while you can try and, you know, you can implement it across small teams and to test it out, I would say it's a big task, so don't undertake it lightly.