← The Digital Marketing Podcast
The Digital Marketing Podcast
Understanding Agile Working
00:18:20
With the launch of his new Book . Daniel walks us through the basics of Agile working methodology, a key working methodology for working in a fast changing environment. Learn how you could employ this development philosophy to enhance your digital...
Loading summary
Transcript37 lines
- [00:01]
A
Welcome to the Digital Marketing Podcast brought to you by targetinternet.com hello and welcome back to the Digital Marketing Podcast. My name is Kieran Rogers.
- [00:19]
B
And I'm Daniel Rolls.
- [00:20]
A
And today, Daniel, we're going to be talking about agile working.
- [00:25]
B
That's absolutely right. Now the reason we're working and talking about agile is that one, there's quite a lot of interest in this topic area, but it's something that's come out in a book that we're about to publish. I just want to do a bit of an announcement about the book.
- [00:36]
A
I'm really interested in this as well because if you've met me, I'm not particularly agile. I mean, you'd know that. So, you know, the more agile you can make me, Daniel, the better.
- [00:43]
B
Well, I think there's a big problem in organizations and that is that the working processes for digital are slowing things down. And myself and my co author, who I will talk about in just a second, have written a book called Building Digital Culture. And Building Digital Culture is basically all about the stuff that causes problems with digital that isn't really digital. So it's the stuff in terms of the strategic planning, the infrastructure, the it, the working practices, the culture within organizations. And I wrote this book with a guy called Thomas Brown. The book comes out on January 3rd of 2017. We've got the big launch event at Twitter at the end of January. So what we're going to do with the launch event is we're going to live stream it. We've got some really fantastic speakers coming up. But also what we're going to do is going to make some recordings of some of those discussions as well. So we're very, very lucky to have some really good people coming along for that. So we'll get all that details out now for the book. The book is going to be available, it's pre order now, obviously Building Digital Culture, but we're going to give away a few copies as well. So if you would like a copy, what we would like you to do is if you like the podcast, go and leave us a review on itunes. Itunes, probably best place to do it. And if you go into itunes, leave us a review and then ping us an email to say you've left us a review. And if you just email us@contacttargetinternet.com we will then put you in the draw. And then anyone that leaves a review, whether it's a good or bad review, it can be an honest review. We will then pull some of those names out the hat. And we'll send out some comments. Copies of the book as well.
- [02:23]
A
How many chances to win?
- [02:25]
B
We will do 20 copies of the book.
- [02:28]
A
20 copies.
- [02:28]
B
There should be a fairly good chance of getting a book based on. In terms of getting some reviews from that as well. So that'd be good.
- [02:34]
A
Coming from a pantomime background. If I was on stage right now, I'd be looking to the audience to go, ooh, do the whole raising hand thing up. That's not gonna work in this medium, is it?
- [02:43]
B
Probably not. As we're in an empty room, it's just the two of us in the studio, it'd be a bit strange.
- [02:46]
A
Okay.
- [02:46]
B
Say the least damage. So. So building digital culture. Loads of really good interviews and case studies there. We're really pleased with the people we got to speak to. And what it's really looking at is the idea of digital transformation, which is how do you change an organization to make it more effective for digital? And how can you do digital effectively?
- [03:04]
A
So, Daniel, how am I going to make my organization more agile?
- [03:07]
B
Well, one of the things we looked at in the book was this agile working. And if you're not familiar, agile is actually basically a set of values rather than a particular project process. But what it's based on is this. So most projects are done on a waterfall basis.
- [03:23]
A
A waterfall? Yeah, just explain that.
- [03:25]
B
So waterfall is the idea that you do something and then once that's complete, you can then move on to the next task and then that drops down to the next task. And eventually at the bottom of these kind of tasks, you end up with something to show your stakeholders the people are interested in the first place, and that's the waterfall. But the problem with that, there's a number one, is that first of all, you have to go all the way to the end of the project before you've got anything to share with your stakeholders, which is not good. If they say, build us a website and you go, no problem, we're going to go off and build a website and we go off and we look into our users and we've done that bit and then we start to build a project and then we get the web design done and then we build it technically, and then we test it and then we get to the end and they look at it and go, that's not what we wanted at all. And it does happen. The other thing that will happen is that you'll be going through this process of project steps and you get to a certain project step and something goes wrong. And that then holds up everything else, which means that nothing else progresses, which delays the entire project. So these stalling points can be a big problem in most projects as well. The other thing is you have particular teams working on particular parts of the process. So you might have the marketing team on one bit and you might have the team that deal with PR or copy dealing with a different bit. You've got the technical developers dealing with their bit and because they're working in isolation, if their bit goes wrong, it delays everyone else's bits as well. So it's generally something we have a problem with in most projects. So the idea of Agile is say, well, let's take away this quite cumbersome process, but let's try and build a kind of process that allows us to do things more effectively.
- [05:00]
A
So it's like pain removal, it's a very painful process to go through, particularly when you hit those.
- [05:05]
B
It is. The other big problem is what happens if the specification, what you're trying to achieve, changes halfway through. Oh, and that always happens, which always happens, right? It happens in every single project. And it means quite often you have to go back to the top of the waterfall where you need to start with your specification again.
- [05:17]
A
But very often people don't.
- [05:18]
B
That's where the and then they try and plug everything into what they've got and it just all turns into a bit of a disaster. So when you're looking at improving your ability to deliver projects, whether that's websites, apps or even just a piece of content, it's looking at these kind of methodologies for working in more effective ways.
- [05:35]
A
And it's sort of a self fulfilling prophecy in a way because actually if you are more agile, the whole process is going to be quicker by its very nature, isn't it? And if it's quicker, there is far less chance for somebody to come up with another brilliant idea that I've just thought of.
- [05:48]
B
That's exactly it. And one of the things that we say and we look at in agile working is that actually you protect people when they're working in these little working cycles. So generally there's a set of kind of principles or ideals behind this agile working and they are, it's about individuals and interactions. So your teams will be cross discipline, which means you can be flexible, but it stops any unnecessary hierarchy. So this is quite challenging for organizations where you take a number of people from different teams and you put them onto a project team and you allow them to kind of run with that project. It's about output. So you work with Building prototypes, interactive prototypes, little bits of functionality at a time, rather than trying to build the whole thing. Your customer has to be at the heart of this. There's customer collaboration involved in this. Now really that's about user centered design, but that's kind of built into the Agile working. And because you work in quick responses, you work in these cycles which we'll talk about, which we refer to as sprints, you are able to then say, right, there's been a change, right, let's look at that and let's build it into next Sprint. As we kind of go through now Agile itself, there are a whole load of different ways in which you can implement it. You have some ways that are very prescriptive and have lots of rules to follow. And then you have the ways of doing that are more adaptive and have very few rules to follow. So at the basic level you go, just do whatever, put a project team together and go achieve it and do whatever you want. Now there is some risk of that, obviously, depending on the individuals. So somewhere quite nicely in between is the idea of working in Scrums. And what a Scrum really tries to do is you split your organization into small cross functional teams, but also you split your work into a list of kind of small concrete deliverables. And then you sort that list by priority, you estimate the relative effort to do each those bits of work and then you try and deliver them in this Scrum working process. So what you've got is you start with something called a product backlog, which is a stack of bits of work that you want to do, and you split those up into something called sprints. And sprints are these working processes. You might have a week, two weeks. We generally say, don't do more than four weeks because that's too much really for a sprint. And then what happens is you go in and you say, right, we know how much work we can basically do in this week or two week period. We've got the project team, we've worked out the kind of hours involved in that and we've split all of our work down into the number of hours. And then what we do is we go off and we run this sprint for maybe two weeks and we know what the deliverable output from that is. So that might be bits of the functionality, it might be a prototype, it might be just changing the functionality of a particular button. It doesn't matter what it is. And then you have daily Scrum meetings. And that's when you basically look at what we've done, what we're going to do next and what the problems were. And you just go through that cycle and at the end of that sprint, you have a deliverable, whatever that deliverable may be, and then you go back to the product backlog and you say, what we're going to do next. Now, the idea is that actually, if the fundamental specification changes, that's okay, because your product backlog will have changed and you can decide what you're going to do in the next sprint. But you are protected during the sprint if things change. So you get to the end of what you're doing and say, right, we need to take a step back. There's only very exceptional circumstances where actually the whole project's canceled or something's gone disastrously wrong. You would stop halfway through a sprint.
- [09:10]
A
I've seen this in action, though, and it is very, very effective. I think what it does is it enables and empowers the teams to focus on what they're supposed to be doing. So a marketeer like me will come along and want the moon on a stick yesterday, and can we change this and change that and change the other, and you're hit with. From the project manager. Well, we could look at that, but not in this sprint. Oh, well, it's a sprint. It's like, oh, well, that's the thing. Well, I can't really question that. Sprint sounds like a formal, kind of structured thing, and it just works. You never told, but you're told, well, we can look at that and we can evaluate it and we can work that maybe into the plan. However, that gives everybody time to look at it, evaluate it, see how well it works into the plan. And if it doesn't, you're met with a, you know, I'm sorry, but that's out of scope. If we do this, if we change direction now, it's going to knock the whole project back and we're not going to be able to meet our deliverables. So it's a very, very effective management tool in larger organizations where any number of stakeholders might try and get creative.
- [10:13]
B
That's it. And I think it's about prioritization. You can say, yes, we can do it, but how much of a priority is it? And then where does it then fit into the schedule of work that we're going to deliver? Now, where this came from initially was in web development and kind of programming projects where you've got teams of developers working on things and they can go off and do their individual sprints. It allows them to focus on what they're doing. But this can work for anything. You can use this for graphic design, you can use this for HR projects for absolutely anything. It's just a change in thinking in the organization, but it gives you an easier structure to work with. There's a number of bits of terminology that go with this that can put people off. So if I just take you through those, but then we can probably put it in context a bit.
- [10:53]
A
It's an agile guide to the agile terminology.
- [10:57]
B
So your product, whatever you're trying to develop, that, that end product is described as a list of features. And that list of features is what you put in the backlog. So you have this backlog of work and the features, each of the features is described in terms of user stories. So it's very user centered. The audience will do this and this is what will happen and you kind of break it down into those functionalities. Then those features in the backlog are ranked in order of importance. So we prioritize them when we have an agreed process for doing that, and then a ranked and weighted list of these user stories. So these things that these little things we're gonna implement is called a roadmap. So we've got a backlog of work, we've worked out the kind of functionality, we built those into user stories, and then we go through and we build this roadmap and that's the work we're gonna deliver. And then we have these sprints, working cycles that normally last one, two, three weeks. And then you have your daily scrum meetings. So what did you do yesterday? What are you going to do today? And are there any obstacles to get in the way?
- [11:58]
A
And for those of you listening, I'm sure you've come across bits and pieces of this, but I'm really hoping that suddenly you'll begin to understand what maybe your development team that are using this or your IT team have been wittering on about. But it really is very empowering and can really help you to kind of get on their side and work with them rather than kind of railing and working against them.
- [12:20]
B
Yeah, I think this is really important with technical teams, particularly, as Kieran says, in that you quite often get an us and them attitude developing. And this is one of the things that came out in the book, by the way, was that actually, culturally you need your marketing and your technical teams to be more closely aligned because increasingly technology and marketing are hugely important because all the digital stuff we talk about all the time and actually if they're not aligned, it can cause huge roadblocks where all the it becomes or development becomes is say no, we can't do that, oh no, you don't want to do that. And they become this risk adverse part of the organization where they deceive themselves as there to block everyone else from doing stupid stuff and actually rather than doing that say no, there's a clear working process, we can put stuff in, we can prioritize it and as long as everyone's agreed that if we do this, this won't happen, that's fine. But it gives a much more transparent working process and it doesn't create resentment between teams and it doesn't create frustration. There's more clarity on what everyone else is doing. So it becomes really important from that point of view. So instead of the idea of a large group spending a long time building a big thing, we've got small time spending a short time building small things. But you can do a lot more of that and it becomes a lot more transparent as you go through. And from a cultural point of view, it starts to break down barriers because you've got cross discipline teams. And therefore when we're trying to work out our company structure, what works for digital in a fast changing environment, a fast changing world, how should we structure our organization? It's less important. There are still siloed bits of the business that have teams and have a manager, but actually those people always working together on projects anyway. So actually how you structure it is less important because you grab people from the right teams and put them into these cross functional teams to deliver particular projects. So it's a project based structure, so you can still have a development team and a graphic design team and a digital marketing team, but we just grab people from each of those teams, put them into the project and then deliver that project on each basis. And it works very effectively for getting the culture of the organization working the right way.
- [14:24]
A
So I'm very inspired by this Daniel, as I'm sure many of our listeners want to find out more about it or to learn more about the process. I think it's been a very good kind of whistle stop tour of, of the whole philosophy behind Agile development. How do we go about it? Are there any places you'd recommend?
- [14:40]
B
So one of the things we've done is we realized that when you talk about this at a high level in a podcast, it sounds great, but you need to get into the detail and really understand how it works as well. So we have added a quite extensive blog report on to targetinternet.com that talks about how you use this functional way of using Agile within marketing and digital marketing. So it will be in the show notes. So if you just go through targetinternet.com, go through to the podcast and it's forward slash podcast and you'll find the show notes and there'll be links through to that, so you can find that. Also all of our blogs and all the other content we do is just targetinternet.com blog, so you can find that. Couple other roostoors I've come across as well and we'll add these into the show notes. There was a great blog on the Moz website, so I'm a big fan of the Moz website, big SEO website. And they look at how you would apply the Agile Manifesto. So agile is, as I said, it's a process of thinking and it's really a set of values rather than a particular prescribed process of working. And they've analyzed that and said, look how this applies to digital marketing. So there's a good thing with Moz to look at. Also there was a lovely excerpt from a book, A Week in the Life of a Scrum Team, which really looked at how a Scrum team was kind of working.
- [15:56]
A
It's like a fly on the wall documentary.
- [15:57]
B
Yeah. And it was quite interesting actually, so it makes some quite good reading. So I'll put that link in as well, which is from the agilearninglabs.com website. Also, there is quite a lot on this in the Building Digital Culture book and we'll get an excerpt from the book that you can just download for free and read if you'd like to, onto the Show Notes as well. So take a look at all those things. So think very carefully about Agile, how you might apply it to your projects and actually it will save you a lot of pain. That's the key thing.
- [16:24]
A
One bit of advice I'd give you, if there are any teams practicing the Agile way of working within your organization, go talk to them. Actually, if you take an interest, they'll be really keen to share with you what works, share with you what difference it's made. And actually that's really great help in getting you to start thinking about how you might employ that within your own teams. And what better time to start looking at something like this than the New Year. New Year, New Year, New team.
- [16:51]
B
Exactly. One thing I would say as well, that you can look at this and if you're not careful you might go, this is a bit eccentric. And I tell you, the reason I say this is that one of the things that's really encouraged is in these daily scrum meetings is because we don't want more meetings for the sake of it. We want them to be as quick as possible. You do the meeting standing up, stand up meetings, right? And it's one of those things that I quite often look at these other things. I'm standing up meetings and I think, oh really? I mean, you know, why are we having a meeting then, if we can? And I actually it works. Having done these meetings a whole load of times, it does work. People get in, they get it done, they get out and they get on with working and it changes the whole mindset of the organization. So this is why culture is so important. And actually it does build the appropriate culture. So good luck with all your agile efforts. Get in contact. We want to hear your stories about these kind of things as well and let us know how you're getting on.
- [17:40]
A
Thanks for listening to another episode of the Digital Marketing Podcast brought to you by Target Internet. If you'd like to get more information on the show, get hold of back issues of this podcast, or get details on any of the links we mentioned, please visit our website at www.targetinternet.com. if you've enjoyed the show, we would love to read your feedback. Please rate us in itunes or even better, write us a review. Or if you have any questions, please get in touch. We'd love to.