Ep. 31: Training your teams

[00:00:00] Peter Maddison: Welcome to definitely maybe agile. Podcast where Peter Madison and David Sharrock discuss the complexities of adopting new ways of working at scale. Hello, and welcome to another exciting episode of definitely maybe agile with your hosts, Peter Madison and David Sharrock. How are you doing today, Dave?

[00:00:15] Dave Sharrock: Hey, doing really well. I think we've both had that chance to relax a little bit and get some free air. I think the way it is, isn't it. Just a few thoughts away from whatever's in front of you, in terms of screen time, work time, and client commitments. How about you? How are you doing?

[00:00:31] Peter Maddison: I'm doing good. I'm doing good. I have greatly enjoyed that little bit of time to take a breather and relax my mind. I think is absolutely essential to be able to do that, to try and to come back and be invigorated about all the exciting things we have to talk about!

[00:00:46] Dave Sharrock: Which immediately leads us to being invigorated by the huge number of things that we've somehow managed to commit ourselves to without heating our own best advice, right. About working limits, and process limits, and all the rest of it that come together with these things.

[00:01:03] Peter Maddison: But that's not all we're going to talk about in this session, although I think that's going to be coming in one, very, very soon. We had a conversation with somebody who reached out who said he was really enjoying the podcast and, he had this question and it went like this: As roles were evolving from your traditional IT roles, to more innovation on products and process re-engineering, how would a leader or manager, train their team to learn skills like process mapping? And what resources are there available to help learn those skills?

[00:01:32] Dave Sharrock: I really liked this question just because the implicit piece behind it is, that you're going to train up your team and teach them, or they're going to learn something. And the reason I pulled that one out straightaway, is so many organizations just expect people to be able to work with the skills they bring to the table, which is great. There is some very, very skilled individuals out there, and great teams that work together, but we really have to invest in people. We have to invest in the team. So then the question becomes, how do you train people up, right? How do you train rolls, IT rolls, when the environment they're working in has changed so much.

[00:02:08] Peter Maddison: Think it's a very good point. It's this implicit assumption that we'll be able to say, "Hey, go read this book". And you'll now know everything there is to know about this. And then you'll be able to go and act on it without providing the time and the space, and the training, and the learning, to be able to actually go and learn how to do some of these things. Which are, for a lot of people who are in very traditional IT roles, very new behaviors. These are very different to the things that they have been doing in the past. So coming in, asking them to, "Hey, go and be introspective and look at that process you've been doing for the last 20 years and completely reinvent it. Oh, by the way, read this book. It'll tell you all about the tools you need to know. See you in a month!" And then expecting miracles to happen.

[00:02:51] Dave Sharrock: Yeah. I mean, I think it talks to the fact that learning itself, has been undergoing a shift. I've got three kids at university. When I think back to my university days it was very much, you get a lecture, you've got a textbook, and you're really absorbing information. And it's your job to make sure you understand that information. You can solve some problems, but it's a skills based approach. Where the intention is, if you come in as a novice, then after a certain number of hours of learning and training, you're going to come out being much more knowledgeable. But the process is very much about transferring information, or knowledge, from one person to the next. What I find interesting when you look at things like universities now, they're moving much more to project-based learning. They're moving to scenario based learning. And part of the reason of that is reflected in the workspace.

[00:03:35] The idea that if you need a particular skill, you go out and either you get a course to train somebody up in that skill. Or you find a person, consultant, resource contract, a third party in some cases, or you bring them internally, who has that skill. And you bring them to the table and they go and do things. And I think when you look at things like innovation, when you look at product thinking. When you look at things like the agile teams, and how we're expecting them to work. The skills bit is a small part of what they're going to learn, and how that capability builds up. Another piece is the working relationship within the team. And it's not skills-based. It's picked up by learning through experiential learning. So there's a whole bunch of consequences that come by rethinking how we upskill our organization.

[00:04:24] Peter Maddison: Yeah. We used to have a leader that liked to describe the resources, which I hate that word as we're describing people anyway, within the organization as being fungible. So, we can just take them out and replace them with somebody else. And it's like going, "I think fungible has got nothing to do with mushrooms". It's not a good word to describe people. As we're looking at how you need to work in the much more complex environment that we're working in now. The old way of working, where we could take the work that we had to do, we could break it down into very specific sets of tasks, which would be the same on every occasion. And then we could build out this entire end-to-end stream of work, that we could just pass between each other. That's not how we need to work today to deal with the environment that we're working within. So when we look at complex knowledge work today. The skills that we need to build, and the capabilities we need to build within teams, and within individuals, so that they can be looking at how we work together. How do we understand the flow of work through to our teams, the teams we interact with, the conversations that we're having? Those dynamics across the organization, understanding all of that requires a very different way of encouraging learning in the organization.

[00:05:36] Dave Sharrock: What I find interesting is, and I always fall back onto sports metaphors, but I'm going to use a slightly different metaphor here. But whenever we're talking about these agile teams, whether you use sports or in this case, something like the SAS, right. Specialist forces within the military. Anybody who looks at, whether it's the Marines, or the SAS, or any of these exceptional units that get pulled together. The skills are a given. We know that people don't get into those teams if they don't have the skills. And this is the thing that, when you're talking about fungible resources, what you're really talking about out is skillsets. And being able to pull skillsets in and out, and have them land on their feet and find things. And as long as you're only dealing with skills, then we can argue which skills are truly fungible and which ones aren't. But it's a very process oriented perspective. But what's interesting is you keep moving up towards high performing teams. And if I take the SAS as an example. Number 1: Make sure your skills are high. So if you take any learning from it, you invest in skills learning. You make sure people have the opportunity and the skills learning opportunities. But number two, is they then run through scenario, after scenario, after scenario, problem set, after problem set, after problem set, to find out how they work together. And in the case of the SAS they're typically four person teams. And those four person teams are continually training over and over again, repeating the problem until they learn how to work together. And the skill that they're learning there is not how to do something in a predictable way, but it's how to respond to the uncertainties. Respond to the surprises, that we know we're going to happen. So now if I take that analogy, and go back to an agile team, we definitely need skills. We need to up-skill in terms of the basic what my job is. If I'm a front end developer, or I'm an architect, or a database engineer, I need the highest skills possible. But the magic sauce that comes in, is how that team solves problems. And they need to go through that scenario based learning, experiential based learning, over and over again. And that raises two very quick questions that come out of that. One is: don't break the team up. Why would you do that? You lose so much. The moment you break that team up, now all of that experiential learning, about how the team can rely on one another, is all of a sudden gone up in smoke, it's disappeared. And then the second part is: how do you give them small, safe scenarios, to work on repeatedly, so that they can learn and figure out how to solve the unknowns. How to solve the surprises that they are going to find.

[00:08:09] Peter Maddison: And we've seen a number of mechanisms, or at least I have come into organizations to try and encourage this type of learning. Did a fantastic job with dojos. Where you can come out of the workplace into a safe environment to completely learn and practice new skills. New ways of learning, new ways of doing things. So that you can then take those, and apply them back into your work and the things that you're doing. So these ideas, concepts of how do we create these environments where we can safely learn, and have these experiential learning experiences. And learn how to apply these new skills in the context of particular active problems that we have in front of us. So this is a very valuable way of going through and starting to help teams be able to learn and develop these.

[00:08:56] There's a second part of this, where the gentleman was asking, what resources are available? Where can we go find resources that can help teams? I had several that came to mind, but like to hear your thoughts on this.

[00:09:09] Dave Sharrock: As you're looking at something like this, the two things that come to mind. One is: you do need to have a skills audit. Whether you use the skills matrix as an exercise with the team, or you're looking at the problem that you're trying to solve and figuring out what the skills are that you need to go and learn. Something that any agile team looking at product delivery, or some sort of process work, they're going to need skills around value stream mapping. They're going to need skills around process definition, and things like this. But context is everything. So understanding that skills audit piece is an important part, but most organizations are actually really well set up for that. They're good at those sorts of things. Either they've put, senior experienced individuals into leadership roles who can then oversee these things. Or, bring project managers in, or something like this, where they've got that expertise.

[00:09:54] What's more interesting as the experiential learning piece. As you were mentioning, there are a handful of ways that you can do it, sort of off-piste. Away from where the work is. The Walmart example that you're mentioning. Things like hackathons and dojos, these are all " let's go to one side and not touch our lifeblood work that we're doing, and work in a safe environment". The interesting change or challenge that we've seen work really, really well when you get it right, is creating that safety in the work environment. And when you look at something like sprinting and agile teams, and I'm not going to get into whether that whatever the framework is, but short iterations of work. Well, they're making small changes and they're validating those changes, and they're learning from them. And they're in a process where they can continually get better. And they're getting rapid feedback. If you've got that right organization around it, where there is safety in making mistakes, there is an ability to learn because they chase one particular architecture and then they suddenly find out that has some weaknesses that get exposed. So they have to back it out and do something else. And these things are not taken as mistakes, or failures on something negative. But are actually taken as, this is part of the journey. You're going to run into cul-de-sacs and go thinking, "This is definitely the way it's going to work". Then you're going to find something out that means you have to back it out and go somewhere else. Right. And I think those are really interesting, because if you can get that into the DNA of the organization. This is what we've certainly seen is, teams Excel in that! But you also end up with teams that are so far ahead of their peers in some ways, because the learning happens when you're not there. The learning happens very, very rapidly and they can build that up really, really quickly.

[00:11:34] Peter Maddison: Yeah. I a hundred percent agree. I mean, I've seen that in many instances. Wherever you can set people up to be able to try these things, immediately. It's why, from a DevOps perspective, we bring it in and say, "Okay, I want you to push something into production, just something small. What will that take? By the end of the day, I want you to be able to have something in production". And you can usually tell by the amount of fear in people's eyes, just how much of a devastating idea this might possibly be. I've got to get all these approvals to do this. I would need this, and this, and this, and this. But just even understanding what will this take, will give you an awful lot of learning. So now we have an understanding of where we want to be, but why is it was so afraid of doing this, and what is it that's standing in our way. Now, if we start to look at what is it we would need in order to feel more comfortable with doing this. What are the things that we can do to ensure that this is allowable within the organization? What are the safety nets we can put into place? How can we be comfortable with this idea that it's going to be okay. And helping people through that journey for exactly the reason you say. Because once you can get that set up within the teams, and teams can do that on their own, on a continual basis, they will run with it and they will go much faster than you could ever imagine. And that in of itself is something that is wonderful to see.

[00:12:47] Dave Sharrock: Yeah. Whenever we're having this conversation, at some point, this conversation is normally going to come up. And I use the phrase specifically about capability building. Because capability building is different to skills building or, resource upskilling, right. And capability building has these three elements that come in, which I think we've been talking about really well. So this might frame what we're looking at.

[00:13:11] One of them is, there's clearly the skills. And ignoring the skills is a bad move. You would need to build in an understanding of what skills we need and how we can raise the bar. But that's typically done by individuals. There are courses out there, go get them. Or it's a mentoring piece, or something along those lines. Working alongside a senior engineer and seeing how they approach things, and asking questions. I think we're pretty familiar with that skills building piece.

[00:13:39] The working together as a team, whether we call it problem-based learning, or project-based learning, or it's scenarios, or experiential learning, but that working together, that skill set is the soft skills. So where do you go for the resources around that? Well, there's a ton of books around team building and culture code that we've talked about in previous podcasts. So there's, there are many books out there that talk about how to create that environment, how to encourage teams to work together. What I find interesting is agile does that really well. When it's applied well. When it's not stripped of any real meaning, and there's a standup at the beginning of the month, and that's it, I'm not talking about that kind of agile. But when you really get a team working together, and they are encouraged to work together as a team, that sort of experiential learning happens really clearly.

[00:14:30] And then the third thing is, just keeping the team together. Because recognizing the container that has the skills, and now has that capability to work together, is the team. Not the individual. So as an organization, when we understand that we're building teams, we're not building individuals, that changes a lot of the organizational decisions that we start making.

[00:14:53] Peter Maddison: The one thing I would add to all of that is, and that this comes nicely out of flow engineering, start with the end in mind. Focus on the outcomes. Why are we seeing the need to develop this capability? What is the outcome we're looking for? How are we expecting the world to look differently? If I look out three months, six months from now, how will it look? What am I trying to achieve? So that I can have this understanding that I'm focusing on things for the right reasons, and not just because it's the flavour of the month, or the thing that I read in the latest article on LinkedIn. Or something along those lines. Versus, "Hey, I've got a vision of where I want to be. In order to achieve that, it here's some experiments I want to run". How can I start to create those capabilities to do that?

[00:15:35] Dave Sharrock: I love that! That's the ribbon that ties everything together. Because when you talk about holding those teams together, the best organizations, the one I point people out to say, you need to go see how these guys work, their teams have a purpose. Number one. And when that purpose changes, the teams change. Because you'll need different capabilities, you need different skills. So that the teams are persistent around a given purpose, or outcome. As those outcomes shift and change, those teams will shift and change, driven by the outcome. Not driven by funding. Not driven by different resource managers wanting to move things around. But they're driven by the need. The purpose of that team. Brilliant point!

[00:16:21] Peter Maddison: Awesome. And with that, I think we're right about at time. So it is wonderful chatting as always Dave. And if anyone wants to reach out to us, they can at feedbackatdefinitelymaybeagile.com and I'll look forward to next time.

[00:16:33] Dave Sharrock: Good to talk again.