Over the past few months I’ve been coaching my clients who are in the early stages of adopting agile approaches for software. Most of them are adopting Scrum, but a few are adopting Kanban.

Universally, one of their complaints is that their teams aren’t “stepping up” to the

• Empowerment
• Responsibility
• Accountability
• Passion & Energy
• Creativity

That is implied as part of the culture of self-directed, agile teams.

To say that they are disappointed is an understatement. And these comments are coming from all levels of the client leadership teams.

But it may not be the teams fault…

But I have a shock for these folks. It may not be the teams that are the problem in these situations. It may be the leadership team that is still standing in the way of the team’s self-organization.

How you might ask?

Well lately I’ve been referring to the problem as – not giving the team enough SPACE, space to grow, to become autonomous, to become self-directed.

You see self-direction doesn’t just happen because you adopt Scrum, Kanban, or another agile variant, or because you say ‘Agile’ twenty times to your teams. It needs a fertile space to grow. It needs to be watered and fertilized. It needs an honest environment.

In far too many cases, this is simply not happening.

So what are the aspects of Self-Directed SPACE? Let’s explore a few that come to mind…

Managers – stop “managing”

The first element is for your managers to stop, well, “managing”. In other words, stop trying to tell people what to do, estimating their work for them, or solving their problems for them.

I usually share the notion of “push” vs. “pull” to managers who are making the transition to agile. You want to resist “pushing” yourself into the teams at all cost –the less frequently the better. However, IF the teams ask you for help, or otherwise “pull you into” the team, then indeed assist your team.

Push reduces their autonomy, while pull supports it.

Be careful what you measure

Measures often drive behavior. For example, if you measure code complete milestones within sprints, then your emphasizing development-done rather than a whole-team done focus. So don’t be shocked if your team doesn’t jell as a good agile team. It’s probably because of the way you’re measuring or incenting them.

I remember once doing an agile training activity for a Ukrainian team. I spent a couple of hours emphasizing the mindset of agility, including the collaborative aspects. Near the end, one young man raised his hand and said:

But Bob, we are not incented to work together. Our compensation model and bonus structure is solely focused on individual performance. I don’t care about my team member’s performance or helping them, I only care about myself.

At that point, I respectively closed the class…

Team Leads

I’ve run into quite a few organizations of late that have the notion of “Team Leads” within their agile teams. Quite often they’re also serving as ScrumMasters. In general, I’ve found that anytime a team member is declared a “lead” they’ll have a requisite of “followers”. That is, the self-directed nature of the team succumbs to the leader. Not always, but often.

If I can, I try not to create unnecessary hierarchies within agile teams. I want the leadership to emerge from each team member as appropriate and as the situations dictate. You see, in a self-directed team, anyone and everyone can and should lead as appropriate.

Language

The language you use becomes very important. Do you reference developers, as “development” and do you reference testers as “test”? Or do you reference your teams as cross-functional, “teams”?

I try to change my language to deemphasize organizational silos and instead leverage “team language” whenever possible. And I encourage all leaders to do the same.

I’ve found the language we use (verbal, tone, body) sets an incredibly important “tone” with organizations. And the emphasis from an agile point of view should be on team.

Team organization

One of the craziest ways to “build” an agile team is to connect a disparate group of remote folks from around the world and then “call them” a team.

I often get challenged that “remote agile teams” simply don’t work. But, when I explore the dynamics that the challenger is talking about, I find the resulting organization structure to be, can I say this, insane.

Try to build your teams as sensibly as possible. Co-locate as many as you can, have as few time zones between them as you can, and support them with collaborative tooling.

And, when you form your teams, pay the price to get them all in one place to kick things off.

ScrumMasters

I don’t know what it is about today’s organizations, but I encounter so many who aren’t willing to “pay for” ScrumMasters – or at least experienced, it’s my job, ScrumMasters.

Why?

Often it’s because they don’t understand the role. They trivialize it and minimize the need for it. But Scrum clearly states that solid teams include the ScrumMaster. It’s an important part of a Scrum team and it’s not a side-effort. It’s a full-time role or job within the team.

I also believe it’s a crucial one. Sure, perhaps not the simpler parts of the role – like impediment remover. But the parts that include coaching the team and guiding them towards continuous improvement, effective collaboration, and high-quality delivery.

Give your team space by providing them with a focused and capable ScrumMaster – then support the ScrumMaster with ongoing training, coaching, and mentoring.

Failure and Discovery

I often talk to leaders making the transition to agile about enabling or empowering their teams to try new approaches and to possibly support…failure.

The room usually goes quiet and everyone gives me a look like I’m trying to sell them a bridge in Manhattan. There’s almost a universal reaction that – Bob, we don’t fail around here, so please don’t mention the ‘F’-word.

The reality is that failure is a part of learning and a part of success. It lies at the core of innovation and creativity. And as leaders we need to create or encourage an environment of risk-taking, learning, and exploration within our teams. That is, if we want them to grow and learn and become an outstanding team.

We also need to trust their intentions related to this journey.

Let the team solve their own challenges

I liken many managers to birds circling their teams, ready at a moments notice to “swoop in” and save the day.

A few years ago, I worked with a manager who I’ll call Bob. Bob was an incredibly experienced and knowledgeable manager. His intentions were also good, that is, all he wanted to do is help his teams and our business to succeed.

When his teams struggled a bit or encountered an obstacle, in a few seconds, Bob was there to help them. He would leverage his vast experienced and essentially “tell them” how to handle the situation.

The ScrumMasters on Bob’s teams has a term for this. They would tell me that Bob “swooped in” today. In fact, some of them kept a swoop-ometer to keep track of the number of swoops.

As I coached Bob, you see he reported to me, I told him that this behavior was detrimental to the teams becoming independent and self-directed. That he was inadvertently taking things on himself rather than allowing the team to face and solve their own challenges.

In other words, I told him to…stop it!

Wrapping Up

For you Star Trek fans outer space was always – The Final Frontier. I actually beg to differ. I now think that team space is the final frontier.

It may be just as hard (or harder) to achieve than leaving earths orbit on another adventure. Why, because traditional management techniques and approaches are a strong part of our DNA and incredibly hard to shift away from.

But if your goal is to foster a sustainable, empowered, trusted, and engaged self-directed team, then shift you must.

Engage #1

Stay agile my friends,

Bob.