The gains in productivity that come from implementing Agile in your organization are monumental, but so can be the headaches when you’re getting everybody on board. Ben Beavers, principal consultant for MI-GSO | PCUBED UK, joins James Lewis to talk about how to ease tensions and make your teams run smoothly with Agile.
James Lewis: A very good afternoon to the MI-GSO | PCUBED community, and anyone else who’s listening to this on our website, and welcome to the latest in the suite of Coming Out Stronger podcasts. So, this set of podcasts, we’ve decided to do it because, in these strangest of times, we want to give everybody within the MI-GSO | PCUBED family and anyone else who wants to listen in the opportunity to actually come out stronger the other side from a professional development perspective.
So, the podcasts themselves will cover a range of capabilities that MI-GSO | PCUBED are able to deliver to their clients and just talk about some of those capabilities in a little bit more detail.
And today, a critical topic one which is all our clients are interested in it at the moment, and that is Agile. So, I’m going to talk to Ben Beavers on the topic of implementing agile. Ben’s a principle consultant in the UK business. He’s been right at the vanguard of all our Agile thinking for some time now and has done a lot of SAFe training and other kinds of Agile training, like scrum master. He’s also got a lot of delivery experience in that area. So, delighted to have him with us. Ben, good afternoon.
Ben Beavers: Thank you, James. Delighted to be here.
James Lewis: Excellent. So Ben, I’m going to kick off with a question around the fact that people seem to have a lot of things in mind when they talk about Agile, the word is used, you could say quite loosely. Sometimes “Agile” with a big A, agile with a small A. How would you describe Agile when we’re talking about the Agile, which we’re helping our clients implement?
Ben Beavers: Absolutely. So, it’s one of the challenges that you see when you talk about Agile people seem to mean so many different things when they talk about it and nobody seems to have quite the same meaning.
What we find is typically when people are talking about Agile, It will fall into one of four categories. So, the most common is frameworks. So, we’re talking things like Scrum, Kanban, SAFe delivery methodology here. If I was to give an example, as a Scrum master, I would say I’m being agile because I’m using a Scrum delivery method, and I’m working in sprints in, and my team is fully embraced in this agile approach.
If I was a project manager, and I said that I was being agile, we’d say that they fall into a category called “Agility.” So if, as a project manager, I’m applying a sandbox or I’m using demos alongside my traditional project management set of tools, I am applying Agile in a way, but I’m applying agility, because I’m applying tools, techniques to help me address challenges that I’m seeing in my delivery environment without necessarily applying a full scale framework.
The next one that we tend to see people using agile to mean is culture. So, an example of this could be – and I’m sure people have come across this – as a manager, I’m saying to the people within my team, “Guys, you need to be more agile.” And when I say, “You need to be more agile,” I don’t necessarily mean go out and start using Scrum. What I might mean is, “I need you to embrace changing priorities a little bit better.” So, I’m talking about certain cultural and ways of working changes.
The final one that we tend to see people referring to Agile using is Business Agility. So, this is quite a big one, and this has been a hot topic for probably three and a half, four years now. And to my mind, I think this is the reason that we’ve really see agile hit the forefront of the stylish project management ways of working.
But when we talk about business agility, we say, as a CEO, I’m looking at how I structure my organization to adapt to disrupters and challenges in the market.
Now, when I look at it from that perspective, I will look at frameworks. I look at Agile frameworks. I’ll also look at traditional delivery frameworks. They all have a place. I’ll look at agility, applying tools and techniques. I’ll be looking at the culture. How do I change and adapt the culture in my organization? I’ll also look at how I do my resourcing. I’ll look at my strategy. I’ll be looking at the digital technologies we’re using.
So, we talk about Agile in a much more broad sense when we talk about business agility as a topic.
So, to briefly recap, we have frameworks, so the delivery approaches. Agility, applying tools and techniques to improve your delivery approach. Culture, adapting your way of working. And then Business Agility – how do I make my entire organization able to respond to disrupters and challenges in the market?
James Lewis: Okay, that’s excellent, Ben. Thank you. So, if something you mentioned that is of course, the fact that most organizations will have previous to Agile being introduced, being using a traditional project and program management methodology is mainly Waterfall.
And very few, from my experience, of our clients are 100% embracing Agile in its purest sense, which means inevitably that you are looking to implement Agile alongside Waterfall to a certain extent. Now, my question to you, Ben, is does this cause tension in the organization? Is it a cause of conflict? And if so, how do you address that?
Ben Beavers: Yeah, implementing agile can absolutely cause conflict in the organization. I would caveat that by saying introducing any change in an organization is likely to cause conflict and challenges within the organization. So, that’s where you’ve got to be very conscious of your change management approach, and you’ve got to make sure that that is weaved into the way that you’re implementing it.
Specifically, with Agile, there are different ways of working. You have different constraints, different reporting approaches, different assumptions that allow the methodology to work as a whole. So, when you are implementing it, you really need to consider, “What is the appetite within the organization for agile? Are we trying to do it piece by piece? Is there a top down directive to completely drive all the way through?”
Because this will guide how gently and softly you put it in, or whether it is a big bang change that there’s a lot of pain, and it just need to be aware of how you manage that and drive it through.
I think further to that, just talking about Agile within an organization causes conflict within it, because – referring back to the four previous points about frameworks, agility, culture, and business agility – different layers of the organizations tend to mean different things when it comes to Agile. So, at the senior level, they tend to be talking about business agility and culture.
The ways that you see agile come into an organization is typically either at the team level, people starting to to use it, liking it, and trying to push it upwards, or at the top down, “Right guys, we’re going to do a complete change in our way of working. We’re going to embrace agile.” That tends to come to a head in the middle layer because the top layer is talking about business agility, the big stuff, the big cultural change.
At the team level, they’re very much focusing on frameworks and delivery approaches. And the middle management, they get caught in the middle. And they’re being told they need to be agile by the guys at the top, but the guys at the top don’t necessarily mean that being the Agile that the guys at the bottom are using.
So, it’s important to have those concepts in to reduce conflict so you can make sure that everybody is talking on the same page, so to speak.
James Lewis: Excellent, thank you. That’s good clarity. So now I’m going to move on to Agile, and the fact that it comes fully equipped with its very own vocabulary.
A lot of new terminology in there, and I think what a lot of listeners might be interested in your perspective on is whether or not the vocabulary for various tools and artifacts and ways of doing things is brand new, or whether or not they have basically taken an old car spray painted it and are trying to sell it off for something brand new, or whether or not is this be something in between the two of those?
Ben Beavers: It’s a very good question, and terminology is certainly one of the things you get overwhelmed with when you’re new to Agile. There are loads of different words that are brand new, sound a bit weird, sound a bit quirky. So, being prepared for the wave of terminology is important if you’re going to start using it. It’s like learning a new language.
So, you do need to learn the terminology. You do need to know what it refers to. But the terminology itself doesn’t necessarily refer to new things. Some of the things are new. There are different ways of doing things. Some of the things are slight adaptations or things you’ll be familiar with from traditional delivery.
And some of the things are just new names on things that you’re very much used to do. It’s important to know Agile doesn’t try to reinvent the wheel. It does borrow from where things work, but it does fundamentally work in a different way.
It’s not a long, linear delivery process. It works in cycles, and it iterates through, and it learns, and it adapts, and changes your requirements and your priorities as you go through without very structured change process, bringing those changes in. That just happens as part of the delivery process.
So, it does borrow things that do work, but it brings them in and then adapts them and weaves them into its own way of working.
James Lewis: Okay. And something else I’ve noticed is there appear to be slight mutations of Agile, which come from the overall Agile wellspring. So, for instance, Scrum, SAFe, and Kanban – tell me the difference between those three and perhaps give our listeners some indication of when you should use each of them respectively.
Ben Beavers: Absolutely. As you said, there are loads of different Agile approaches and they all adapt for slightly different circumstances or slightly different environments. So, the three you mentioned are definitely the most common; so Scrum, SAFe, and Kanban. So an important distinction between Scrum and Kanban and SAFe, is that Scrum and Kanban are typically team level methodologies.
SAFe is a larger framework that you would use to apply up to a program level. So, one of the big deciders as to which you’re going to use if you’re managing work would be actually what’s the size of the team that I’m working with. If I’m working with a smaller team, I would look at something like Scrum. And by smaller, I mean, less than 10 people. If I’m looking at 50 to 100 people, I’d be looking at something like SAFe.
If I’m looking in between that, if I’ve got two or three teams, depending on the level of governance that I’m looking to apply, I would either choose Scrum with a bit of Scaled Agile Governance over the top, or I’d look at implementing SAFe at a program level.
Kanban’s quite an interesting one because Kanban is a delivery methodology on its own, right. It allows you to continuously deliver. So, if we think of Scrum and SAFe as they will say they continuously deliver and they do, and you can release it any time, but you’ll plan in increments. You’ll plan in either normally two weeks in Scrum and delivering at the end of that two weeks, or SAFe, you will plan a over a 10 week increment with two weeks sprints underneath. With Kanban, you’re continuously prioritizing, continuously delivering, when it’s used as a delivery methodology.
If I had a service desk, a support team who couldn’t say, “This is all the work I’m going to be doing for the next two weeks,” because they have to be responding to queries. That’s when I’d look at using Kanban as a delivery methodology.
Kanban, interestingly, can also be used just as a way of visualizing your work. So, you can use Kanban to visualize the work you’re doing in Scrum to visualize the work you’re doing at SAFe, to visualize your own personal backlog. But Kanban is a delivery approach is best suited for teams who need to continuously deliver, continuously re-prioritize.
James Lewis: And actually, it leads quite neatly onto the, the final thing. So, if we have consultants, or we have clients, or just people listening to this podcast who are required in the near future to implement an agile approach within an organization for the first time, what should those people consider? What’s your advice to those people as they set off on an Agile journey within an organization with the responsibility of implementation?
Ben Beavers: Very good question. So, leaning back to the previous answers, firstly, terminology. Be aware of the different terminology that’s used and make sure that when you’re implementing it, you are clear on the terminology you’re using and the rest of the team are clearer, as well. Otherwise, there will be confusion. People will use different things to mean the same thing or the same words to mean different things. So, it’s important to get that relatively clear.
Secondly, which methodology you’re using. Don’t just pick the most popular one. Think about the constraints in your environment. Think about what you need, and then decide which methodology or approach you should be using.
So, if it’s a small team, again, Scrum. If it’s continuous delivery with a support team, probably something like Kanban. If you’re implementing it across multiple teams, if you’re implementing it very broadly across the organization, something like SAFe is probably going to be most appropriate.
Then you’ve got to understand what are the assumptions each of these methodologies make. So, if you look at something like Scrum, Scrum assumes that everybody’s in the same room. If people aren’t in the same room, you need to consider how you adapt to that. So, if you have people in multiple locations, multiple time zones, your communication is going to be impacted. Scrum is going to assume that people can just get up and talk to each other.
Particularly in times like this, we can see that that’s not always possible, but if you’ve got multiple locations, that’s definitely not possible. So how do you put in place communication channels to replace the assumed communication that’s not able to be fulfilled.
Be aware of people’s different experiences. So, people tend to adapt the methodology, which is great. You should, you need to adapt it for your environment. But if you have a team of people, who’ve all say they’ve done Scrum before, and they’ve done it here, and they’ve done it there, and they’ve done it there. Don’t make the assumption that they are all going to end up working in the same way.
If you get a group of 20 people in the room, they are going to tell you the best way of implementing Agile, but it’s going to be 20 different versions of the best way of using Agile. Define your way of using Agile. Define what you’re doing – define what you’re not going to do.
Float it with the team. You will get some objections. You will get some concerns. The best thing to do is to pull back and say, well, as part of our approach we have retrospectives, and in retrospectives, we identify ways that we can improve the process. So, if we don’t like it in two weeks, four weeks, six weeks, as we go on and we let the process embed and mature, we can adapt it and we can change it then.
That will get people buying into it and going ahead with it. And normally, by the time you get to that point, people are used to this way of working. They’ve forgotten about the old way, and actually they’re pretty happy on this because they’re just focusing on getting the products out now, which is what they’re paid to do.
And then the final point I would say to consider is the delivery environment. If you’ve read the Scrum guides and go out and try and apply that to the letter, then you’re doing it wrong. You have to understand the principles and the values that sit behind it. And you have to understand the principles and the values in the organization you’re implementing it in and you have to adapt. You have to adjust the approach for constraints for the environment that you’re in. Equally, the organization itself is going to have to adapt as well.
It’s a two-way give and take, but if you go in and you implement it and you say, “This is what we’re doing, because this is what it says in the book,” it’s the wrong way of doing it. You’re not embracing the values that underlie it, and it’s not going to work. It’s not going to land. You’re going to end up with all sorts of problems and challenges, and it’s going to cause too much friction to actually land and get bought in by the organization,
James Lewis: Ben, some great stuff, right there, some really sound advice. Thank you very much indeed for your time today. And it’s been a pleasure having you on the podcast.
Ben Beavers: No problem, thank you very much for having me.
James Lewis: And to our audience that concludes this podcast. Number seven on our series. We’ve got some great new ones being lined up, but for now, please stay safe and well and have a great rest of the day, whatever you choose to do. Thank you very much, indeed.
A monthly digest of our best articles on all things Project Management.