Episode 17 – Motivating Agile teams
/
RSS Feed
Scientific Management sees workers as inherently unmotivated. Given an option the worker will avoid or minimise work. This belief helps to drive the separation between workers who execute tasks (typically unwillingly) and managers who define the work (and enforce its completion). However, as Agile leaders, we reject this viewpoint. Instead we believe that motivation is primarily intrinsic, not extrinsic. Individuals are motivated by what they desire, not solely by reward or punishment. Teams can use self-management to most effectively deliver business value. Indeed they can develop to the level that Takeuchi and Nonaka refer to as “Self-transcendence”.
This podcast is AI-generated based on material from the “Agile Plays” website and book.
Transcript
Welcome back, everybody. We're diving into a topic that I know is near and dear to all of us leading teams. It's that age old challenge of keeping our teams, especially our agile teams, motivated and really performing at their best. And you know what's interesting? I think even when we try to do our best, a lot of leaders still kinda fall back into those old habits.
Right? They're looking at carrots and sticks. Yeah. The classic reward and punishment system. But when it comes to agile teams, you know, it really doesn't work.
It seems like be the opposite. You'd think with agile teams where there is so much emphasis on empowerment and self management that those kind of external motivators would be even less effective. Absolutely. And this is where Dan Pink's work comes in. You know his model, Autonomy, mastery, purpose.
Yeah. I've heard of it. It's a classic at this point, I think. It's a classic for a reason. It really gives us a framework to understand what truly drives people, especially in this context.
Okay. So let's break it down. We've got autonomy, mastery, and purpose. Yeah. So autonomy, I get that.
You know, giving people the freedom to make their own decisions about how they work. But how does that translate to a real agile team setting? What does that actually look like? Imagine you have a team. Right?
And they're working on the new feature. If they have true autonomy, they get to decide how they approach the problem. So not just what tasks they pick up, but how they actually do the work? Exactly. They choose the tools, you know, how they structure their day even.
Wow. Okay. So it's about, like, deep ownership, not just doing the work, but really owning the how. Right. And then you add mastery to that.
So you're giving people opportunities to learn, to grow, to get better at what they do. So, like, encouraging them to dive deep into a new programming language or maybe a a new testing framework. Exactly. You know, it's like we talk about technical debt. Well, there's also this concept of, like, personal development debt.
Oh, that's interesting. Right. If you're not investing in growing your skills, that's gonna slow you down. I like that. Makes sense.
But what about purpose? I feel like that one's a little more, I don't know, abstract. It can be. But think about it this way. Purpose is about connecting the dots, helping your team see how their work, you know, how what they do every day, how it fits into the bigger picture.
So, like, how their code actually impacts the users, how it contributes to the company's goals. Exactly. You can't just throw user stories at people and expect them to be all jazzed up. You have to help them see the why behind it all. You got it.
And that's where leadership really comes in. We're talking about creating a whole environment, a culture even, where these things can thrive. Oh. Autonomy, mastery, purpose. That makes a lot of sense.
But, you know, from experience, I know that giving up control can be really tough for some leaders. Oh, I hear that all the time. Especially, you know, if they're used to that sort of command and control style. Yeah. How do you help those leaders, those managers who are so stuck in that mindset?
You know, it's a helpful model to think about. McGregor's theory x and theory y. Okay. Refresh my memory. What's that about again?
So theory x, it basically assumes that people are, you know, naturally lazy. Right. And they need to be, like, controlled and directed to get anything done. Okay. Yeah.
But then theory y, it flips that. Yeah. Theory y says people are actually motivated to grow. They want responsibility. They just need the right environment to flourish.
So theory y definitely seems to fit better with, you know, self management and the whole agile approach. Exactly. Because if you believe your team is just inherently lazy, then you're gonna try to control them. Right? Yeah.
And that just kills creativity. It kills motivation. It defeats the purpose of being agile. So you have to start with that belief that your team is actually, you know, driven to do good work. Absolutely.
And, you know, there's this other really fascinating concept that builds on this. Oh. It's from Tokuchi and Nonaka. Remember them? Vaguely.
They wrote the new new product development game. They talk about self transcendence. Self transcendence. Okay. It's basically this idea that really high performing teams, they don't just manage themselves.
They also take ownership of their own continuous improvement. So they're not just doing the work. They're constantly trying to figure out how to do it better. Right. And they even, like, redefine what better even means.
Wow. That's that's pretty impressive. Yeah. How do you even foster that kind of mindset, you know, in a team? It starts with creating a culture of psychological safety.
Okay. Where it's okay to experiment, to give feedback, to challenge the status quo. You have to celebrate learning, not just results. It's about removing that fear of making mistakes. Exactly.
It's like, what can we learn from this? How can we grow from this? And that's how you get real innovation. So we've talked about these big motivators, autonomy, mastery, purpose. But, you know, in the real world, we still have deadlines.
We have budgets. We have stakeholders breathing down our necks. Mhmm. How do you balance that need for control with this, you know, this idea of letting go and empowering teams? Yeah.
It's a tough one. Right? Like walking a tight rope. Totally. But I think a good principle is to focus on defining outcomes.
Okay. So instead of telling people exactly how to do things, you say, hey. We need to achieve this by this date. Figure out the best way to get there. So you're giving them that autonomy within a framework.
Right? Exactly. They still have to deliver, but they get to choose how they do it. Okay. That makes sense.
But what about when things go wrong? You know, inevitably, in any project, things go wrong. In a self managing team, who takes the hit? That's where you need to shift to this idea of collective accountability. It's not about pointing fingers and blaming individuals.
It's about the team as a whole owning both the successes and the failures. So celebrate together when things go well and work through the challenges together when they don't. Exactly. And that builds trust. It encourages open communication, which are essential for any high performing team, especially an agile one.
This is all really eye opening. So it sounds like creating that motivating environment, it goes way beyond just picking the right agile tools or the right methodology. For sure. It's about building this deeper culture. It is.
It's about trust. It's about empowerment. It's about continuous learning. So for leaders who are, you know, just starting to dip their toes into agile or maybe struggling with motivation on their teams, what are some concrete things, some action steps they could take? What would you recommend?
Well, there's actually a lot of practical things you can do, and that's what we're gonna dive into next. Alright. So let's get tactical. What can leaders actually do to boost motivation on their teams? Well, one way to really cultivate autonomy is to involve the team in goal setting, you know, and even in choosing how they're gonna work.
Oh, interesting. That almost sounds a little counterintuitive. Like, wouldn't setting goals be a manager's job? How does that give the team more autonomy? Well, when people feel like they have a voice, a say in what they're working towards, they naturally, they become more invested.
Right? They're not just told what to do. Right. So it's a collaborative effort. Exactly.
It becomes our goal, not your goal. Okay. I see how that can build ownership for sure. So what about mastery? You know, how can we, as leaders, help our team members actually get better at what they do?
One thing that I found really helpful is to encourage a growth mindset. A growth mindset. Okay. So framing challenges not as, like, setbacks or failures, but as opportunities to learn. So when a project hits a snag, it's not about getting discouraged.
It's about, like, what can we learn from this? Exactly. And that ties into, like, you know, failing fast, which is a big thing in agile. Experiment, make mistakes, but learn from them. Yeah.
Love that. It takes the pressure off too. It does. But we also have to be realistic. You know?
Learning takes time. It takes resources. Right. How do you balance that with, you know, deadlines, budgets? Well, you can build in time for skill development.
Right? Dedicate some time in your sprints for that. Maybe budget for training, conferences, or even create mentorship programs within the team. Those are all great ideas. Okay.
So we've got autonomy and mastery. Now let's tackle purpose. That one always feels a little, I don't know, fluffy sometimes. It can be. Yeah.
How do you make it real for people? I think transparency is huge. Share customer feedback with the team, even the negative stuff. Oh, interesting. Let them see the impact, both good and bad.
You know? That makes a lot of sense because it's easy to get so heads down in the work that you forget who you're even doing it for. Exactly. And don't forget to celebrate wins, big or small. Yeah.
Recognition is so important. It is. You know, acknowledge those wins and really highlight how their work contributes to that bigger mission. So painting that picture for them. Yeah.
Show them how their piece fits into the whole puzzle. Okay. So we've talked about these principles in general, but how do they apply to self managing teams? Because we've talked about those 2. Yeah.
Are self managing teams just automatically more motivated? Not necessarily. It's not a magic bullet. Right? You have to think about it.
With more autonomy comes more responsibility. Right. And if a team's already struggling, giving them more freedom might actually make things worse. Oh, I see. So it's kinda like giving someone a car when they don't know how to drive.
Exactly. So how do you set them up for success? Yeah. Good question. Clear expectations, shared understanding.
Everyone on the team needs to know what the goals are, their roles, how they'll be held accountable. So it's not just, like, throw them in the deep end and see if they swim. No. No. No.
It's more like giving them the compass and the map, but letting them choose the route. I like that analogy. Yeah. But what about when, you know, you got someone on the team who's just not pulling their weight? Like, doesn't that create resentment?
Oh, yeah. For sure. That's where communication comes in. Okay. Really encourage open and honest conversations within the team.
Give them the tools and skills to work through those conflicts. So they're not just managing the work. They're managing the relationships too. Exactly. And that can be tough, but the payoff can be huge.
This has been so helpful. I'm already starting to rethink how I approach motivation with my own team. But, you know, I have to admit, sometimes it feels like there's this disconnect between what the team finds motivating and what the organization seems to prioritize. Oh, yeah. That happens a lot.
How do you bridge that gap? It often comes down to metrics. You know? If the organization is all about speed, speed, speed, but the team values quality and learning. You're gonna have a clash.
You got it. Alright. So we're back, and I'm really curious to hear more about this whole metrics thing. It does seem like if the organization is, you know, measuring success one way and the team is motivated by something totally different, you're kinda setting yourself up for, for some problems. Yeah.
Yeah. It can be a recipe for disaster, you know, especially in agile where we're all about giving teams that ownership, that empowerment. So where do we even begin to fix that? Do we just scrap the old metrics and start from scratch? Not always.
Sometimes it's about looking at the metrics we already have, but with a fresh perspective. So take velocity for example. Okay. Yeah. Velocity, that's how much work a team gets done in a sprint.
Right? Right. Pretty standard metric in agile. Yeah. But it can be a problem, you know, if it's the only thing that matters because then you just end up focusing on speed, speed, speed.
And quality goes out the window. Exactly. And teams start cutting corners just to hit those numbers, and that's not good for anyone. Yeah. No one's happy in that situation.
Yeah. So how do we shift that? How do we either reframe velocity or, I don't know, come up with some new metrics that actually support, you know, autonomy, mastery, purpose? Okay. Let's think about autonomy first.
So instead of just looking at how much a team produces, what if we also measure how well they're self managing? Oh, interesting. Like, are they making decisions on their own? Are they resolving conflicts constructively? So it's not just about output.
It's about how they're working. Right. And for mastery, we can look at things like, how much skill development is happening? Is there knowledge sharing going on? Are they experimenting with new things?
So, like, how many new technologies did they try out this quarter? Did they do any cross training? Exactly. You're measuring growth, not just churning out features. Love it.
Now purpose, that one's a little trickier to quantify, but you can still measure its impact. Like, how well does the team understand the customer's needs? Oh. Are they talking to users? Are they taking that feedback and actually using it?
So it all ties back to transparency. Right? Yeah. Making sure that connection to the end user is there. Exactly.
So what we're talking about is having this, like, balanced scorecard. You know? It's not just about what the team is producing. It's how they're working, how they're growing. It's about the whole picture.
This is fantastic. I'm really starting to see how, you know, thinking differently about metrics can actually create a more a more motivating environment. It can. And the key is to keep refining, keep experimenting. You know, get feedback from the team, see what's working, what's not, and adjust as you go.
This has been such a great conversation. Thanks so much for sharing all of your insights with us. My pleasure. It's been fun. And to everyone listening, as you go out there and lead your agile teams, you know, keep in mind what we talked about today.
It's about creating a culture of trust, of collaboration, of continuous growth. Empower your teams, give them the tools they need to succeed, and make sure that the way you measure success actually reflects what truly matters. We hope you enjoy this deep dive, and we'll catch you next time for another fascinating discussion. Until then, happy agile ing.
Leave a Reply