Dave: And we're back. My name's Dave. I'm joined by Jags and Paddy, and in this video we're going to talk really about collaboration and self-organising teams.

And this is a great one because this kind of leads into that jargon busting and that discussion around key agile terminology.

This one is specifically around self-organising teams because if I am sitting in management in a traditional organisation, the idea that I would have a team that would self-organise and figure out what it's going to do does not sound at all appealing - that sounds like a recipe for disaster.

So why does agile and so many agile frameworks really push this idea that self-organising teams are central to success?

Jags: I think the key thing here is about having knowledgeable workers. Peter Ducker described knowledgeable workers as individuals who are better informed about what must be done, more than their leaders.

So, we have knowledgeable workers and what we say about these knowledgeable workers, they are self-organising.

They're determined about what order they're going to do work in and how they're going to accomplish their work without being told what to do, like your traditional leaders who tell you, this is what you must do, here’s a task list, I will review what you've done and I will approve or reject your work.

Dave: So there's a whole change in in mindset from about the whole organisation that allows us to facilitate such things as self-organising teams. It's no longer about leadership, micromanaging, it's about leadership leading in other ways.

Jags: Well, leaders need to think differently, leadership’s not about directing, it’s about developing people.

Dave: Wasn't it, wasn't it Steve Jobs, though, who had some kind of quote about people and experts, I don't know if you guys know that quote well?

Paddy: I’m trying to remember it. So we employ people because of their expertise.

Dave: Yeah.

Paddy: We don't employ them to tell them what to do.

Dave: Yeah, exactly. It was that. It was definitely along those lines.

Jags: Paddy, what did Daniel Pink say?

Paddy: Absolutely. So Daniel Pink sort of has done a fair amount of research into this to say, well, what motivates us as individuals within an organisation? Is it money?

And what we often find is money is a great booster for some people, but it's a short term fix because as individuals once we've had that we become demotivated again.

So what do we do? Do we keep paying people more money and rewarding them in that way? Well, actually no. There's other elements that we should perhaps consider.

So things like autonomy, mastery and purpose are three of the key elements that Dan Pink mentions are really important for a team. Going back to the self-organising element and the leadership.

There is a notion of what we call servant leadership within Agile, so it's very much about, as a leader, I'm going to be the silent leader in the room, because the team have the knowledge and the answers amongst themselves, but what I will do is become a catalyst so I will help the team to discover the right answers without telling them what to do.

So servant leadership is another concept that's really important for agile leaders.

Jags: But around servant leadership you’ve got psychological safety. It's okay to make a mistake. We learn from it. Yeah, you don't come to work to make mistakes. You come to work to make a difference.

And what did David Marquette say about leadership? Did he talk about the individual teams and whether they’ve got the technical competence or whether they could develop the technical competence and whether they've got clarity about what the organisation is trying to achieve. And they’ve got psychological safety.

They want to make local decisions.

Dave: So in terms of David Marquette, I hope I'm saying his name correctly?

Paddy: It's actually David Marquette. The only reason I know that is because I did a podcast with David and he absolutely told me it's David Marquette.

Dave: You've actually met this person as well because he sounds like quite an impressive guy. As far as I understand, he was the commander of a nuclear submarine, the Santa Fe, if I'm correct, according to my notes.

So can you maybe just expand on that example a little bit more about the story of David Marquette and how his vision of leadership specifically relates to again this topic of self-organising teams?

Paddy: So, David Marquette, he had had a very sort of traditional style of leadership, so the US Navy had pretty much instilled this notion of command and control, because if you're going to command a nuclear submarine, you should be telling everybody what to do.

David Marquette was put into a position where he was given the command of a brand new submarine that was seen as one of the low, lowest performing submarines in the whole of the US Navy. And, in the book he talks about how it was a very scary situation for him because all of a sudden he was expected to turn the ship around in terms of the performance.

Now, what David Marquette did was he admitted that he didn't have all the answers, and he wasn't going to be there to tell everybody what to do.

The only decision he felt that he should keep hold of was whether or not to fire a nuclear missile, which he felt carried great responsibility, but pretty much every other decision he'd constantly look to the team to make those decisions or at least have a perspective on those decisions.

So rather than telling people what to do, he would invite the team to come up with suggestions and recommendations. So he took a very different approach to leadership in an environment that was traditionally seen as a command and control sort of environment, and the results were impressive.

They went from being the lowest performing nuclear submarine to one of the highest performing, but not only that, the amount of churn within the staff.

So year on year what they find is traditionally that submarine people would be quitting, they would quit after a year. But he had the highest retention rate across the whole team and the level of satisfaction as well amongst the people they were just a lot happier taking this approach.

Dave: So this vision of servant leadership, then, which is kind of what he's advocating for, it basically, to put it in the context of the self-organising teams then, you're saying that self-organising teams are about autonomy and responsibility, people owning their own work and working together to figure out how the best way they should be working is done basically?

Jags: So you can imagine you've got this small group of people self-organising. The question is how are these teams formed in the first place? Does a random e-mail go out saying can I have some willing volunteers to be part of this team?

And this team on day one needs to figure out what must be done? Given that we will live in a VUCA world? Volatility, uncertainty, complexity, ambiguity. They don't have the answers on day one.

They have to figure out what the answers are. For this iterative, incremental delivery. And guess what? They will make mistakes. So I need a group of people who can work in an environment of uncertainty. So, you know, these people are pretty special.

Paddy: What I often find really entertaining is The Apprentice. I don't know if you guys have ever watched The Apprentice?

Dave: Bits and bobs maybe at some point.

Paddy: So it's a great example of where the teams are set up with the project manager, somebody who's going to lead the team and direct the team, because now everybody should do as a project manager says.

But what happens in nearly every episode? Does everybody follow the project manager, right down to the letter?

Dave: No.

Jags: Absolutely not.

Paddy: No, right. And there's a reason for that, because the project manager can't be in all of the different locations as they're doing these tasks.

And what ends up happening is people start to make their own decisions based on the information they have.

And often, if there is then failure in the task, we come back to the boardroom and there's a big blame game and the project manager feels that everybody should have followed their direction when actually that probably wasn't the right answer.

Those individuals, if they had been equipped with this notion of self organisation, been given that autonomy and that purpose, they would have perhaps made the right decisions if they knew everyone else was supporting them.

Jags: And this self-organising team, they would determine how they're going to communicate with one another, how they want to work. And how they respond to feedback and having to make adjustments on a day-to-day basis.

Dave: So I think this does lead actually quite nicely on to a discussion, a more in depth discussion at any rate, about incremental and iterative delivery, right?

I've got here a question around the Stacey matrix, I suppose because it's a great way to visualise the state of that VUCA world in many ways, but also from a more traditional project management perspective.

So do you want to tell us a little bit more about what that Stacey matrix is all about and how it fits into this conversation?

Jags: When I talk about the Stacey matrix, I talk about what type of noise your projects are making, the product solutions that you're developing. The reality is, our requirements are completely changing.

The type of projects we're running nowadays, they're not set in stone. And the solution technology to deliver those requirements are at best finger in the air, we've got some vague ideas.

So what the Stacey matrix describes is what type of noise is your project making. Either simple, complicated, complex, or chaos or anarchy?

And what we tend to find is a lot of our projects now complex, where there's more unknowns than knowns. And the way we discover unknowns is through incremental delivery.

And through incremental delivery, we can test our assumptions, get feedback from our stakeholders. That way we could spend less money and less time on doing the wrong things.

Therefore, we're more customer centric and value driven. So Agile works really well in this complex environment. We say agile is an empirical process, a process of experimentation, learning.

Dave: And would yourself Paddy, have you maybe got an example of any organisation you might have worked in before where you've seen like great examples of the kind of simple or even complicated problems that people having to deal with versus complex problems, and how different teams.

Because I think there probably is a space where there are just simple problems that people can deal with in straightforward ways. So we don't always have to be agile for every single kind of problem we need to deal with, right? Or am I wrong about that?

Paddy: No, that's a great question. Often I do get asked the question when should we use the more waterfall approach versus the agile approach and my personal perspective is we should all have the agile mindset regardless of which approach we take because being able to respond to change even in a waterfall environment, I think it's really powerful.

It's a really key skill set to be able to have. However, there are certain projects that do lend themselves well to a more phased approach. And those projects for me are for example working within banking.

Recently I spent the last 6 1/2 years within a large global bank and we were going through a large transformation where we were replacing our HR system, the core application that runs a lot of our HR function.

And what's really interesting is as a group my team, we were offering agile coaches to different projects within the organisation to help support them. This was the only project that I can ever recall that turned us away.

And they said no, thank you, we're good. We want to use a more phased approach and we don't feel having an agile coach is going to really help us.

And it was a great example of where I wouldn't say it’s a simple programme by any means, I mean changing your HR sort of core platform is a really complex thing to do, but in terms of the knowns, there were a lot more knowns within that particular programme because the vendor that was helping us, they've done this hundreds of times before with many different organisations.

So they had very mature processes. They had been through this process many, many times before and actually what they just needed was time just to get it done. And so it was a great example of where they didn't need to iterate and they didn't need to produce and deliver something every three to four weeks so that people can give them feedback.

Jags: But that's not to say they didn't involve stakeholders throughout the entire journey.

Paddy: Absolutely.

Jags: People have a misconception that waterfall is, you know, we deal with stakeholders upfront and I'll speak to them sometime in the future. Actually we do.

Paddy: Yeah, no, absolutely. And so it's absolutely about involving the right people at the right time. But in terms of when do people start using, when do they start using this product.

In some cases it didn't make sense for us to be using it so quickly because we wanted to get things right. So in those environments where I think the needs are well understood.

We also have a good grasp of how we're going to deliver the product, taking a phased approach isn't a bad thing, but there's not many of those examples and that's the key I think, in today's world is there are very few of those examples that organisations can rely on just because things are changing all of the time.

Dave: So more and more actually we're finding that projects and programmes, portfolios tend to fit into that complex zone, even all the way up into anarchy, maybe, right, where we need to be able to adapt, respond to change, work with our customers and that's where that agile mindset comes in.

Jags: We’ll what we’re hoping for, it may start off in anarchy, but through stakeholder engagement, incremental delivery, if you get feedback, it becomes complex and complicated and then it becomes simple, eventually, as we get to know the project really well.

Dave: That's the dream.

Self-Organising Teams and Collaboration

SELF PACED PLATFORM

TRAINING CONTENT

JOB ROLE PATHS

CERTIFICATIONS