Back again. This time, Paul Scott, advisor and director at Digital Village, General Manager at Evergreen Digital returns to talk about a subject he is passionate about and that is Agile. Paul co-authored with Andrew Walker, the book Beyond Agile – How to run smarter, faster and less wasteful projects which provides a history of Agile for software development and spells out the Agile principles they have successfully been applied to hundreds of projects and organisations. Paul shares his observations and thoughts on the application of Agile in marketing, declaring that it is not for everyone, all the time.
You can listen to the podcast here:
Follow Managing Marketing on Soundcloud, Podbean, Google Podcasts, TuneIn, Stitcher, Spotify, Apple Podcast and Amazon Podcasts.
Transcription:
Darren:
Welcome to Managing Marketing, a weekly podcast, where we discuss the issues and opportunities facing marketing, media, and advertising with industry thought leaders and practitioners.
Today, I’m sitting down again, with Paul Scott, Advisor and Director at Digital Village, General Manager at Evergreen Digital, and co-author of the Beyond Agile: How to Run Faster, Smarter and Less Wasteful Projects. Welcome back, Paul
Paul:
Darren, great to see you again. Thank you for inviting me back.
Darren:
Now, I wanted … because last time, we were talking about call centres and the opportunity that provided for marketers to really understand how their customers were feeling and thinking about brands.
But this time, I’d really love to focus on this amazing book. And you co-authored this with Andrew Walker, Beyond Agile. And I love the concept of Beyond Agile because I feel sometimes that a lot of organisations are stuck in agile rather than going beyond agile.
Paul:
So true.
Darren:
Tell me a little bit about how you got to write this book.
Paul:
Yes, well, it goes back to when I started working with Andrew in 2016 in a software development business called Three Weeks. And Three Weeks was a very unusual software developer of its time in that it adhered to the principles and the values of agile but did not use any of the rituals and the methods that have sprung up around agile in the last 20 odd years.
What I mean by that is we didn’t have Scrums. We didn’t have Scrum Masters. We didn’t do stand-ups; we didn’t do retrospectives. But the business adhered to the philosophy that is basically inherent in agile, and I’m sure we’ll come onto it later.
Darren:
Sorry, Paul, but if you don’t have Scrums and Scrum Masters and stand-ups and retrospectives, can it possibly be agile? Because every organisation that we’ve dealt with that has embraced agile, all point to Spotify and the-
Paul:
Of course, they do.
Darren:
And that this is what agile is. It’s about all those rituals. It’s about the language, it’s about the process, isn’t it?
Paul:
And look, I’m not saying that you can’t adhere to the values and the principles of agile by doing those things. What I am saying though, is too often, they get in the way of the original principles and people forget what it was originally about, which was about producing working software, focusing on interactions rather than processes, dealing in customer collaboration rather than contract negotiation, and responding to change rather than having a set plan.
And what happened when people started developing these frameworks and methods around agile, was it began to dilute a lot of those original values and it caused people to stop behaving in an agile way, not delivering the outcomes that were intended by creating those agile values and principles.
The whole philosophy was set up in 2001 by a bunch of guys who got together in Utah at a retreat. And the reason why they were together was because they were becoming really frustrated at how slow and ineffective project management techniques and development techniques were in the software industry.
95% of projects don’t deliver on the original objectives, and either overrun on time or on budget. And the reason why that happens is the same reason every time; because they’re not engaging with customers, they’re trying to scope out the whole project end to end from right at the outset and working to a very rigid plan. And they weren’t delivering outcomes that customers needed and wanted.
By the time they got to the end of the project, the customer’s needs had changed and they hadn’t worked out how to adapt on the go. So, what these guys did was to basically sit down and work out what are the things that are going to prevent us from achieving a successful outcome for customers and users, and let’s focus on just addressing those things.
And they came up with these four core values and 12 principles that sit around them. And if you read it and think about how that can be executed, you don’t need Scrum. You don’t need any of these rituals to achieve success. What you need is to maintain integrity to those original values and principles. And if you can do that, you will produce great outcomes.
And that’s what we did in Three Weeks. We did over 260 projects in the space of four years, and every single project exhibited the same characteristics. We delivered it in half the time that the customer expected, probably about a third of the budget that they expected, and always produced a successful outcome. And we did it just by rigorously adhering to those philosophical principles.
Darren:
And it’s interesting because everyone knows that agile has its foundation in software development, but it’s interesting the number of areas that it’s been sort of expanded into, including marketing.
Paul:
Everywhere.
Darren:
But you wonder sometimes because a lot of processes are still quite linear and quite Waterfall, and then to try and put an agile process on that could be counter-intuitive or even counterproductive, couldn’t it?
Paul:
And there are still plenty of examples where those agile principles don’t really work that well. I mean, people try to adhere to agile principles and there’s something called the scaled agile framework or SAFe framework, and the objective behind SAFe was to create scalable agile.
And again, my observation would be having seen how people have tried to apply that framework, it doesn’t work. Very rarely does it deliver what people expect at the end of a project. But it’s not to say that it can’t be done.
Nowadays, in our industry, people talk about continuous development and continuous integration, which is really a scaled version of agile. It is adhering to many of the principles of agile that were set out in 2001, but it’s bringing it more up to date with the needs of large enterprises and recognising that there are aspects of it that just don’t work when you’re having to deal with a multifaceted, multi-departmental organisation that’s got a lot of different stakeholders who may be using the same product for doing different things.
So, there are ways of bending the rules, but it comes back to those four principles. If you can work to those, you can produce meaningful outcomes for customers.
Darren:
I’m even aware of some major organisations which have said that they’ve embraced agile at every aspect of their operation. And I quite sort of cheekily wonder how their finance department’s going if they’re operating agile. Do they have a stand-up every morning where they look at all the invoices that need paying for the day?
Paul:
I mean, I’m not sure how it works in every single department in an organisation, Darren. But again, it comes back to how people interpret things.
It’s fascinating for me, when we were writing the book, we were looking at different methods that had developed over the last 40 odd years. And its interesting how Waterfall was actually sustained really as a primary method of software development for the last 40 or 50 years. I mean, it really hasn’t changed dramatically, and it is still a valid method of doing large scale product and software development.
But even in Waterfall, I’ve seen organisations adopt a lot of the agile principles of getting close to customers, try to focus on interactions, being more responsive to change, even though they’ve got to have a detailed project plan to work to. So, I think you can sort of pick and choose bits of agile to make it work in different environments, but just don’t call it agile, call it something else.
Darren:
I think it becomes particularly difficult when you’ve got two organisations such as an agency and a marketing department, is my observation, where on one side, it’s very much Waterfall with stage and gate approval as they move forward.
And on the other side, you’ve got an organisation trying to work in an agile way, and it’s a complete misalignment across the two, because one is driving this sort of, they interpret agile in its most literal sense of being flexible and adjusting to change. Whereas the other one is very much a traditional linear project management, Waterfall, or in stage and gate.
Paul:
That’s right. And one of the observations we made when we were putting the book together, was looking at organisations who’d been trying to use agile and failing. And there was a common factor in that although they were creating teams of people to work in an agile way, the teams were too big.
And I suspect this might happen in the marketing domain as well, is that agile only works when you have a small core team of people who are multi-disciplined and can work on the core purpose of the project.
And I’ll give you an example; in the book we talk about Alpine mountaineering. So, mountaineering was renowned for its need to have large support teams to get mountaineers to the summit of Mt. Everest or wherever.
Until I think it was around about 2000, it was probably around 2004 — a very brave chap questioned the need for there to be a large team of support people to get somebody to the summit of a large mountain like Everest.
And said, “Why don’t we actually train a small group of people to be able to do a number of different things that will enable us to move faster and to reach the summit without compromising our own lives,” and succeeded in doing so.
So, I think he proved that there was a way of approaching a traditional problem in a different way and working with a smaller team to achieve the same outcome.
Now, we applied exactly that principle. When we were doing software development, we used this thing called the fractal model, which basically says the shortest lines of communication are between three people.
If you can work in a team of three people to deliver an outcome, you will work faster than a team that involves 5, 7, 9, 10, 11 people because you’ve got the complexity of the communication in that larger team.
So, when you apply this now to marketing, you’ve got to think, okay, so if I’m going to put together an agile marketing team, what are the core disciplines that I need to have in that team? What’s the minimum number of people that you can pull together to create an outcome in a marketing sense?
When I was doing the research for this discussion, I came across that website that talks about agile marketing, and they describe a team of 10 people as being the minimum size of the team. That’s simply too many to be able to move in an agile way. That’s why you need to have a morning stand-up.
And by the way, the morning stand-up’s going to go on for about 40 minutes, because you’ve got 10 people, all of whom have got to give an update, and it just slows down the process. And if you can’t work with a smaller team, you won’t be able to work in an agile way, it’ll just slow everybody else down.
Darren:
It’s a really good point, Paul, because one of the things that we constantly get fed back to us, especially where marketers are engaging their external agencies in an agile process, is that they spend a lot more time in meetings; stand-ups, they’re often called, because it’s the only way of being able to communicate with all of the stakeholders.
You know, when you think about just getting an advertising campaign, a TV campaign to where you’ve got a media agency, you’ve got the creative agency, you’ve got the production company — already you’ve got three groups of people working with the marketers, and there’s probably two or three from each of those that would feel the need to participate in that conversation. So, your team’s just blown out of the water.
Paul:
And I don’t have the answer to this, but if you do want to think about how you can create an agile marketing team, that as a first principle, you’ve got to try and keep the team number down to three. If you can keep the team number down to three and say, okay, well, we recognise we’re not going to have all the skills to do everything in this team of three.
But then have each of those individuals be able to have interactions with other people who bring those other disciplines, then you do stand a chance and are beginning to act in an agile way, and to have your team perform in a way which adheres to those original principles.
Darren:
And that’s absolutely achievable, but it means that people need to give up their sense of control or that everyone has to participate to know exactly what’s going on.
Paul:
Indeed. And again, to give you an example in our world, in the software world, we had multiple problems with customers. When we first talked to them about working in this team of three, we’d say, look, we’re going to have a team of three people. We’ve got a wrangler who is basically a product manager, and a project manager, a tester, and a specialist in our method.
And then we’ve got two full stack developers. So, full stack developers can develop basically end to end solutions, the front-end fancy bit, and the backend processing piece. And our wrangler would interface to our customer’s single point of contact, who we would call the one.
So, the one is basically the person who’s been delegated by the customer to act on their behalf, to make every decision that’s needed. So, they’re given authority to act on behalf of the business, to help us with prioritising what features and functions we’re going to develop, which customers are going to go talk to, etc, etc. They become that single point of contact.
And if our customer couldn’t point to that one person, they’d say, “Oh, no, no, you’re going to need to talk to IT, you’re going to need to talk to compliance. You’re gonna need to talk to our finance team.” We’d say we can’t do that. We can’t operate that way. If you can’t give us a single point of contact, our model doesn’t work, you might as well just go to any other software developer and work with them.
Darren:
Yeah, because I mean that one, the one, can still go back into the business and get feedback.
Paul:
Of course, they can.
Darren:
It’s not like they’re taking the whole responsibility, but what you’re saying is it’s the coordination and the time that it costs-
Paul:
Correct.
Darren:
For you to then navigate your way around the organisation, just to get what “the one” should be able to deliver.
Paul:
Precisely. And if it can be applied in a marketing sense, what happens is you suddenly realise that the pace of the project picks up. We talk about cadence in software development terms. So, cadence is about how fast you can actually get a production piece of software into the hands of users.
So, if you’re doing agile really, really well, you should be able to get two or three production releases out per day. Now, any software developer listening to this will say, that’s insane. You can’t do two or three software production releases a day.
Well, actually, yes, you can if you’ve got the setup, right and you’ve actually got the relationship between our wrangler and our one, you can do that. But it’s a change of working practices that would not normally take place.
Darren:
And I was going to say that the big thing that’s screaming in the back of my head here is this is a huge cultural change for most organisations, where there’s this sense of hierarchy and approval processes that are multiple points of contact and the like.
Paul:
Yeah, it’s a massive cultural shock to a lot of large enterprises. And I’d be fascinated to know how agencies in particular, who have tried to adopt agile with their customers have got on; what have they seen as being the challenges, because I bet the culture thing is going to be a really, really big issue.
Darren:
Yeah, absolutely. Now, it’s interesting because there are agencies that have come from a software development background, and there you find agile exists in the actual development, but the interface into the client is where it struggles. And sometimes even the interface into the rest of the agency, it struggles.
It does exist in the culture and the function of software development and can, but it’s at those interfaces all the time where we have trouble.
I’m wondering from your perspective, because you’ve mentioned a few things. One is speed. That agile is the ability to speed up a change process. You’re also, utilising less resources to achieve more, so productivity is another one.
And also, I imagine that there’s a cost aspect associated with it as well, because you said before what percentage of software projects don’t actually fulfill their need — that must be a huge opportunity cost loss.
Paul:
It is. But I think there’s another factor that we haven’t talked about, which is really material to successful agile anything, and that’s the competence of the individuals who are doing it.
So, when we were in Three Weeks, we set about trying to train developers and wranglers in our clients. So, basically, taking our method and our approach and our interpretation of agile and turning it into something that could be learned by people and our clients.
And what we discovered very quickly was that the kind of benchmark that we had set in our organisation for the quality of developers and wranglers was so high that it was really unrealistic to expect any of our clients to have the same level of competence in those individuals.
Not to say that they couldn’t get to that level, but it’s the difference between being a good club runner and being an Olympic runner. There is a difference in performance and capability, which the gap can be bridged, but it’s going to take a while to get there.
So, what we had to do was to start thinking about how can we not be dependent upon the developers being in the top 5% of developers in Australia. And what we did was to kind of break down some of the responsibilities in that group of three to a larger group.
So, we ended up actually training up a group of five or six people instead of three, so that we knew we had capacity to be able to train our people who weren’t quite at that Olympic level yet.
The competence of individuals actually undertaking agile is incredibly important because they do need to learn new skills. They need to learn new levels of skill in order to be able to fulfill the same kind of thing that a pure agile team can do.
And again, I’m not sure how that translates directly into marketing. But I’d be interested to know if there is a model there that would keep the integrity of the team of three, who are the core team, but then allow you to build capability around that, to ensure that they can still deliver these iterations and project outcomes in a very, very rapid way.
Darren:
Well, I’ve got two case studies that I’ll share with you from real life and I’d be interested in … the first one was quite a senior CMO who was telling me how they’d absolutely knocked agile on the head, really sorted it out. And that the campaigns or the work that they do, where their agencies in the past would typically take 12 or 13 weeks, they got down to six weeks.
And the way they did that is every morning, they would start the day with a stand-up or a meeting of everyone, and they would just be sharing and reviewing the progress of the last 24 hours.
Now, my point was, all they’d really done is taken the natural pace of a linear process and sped up the plates. You know, whereas before there would be normally a weekly meeting of updates or to go through the next gate, they were making this every 24 hours.
And when I asked around resource utilisation, they didn’t want to know about it because apparently, there was a big problem from the agency with how much time it took on their part to attend all these meetings. Is that agile?
Paul:
No, it’s not. It’s an accelerated way of working, but it’s not agile. So, I think the main difference being we talk about small iterations, we talk about the ability to release working versions of software on a very rapid basis. Having this cadence release is fundamental to it.
The bit that that may be missing, I don’t know, is the interaction with customers. So, I know that data analytics is a foundation of anything that might be described as marketing agile or agile marketing, and for good reason.
The ability to be able to extract useful information from the data that you’ve got is going to have a profound impact on how you then start applying that to your marketing campaigns and how you then get the feedback from customers will determine how you make changes and move on.
So, I think what you’ve described isn’t agile, it’s just speeding up a process. All it’s done is to speed up a process. It doesn’t necessarily adhere to any of the principles around agile because it’s not really focusing on interactions rather than processes. It’s not necessarily delivering a valued outcome rather than focusing on the documentation. It’s just doing it quicker.
Darren:
And you said before, where ritual and the labels associated with the agile ritual often mask what’s happening underneath. It makes it look like it’s agile because this CMO referred to daily stand-ups and therefore, ipso facto, it must be agile.
Paul:
It’s not agile, but look, I mean, if it produces a good outcome, who’s to say, it’s not a bad thing. I mean, it’s a good thing.
Darren:
Well, I think we need to look at more than this anecdote that I’m sharing. Well, look, you got me … because you already touched on the second example, I wanted to give you. And this was very impressive. It was a very large marketing department for a telco.
They had traditional marketing over there, churning out campaigns on a program in the traditional way, but there was one small group to one side called the performance marketing team. And it’s interesting, you should say the team of three, because there was someone focusing on data analytics, both what was happening and what the responses and the rights were.
There was one focused on content and messaging, and one focused on media. So, it was a team of three. And their job was to acquire as many mobile phone customers, plan customers, as they could as fast as possible, and for the lowest possible cost of acquisition. They were their KPIs.
And so, they were literally working in cycles of putting things into market, messaging, and content, testing out different media options, and then analysing the results. And when they got positive, they would then use that to learn in the next cycle and do more and test more and more and more until they were absolutely …
In fact, the marketing team hated them, absolutely hate them, because senior management was going, “We’re getting more customers and making more money out of this team, this performance marketing team than we get out of all these people sitting over here.”
And they kept saying, “But we’re responsible for brand.” And the performance team are going, “Well, we’re building brand. Everything we say is part of the brand messaging.” We’re just getting lots and lots of customers doing it at a very increasingly lower cost.
Paul:
You have just described another characteristic that we came across time and time again, whenever we were working in large enterprise customers, which was we were the most unpopular team of software developers in the room.
And what you’ve just described there with a performance marketing team, I’ve also seen with some colleagues of mine at a company called North South Advertising, I don’t know if you’ve come across them.
They’re paid search specialists, and they exhibit exactly the same characteristics that you’ve just described in performance marketing, which is small team of people, focused on delivering outcomes, very clear charter, constantly iterating and learning, and producing phenomenal results; and not very popular with the rest of the marketing team, because they’re doing stuff that’s working and they’re continually impressing their peers and their bosses, because they’re actually delivering great outcomes.
So, your example on performance marketing is the closest thing I’ve heard of to being true agile in marketing.
Darren:
And what I particularly liked about it was that it was an ongoing process. Like they never believed that they would actually achieve, so this always on, always testing, learning.
And the other thing I liked about it, they didn’t fall for the trap that a lot of marketers do, which is if something didn’t work, they were happy to just stop doing it and move on. There was none of this attachment to a particular strategy or tactic.
If the numbers didn’t prove that what they were doing was effective, they would very quickly drop it and move forward. So, there was this sense of constantly moving forward towards finding the better result.
Paul:
And that’s a tough discipline because a lot of people struggle with that. That ability to not become emotionally attached to an idea, or to just hold a belief when it’s proven to be unfounded. And that’s a very, very valuable commodity, particularly in marketing.
If you’ve got a group of people who are prepared to just ditch something they’ve been working on for the last week because it’s not working, then you know you’re onto a winner.
Darren:
Actually, on reflection and in this conversation, I suddenly realised you had three very different types of people in that team as well. The data analyst was very much about looking at the numbers and trying to find the insights.
The content person, they didn’t own the brand communication, but they were very much aware of it and worked with that. But they were constantly looking for what are the things that I need to say and how do I present them? So, they were still in that area of creating messages.
Whereas, the media person, again, was probably quite numbers and performance-focused because they were looking for people and looking for the right environment and the right number of people to make it scale. And they also had this quite complimentary, but very aligned focus on pushing the numbers. Interesting.
Paul:
Yeah, and I think that’s a great combination as well because there’s no overlap. And each of them can individually interface to other parts of the business in order to be able to gather insights they perhaps wouldn’t be able to bring on their own.
So, this strong communication is another characteristic of really good quality agile, is often face-to-face by the way. So, face to face communication either with the end user or with customers and the others that you work with in the team, is a profoundly important aspect of good agile practices.
Darren:
Well, it’s interesting because I think that’s where they failed.
Paul:
Oh really?
Darren:
Yeah. They were so into what they were doing that they interfaced with sales a bit just because sales were leaping off the back of what they were doing. But yeah, largely marketing and the other components within the business were held at arms distance because they saw them as getting in the way of what they were doing rather than facilitating it.
Paul:
It’s a big risk, I think when you introduce agile teams into a traditional environment, whether that be marketing, IT, finance or sales, there is a sense of who are these people? Why are they being given special attention? You know, what’s different about them.
It can be quite challenging to begin with because there is that kind of a sense of, “Are these people going to take our jobs away? They’re only three of them, and there are 20 of us. Does that mean they’re going to make us redundant?”
That happens quite often when true agile teams start emerging within organisations, that it can generate a bit of suspicion and mistrust.
Darren:
Now, you said that the idea of small teams, very focused; from that point of view, you could actually develop brand or marketing strategies in an agile way.
Paul:
Of course. Yeah, I don’t think there are boundaries in the marketing domain around adoption of agile. I think you’ve pointed out — I mean how you would apply agile principles in something like manufacturing or in … well, in fact, you can in manufacturing; but in finance, it is a little bit challenging.
If in finance, you adopted the view that you would have finance people working in teams of three, and then you would encourage open and honest communication and that they would be responsible for reducing innovation and change in that domain, then maybe yes. But it’s not applicable to everything.
Darren:
And yet, a lot of organisations have almost embraced it like a religion.
Paul:
Look, it’s a shame that that should happen. But I mean, I think that that’s often the case, isn’t it? With methods and tools that work, people tend to become quite obsessed with them.
If you go onto YouTube, I mean, there are literally thousands of videos and posts to do with agile, with various consultants and gurus suggesting that they’ve come up with a new way of adopting agile and building it into enterprises and small businesses.
It’s probably a factor of success, isn’t it? One of those kinds of deficits that happens where when something is successful, everybody wants to jump on the bandwagon and come up with their particular spin on it. And it’s about a whole industry of trainers and developers and people who are consultants in agile methodology and Scrum and the like.
Darren:
And lean, as well.
Paul:
And lean, of course, let’s not forget lean, yes.
Darren:
Don’t forget lean.
Paul:
No, no. We covered that in the book too.
Darren:
I wonder if some of what’s driven this is those rituals though, because in a way, they’re a visible and very tangible expression of doing something different. Even though, to your point, they’re not actually needed to be agile, they’ve become almost like collateral to agile.
Paul:
Well, they have but it’s a very tribal thing, Darren, isn’t it? I mean people like to belong, they like to be part of the club. They want to be in with the in-crowd, they want to be able to associate with others who understand what’s good about it, and what’s bad about it.
I mean, the IT sector is brilliant for this because of course, there are programming languages and there are methodologies and tool sets and ways of working, which encourage people to develop their own language around how they collaborate and work with each other.
So, it gives people a comfort factor, I think, being able to use words that are easily associated with what they’re doing, which doesn’t necessarily mean they’re really good at it.
Darren:
Well, who doesn’t want to be a Scrum Master? I mean, it just sounds impressive.
Paul:
Yeah, it does, doesn’t it? Yes, once you’ve learned to be a Scrum Master, you’re the master of the universe.
Darren:
Well, the book is amazing in that you you’ve managed — well, you and Andrew have managed to take these principles and actually provide them in a really clear way of how you applied them to software. But how it’s principle-driven rather than necessarily a framework-driven.
Paul:
Yeah, so look, Andrew is doing a phenomenal job with it because he is now taking the principles that we developed around our approach to agile, and finding ways to get that into the education system.
So, he’s working with a number of education bodies now to actually build this into the curriculum in schools and universities, because if we can help young people understand these principles when they’re learning to program, and they’re learning about computer science, there is every possibility that it will start to emerge in a lot of the working practices in software companies as well.
And besides that, Andrew’s also working to identify opportunities where we can train up other people in the method. So, in enterprises, who’ve got large software departments or software development departments, he’s going in and helping them actually understand how they can develop and manage those principles themselves.
Darren:
Look, I would absolutely recommend this book to any marketer who is facing the threat of being made to work in an agile way by a consultant that is spouting all the words, but not necessarily making a lot of sense. Because I found, first of all, it’s not a particularly big book.
But I read a quote recently that most business books are about one third insight, one third just talking about your own experiences, and one third padding just to make it seem like it was worth the money that you’re paying. So, I think hopefully, you’ve cut out at least a third or a half of the waffle to just fill it with insights.
Paul:
Yeah. I mean, what we were trying to do with the book was first of all, just give everyone a quick history lesson on how software development techniques developed over 50 years. Secondly, to share the original principles and values of agile and how we had applied that philosophy and not adopted a method or a framework.
And then third, we wanted to share examples where we had been able to apply this because we did over 260 odd projects ourselves. And we also train people up in the method in a couple of our clients.
But the proof is in the pudding, isn’t it? The two big case studies in there for a news corporation and for Monash University where we were involved in multiple projects, applying this method, really is vindication that it works, and that you don’t need to have a set of rituals to make it work.
You just need to have the intelligence to use the philosophy that was originally in that manifesto and then apply it consistently every day, and it produces amazing results.
Darren:
Yeah, makes a lot of sense.
Paul:
And I do believe that it can work in marketing. I’ve seen it work in marketing, but it does take some effort. And there are definitely aspects of the agile methodology, which will work in marketing and others that won’t. And you just need to be honest with yourself about which will and which won’t.
Darren:
Well, could you share an anonymised example of what would work or what you’ve seen work really well?
Paul:
In marketing?
Darren:
Yeah.
Paul:
Yeah, I mean, the only ones that I’ve had exposure to are the ones that the guys in North South have been doing, and they’ve got clients in mainly the retail sector. And what they’ve proved is that they focus on an outcome. They focus on delivering a very clear outcome for the customer. They set up a hypothesis in terms of what they think the paid search needs to be focused on and they start hitting it.
And within a matter of days, they’ll have results that will demonstrate to them where they need to be making changes. And then it’s a case of literally iterating on the fly. They’re doing it two or three times a day and producing phenomenal results.
Small team, only three people, and they insist on working with one person in the client, the one, who will be the single point of contact. And it works every time.
There are people who won’t work with them because of the way they work but they’re smart guys. And they realise that if they compromise on their method, they’re not going to be able to produce the results that clients want, and they stick to it.
So, it can work and it could work in an in-house team. That performance marketing team example you gave is a really, really good example of how it can work within an agency or within an in-house team. It can do.
Darren:
Absolutely. Paul, is this book widely available?
Paul:
All good book sellers, of course. There’s not an audio version of it yet, but we’ve got an eBook as well as the physical one. And yeah, it’s available.
Darren:
So, it’s Beyond Agile: How to Run Faster, Smarter and Less Wasteful Projects by Andrew Walker and Paul Scott. And I’ve been talking to Paul Scott today. Thank you very much for coming back and having a further conversation, it’s been terrific.
Paul:
Not at all, Darren. It’s a pleasure talking to you again, and thank you very much for inviting me back.
Darren:
Okay. So, I always ask a question at the end and I’ve got another one for you Paul; you have to tell me where have you seen agile just go completely balls up?
Paul:
Well …
Ideal for marketers, advertisers, media, and commercial communications professionals, Managing Marketing is a podcast hosted by Darren Woolley and special guests. Find all the episodes here
