My partner Josh Anderson and I just finished a on the topic of self-directed teams. One of our listeners asked us to share our thoughts on handling agile team members who simply wanted to be “told what to do”.

On the surface, this doesn’t seem like such a bad thing. In fact, I’ll bet these folks are bright, capable and work very hard. They’re also probably “good people”. So if there is an issue with this in agile teams, what is it? And why would it be a problem?

Command and Control

I think much of this pattern comes from our traditional management style of command and control. Where managers basically take high-level ownership of projects and teams and literally tell everyone what to do towards achieving project objectives.

What’s wrong with this style? Nothing if you want most of the thinking to be done by the manager and little by the team. But it often doesn’t engage the intellectual power of the team nor does it engender their engagement. It also doesn’t scale very well, as no manager can make better decisions than a team as a project (and organization) scales or becomes more and more complex.

Essence of Agility

The key problem I have is that this attitude flies in the face of the agile self-directed team. The teams, and their members, are not simply automatons. I want them to be engaged and thinking about the best ways to solve their customers challenges. I want them working together towards goals, rather than blindly following a plan. I want everyone to have a voice and “skin in the game” for their team.

The other challenge is that software projects are notoriously complex. Simply following directions or plans often doesn’t take into account the discovery that the team makes along their journey. Things change, obstacles are thrown in their path, and approaches that were thought to work, don’t.

In our Meta-Cast, Josh and I discussed the fact that agile teams truly have no place for a team member who simply “mails it in” and tells their team to tell them what to do. It truly an anti-pattern for what we’re trying to encourage when we build and coach our teams.

However, it often happens as individuals make the transition from a command-and-control style to a more collaborative, empowered, and self-directed style. Often it takes some time and “deprogramming” for them to make the transition and not everyone makes it.

Here are three recommendations for helping your teams move in this direction (pun intended)—

Transition Planning

A big part of an agile transition is planning the leadership coaching, training, and transformation necessary to guide entire teams through the transition. Often the middle leadership function receives little to no investment and this is a huge mistake.

As you can see in the annual agile adoption survey results, mid-level leadership roles can either be an important factor in guiding their teams towards an agile mindset OR they can be an incredible inhibitor. In fact, that latter is more the case as survey results show in critical failure factors in agile adoption.

Retrospectives

I think effective retrospectives are incredibly important in supporting team members during their transition. One key is focusing on the team in the retrospective. That is, I usually hold that retrospectives are a “management free zone” for the team. Why you might ask? So that the team feels more comfortable expressing themselves and getting the real issues and challenges on the table for sorting and resolution.

Often the presence of a manager will inhibit safety and openness within retrospectives. I’d rather “kick myself out” and generate better team engagement in their continuous improvement journey.

Roles & Responsibilities

Now I am a firm proponent of defining clear roles and responsibilities within agile teams. Why? Mostly because it’s unclear to many team members what the new expectations are within self-directed teams. Historically, they’ve become comfortable with what’s expected. But in an agile transformation, often things are quite different.

I’ve found that establishing a clear definition of the following roles:

• Scrum Master
• Product Owner
• Team
• Management

Focusing on the essence of each role and the interplay truly helps teams understand expectations as they move into agile. I remember when I was a coach at iContact, I would “dust off” our R&R slide deck about once a quarter. We would have enough new hires and the teams would begin to forget the basic “rules of engagement” and our behavior, trust and results would suffer. This was a nice way of reminding everyone of our expectations.

Wrapping Up

I hope that Josh and I aren’t too naïve in hoping that you can build solid agile teams that truly engage self-direction. We also hope you don’t translate this to a view that the “Inmates are Running the Asylum”. Self-direction does have rules of engagement and constraints. But overall, the team is accountable for their results.

And trust us, there is no more exciting place to be than coaching and leading a truly self-directed agile team. It rocks!

Stay agile my friends,

Bob.