We often hear, “I wish my leaders really understood how to support our teams and how to create an environment where we can thrive.”
In this episode, we share the handful of things we think leaders need to know if they want to help their Agile teams get the best results.
Leaders have a huge impact on whether Agile teams in their organization are going to be successful or not. In this episode, Peter and Richard share the most important things leaders need to know if they want to help their Agile teams get the best results.
Learn More
We love to support leaders who want to make this happen in their organization. Visit humanizingwork.com/contact to schedule a time with us to discuss your unique challenges and how Humanizing Work can increase your leverage.
Episode transcription
Peter Green
Welcome to the Humanizing Work Show!
Leaders have a huge impact on whether Agile teams in their organizations are going to be successful or not. And when we talk with team members and coaches, we often hear things like, “I wish my leaders really understood how to support our teams and how to create an environment where we can thrive.”
Richard Lawrence
In this episode, we’re going to share the handful of things we think leaders need to know if they want to help their Agile teams get the best results. Some of these may be reminders for you, some may be a new angle on something familiar, some may be a whole new idea that unlocks new possibilities for you. Let us know in the comments on YouTube or social media what resonates with you for your particular context.
Peter
Before we get into that, though…
This show is a free resource sponsored by the Humanizing Work company.
Humanizing Work exists to make work more fit for humans and humans more capable of doing great work. To that end, we do training and coaching in three areas:
- We help leaders lead empowered teams and individuals more effectively
- We help product people turn their ideas into good experiments, visions, and backlogs
- We help teams collaborate better to produce meaningful outcomes on complex work
Richard
If you or your organization would benefit from better leadership, better product management, or better collaboration, and if you find our vision for human-centric work compelling, we have capacity to take on a few new clients right now. Visit the contact page on humanizingwork.com and schedule a conversation with us.
Based on our experience with many hundreds of teams in many dozens of organizations across a wide range of domains, here are the key things a leader needs to know if they want their Agile teams to thrive…
First off, be aware that product development is complex work. We’re creating new things for humans, based on educated guesses –hypotheses–about how people will behave in the future. There’s room for research and planning, for sure but the nature of complex work is such that we’re going to learn as we go. We discover more about the problem and about the solution as we try to solve it.
Peter
This means there’s going to be some give and take when it comes to longer-term planning. The further out you plan, the larger the margin of error. And committing to plans too far out actually reduces your ability to succeed with the most valuable things because those will often be the most complex things.
That’s not to say “We’re Agile, we don’t plan” holds any water. There are Agile ways to do strategy and roadmaps. Just be aware that the traditional ways tend to be poorly suited to complexity.
The second thing to be aware of, is that the Agile movement is, essentially, a response to this reality. If the work is complex, it makes sense to approach it in an iterative, collaborative way.
Richard
I love the way the values in the Agile Manifesto are modeled. Instead of just a list of good things, as is often the case for a list of values. Like, a company’s values; like, “We value quality” or “We value integrity.” In the Agile Manifesto, it’s a set of tradeoffs between two good things. They’re all things that could be valuable in the right context. But, it says, essentially, in order to optimize for complex problem solving, we value the good things on the left enough to be willing to give up or get worse at the good things on the right.
Let’s talk for a moment about where this Agile Manifesto came from—and with it the term “Agile Software Development,” which is often just shortened to “Agile” used as a noun and frequently capitalized…
Methods like Scrum and Extreme Programming (sometimes called XP) sprang up in the 80s and 90s as a response to increasing complexity in the field of software development. Traditional project management wasn’t working for a lot of software teams because a complex reality was breaking their plans. So, they emerged these lightweight, iterative methods as an alternative.
Peter
Then, in 2001, the proponents of Scrum and XP and a handful of other methods got together for a weekend to see what they had in common. Maybe they could align a bit more.
It turns out that they couldn’t agree or align on a single method, but they found they had values, and eventually, principles in common. And, during those two days, they gave the methods like theirs a shared name: “Agile Software Development.”
So, there is no one Agile method. It’s more of an umbrella over the various methods that share those values and principles.
We want to point out that one popular method, these days, SAFe, the so-called Scaled Agile Framework, was created much later as a way to package up various Agile practices and methods with some extra process and formality to make it palatable to organizations that saw themselves as too big—and maybe too serious—for the more team-focused Agile approaches.
Richard
In some cases, SAFe probably has provided a way for people to experience some of the Agile values and principles on legitimately very large initiatives. [Richard repeats:] In some cases, SAFe probably has provided a way for people to experience some of the Agile values and principles on legitimately very large initiatives. In many cases, SAFe turns out to be way too much process and leads to people using a lot of the words without really experiencing the intended benefit. That could be a whole episode of its own, probably, but for this one, I think it’s good for leaders to understand how SAFe fits into the overall history of the Agile movement.
Changing gears, another thing leaders with Agile teams should have a good handle on is the nature of self-organization. You’ll hear things like, “Agile teams are self-organizing.” But what does that mean?
Peter
In this context, self-organizing doesn’t mean just do whatever you want. Work on whatever you choose. Organize your work however you please. Communicate out however you feel like. That’s a recipe for chaos and waste.
Self-organizing in this context means, within a reasonable set of constraints, a team has the freedom to choose how to approach their work. No one is assigning tasks to them. They don’t have every detail of their internal process dictated from outside the team.
This increases engagement on the team—people are motivated when they feel like they have the right amount of autonomy in their work. And it makes the approach to the work more likely to fit the team’s context well.
Richard
But a big challenge for a leader with self-organizing teams is to set the right set of constraints. The two big areas we encourage leaders to pay attention to are:
- Direction: Point the team in the right direction. Give them a compelling vision for their work. Give them a clear definition of success. Give them a strong connection to their customer. And then leave lots of room for them to figure out how to solve the customer’s problem.
- Coordination: Establish standards in places where a team needs to coordinate with other teams or with other departments. Standardize at those boundaries so it’s easy to align and communicate. But leave lots of room for local variation within teams where it doesn’t really affect anything else. For example, two Scrum teams working together on the same product backlog should standardize their sprint length. They need to coordinate planning and review. But another Scrum team in that same organization working on a different backlog should probably be free to choose a different sprint length that fits their own work better.
Peter
Now, we’ve mentioned teams several times in this episode so far, and let’s talk a little bit about the importance of team structure. Team structure makes a huge difference in whether individuals, teams, and, really, everybody involved will experience any meaningful value from an Agile approach.
Team structure is a complex problem and it’s one we spend a lot of our time helping leaders work through, but the essential idea for leaders to know is this: As much as possible, teams should be fully cross-functional such that they have all the skills required to complete complex and valuable work without having to wait on outside teams and individuals. The more you build teams around some core complexity, the easier it is for them to collaborate.
A good way to test this is to ask some people close to the work in your organization how many teams have to touch a typical feature between idea and production and how long it takes. The more handoffs and the longer the cycle time, the more likely you’ve got a less than optimal team structure.
We often encounter developers who are frustrated and cynical about Agile, at least in their organization. A broken team structure is a common root cause because it can lead to what feels like lots of process (especially meetings) that doesn’t seem to support autonomy, mastery, and purpose.
Richard
In many orgs, Agile can just seem to bring a lot of new words and new meetings but not better outcomes for people. And that comes from either missing the structural things like good team design or applying too much process or process that doesn’t clearly produce a desirable outcome.
Our favorite way to get ahead of this when we can is to start an Agile transformation with a single team pilot. Get the structure right for that one team. Apply just enough process and leave room for self-organization. And then let the team experiment to find what works for them to be successful.
By the way, successful here means not just a better work experience for the team, as important as that is, but better results for their stakeholders and customers.
Once you’ve genuinely proven an Agile approach in one place, you can start scaling and adapting from there. That works so much better than trying to change everything at once in place, with all your existing initiatives running, which often fails to produce even a single thriving team.
Of course, you can’t always get ahead of the Agile cynicism. You might be in the middle of it right now. In that case, the best move is to incrementally fix things. Sometimes that looks like a sort of pilot in place, getting conditions sorted out for one team, and proving what can work, and scaling from there.
Working in an iterative, collaborative way requires a new set of skills. If you want to see good results, you can’t just declare “we’re Agile now.”
Richard
Right; and just to name two key skills that most orgs don’t have by accident:
One is slicing work into increments of value at various levels of detail. I spend a lot of time working with, not just project owners, but whole teams around this, because it’s such a key skill that makes so many other things work on Agile teams.
And then, a second one is actually working together on an increment of value—how do you structure the work? How do you actually work together on a thing? What do you do together? what do you do in parallel?
It’s funny–we have a structured first two weeks for a team that we call our Team Launch Sequence. It helps a team learn to actually collaborate on their work. And, more than once, a participant on a team on about day 4 of Team Launch Sequence has said something like: “Oh, I get it now, this is what collaboration feels like.” They’ve never really done it before. And that experience wouldn’t have happened if the team had just been told to go start collaborating. They had to learn to do it.
Peter
So, it’s important for leaders to make these learning opportunities available for teams. That can be live training, it could be self-guided training, internal or external coaching, even access to good books. And it’s critical to make sure there’s enough capacity for teams to actually do the training. If they’re overcommitted, there’s no time for skill development.
Finally, the last thing leaders need to know if they want to help their Agile teams succeed is that leaders’ highest-value contribution isn’t going to be in the details of the work. The more you’re planning, directing, or otherwise managing the work, the less you’re contributing in a way you’re uniquely positioned to contribute. If you want your team to be empowered and set free to do the right thing, you really have 3 jobs as a leader:
Richard
Number 1, create clarity. Make sure your teams know where they’re going and what success looks like. Now, this might be someone’s job, like a product manager or product owner. But the more senior a leader you are, the more important it is that you’re ensuring this clarity is there for the teams somehow.
Peter
Job number 2 is to increase capability. This includes training, staffing, budgeting—all the stuff around making sure your teams have the resources they need to succeed.
Richard
And job number 3 is improving the system. Look for ways to help work flow more smoothly. Not so much in the details—that’s the teams’ own responsibility unless there’s some impediment they need you to remove. But more around the larger workflows and systems, the career paths; compensation, team structures, and the like.
Peter
Create clarity, increase capability, improve the system. Those are the 3 jobs of a leader when you have self-organizing, empowered teams.
So, to summarize, leaders who want their Agile teams to be successful need to:
- Be aware that product development work is complex
Richard
- Understand that an Agile approach is fundamentally about making the tradeoffs to optimize for complex problem solving
Peter
- Set the right constraints to enable self-organization on teams
Richard
- Shape your team structure so complexity is located inside teams, making collaboration as easy as it can be
Peter
- Start with a pilot and scale, if you can, so you avoid the cynicism engendered by process, meetings, and language without any meaningful results
Richard
- Get your teams the skills they need
Peter
- And finally, focus on your 3 jobs: creating clarity, increasing capability, and improving the system
Richard
We love to support leaders who want to make this happen in their organization. Visit humanizingwork.com/contact to schedule a time with us to discuss your unique challenges and how Humanizing Work can increase your leverage.
Peter
Thanks for tuning in!
Last updated