One of the core ideas or principles of agile teams is this notion of a self-directed, self-managed, and self-organized team. 

In my experience, it’s one of the hardest things to “get right” in your coaching and team evolution efforts.

Often I see two extremes…either:

the teams use the self-organization, self-directed mantra as a means of having no accountability. It’s essentially the “inmates running the asylum” and they can choose to do whatever they wish, whenever they wish under the banner of – “don’t bother us…we’re being agile”.

Or the other extreme is that:

the management team says that they’re empowering their self-directed teams, but when you look at their behavior, they’re doing what they’ve always done…tell folks what to do.

People also seem to like being told what to do; being micro-managed

Self-directed teams are teams that, once given a mission or goal, are expected to sort out the challenges and deliver.

While this is a central notion, in my experience, it’s hard to get individuals and teams to take this on. I’m not quite sure why, because it’s really such a compelling premise. That is (You) own your own destiny (Results) so figure things out.

Instead of folks embracing it, I often see them fighting it. Is it a lack of practice in decision-making? Is it a fear of accountability? Is it a fear of failure?

I’m not quite sure, but it could be aspects of all three and much more.

It seems that many of us have become comfortable complaining about things and “pointing upward” to “them” as being the problem. Point being, many individuals have become comfortable with being told what to do. With the accountability residing with their managers and they simply are – doing as they’re told. However, if agile is done well, then “they” becomes “us”, which can be particularly scary.

On the flip side of this, when I do see individuals and teams embrace self-direction, then it’s a “magical” thing. There is a shared accountability between the leadership team and the teams doing the work. It’s balanced and effective, with each one supporting and trusting the other.

But this balance can often be quite difficult to achieve.

What the Scrum Guide has to say…

Next let’s review what the Scrum Guide says related to the overall Scrum Team:

The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master. Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team. Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team. The team model in Scrum is designed to optimize flexibility, creativity, and productivity.

And then it goes on to say the following about the Development Team:

The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of “Done” product at the end of each Sprint. Only members of the Development Team create the Increment. Development Teams are structured and empowered by the organization to organize and manage their own work. The resulting synergy optimizes the Development Team’s overall efficiency and effectiveness. Development Teams have the following characteristics:
  • They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality;
  • Development Teams are cross-functional, with all of the skills as a team necessary to create a product Increment;
    • Scrum recognizes no titles for Development Team members other than Developer, regardless of the work being performed by the person; there are no exceptions to this rule;
    • Scrum recognizes no sub-teams in the Development Team, regardless of particular domains that need to be addressed like testing or business analysis; there are no exceptions to this rule; and,
    • Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole.

In this case the Scrum Guide is focusing the term self-organizing towards how the team decides to attack the work they’ve been asked to perform via the backlog. Schwaber and Sutherland seem to go to great lengths to emphasize the team owning and deciding work strategy. They also emphasize a blending of roles to the point where they are near meaningless. The key points seem to be: team, teamwork, delivery of a product increment and accountability.

What Esther Derby has to say…

In 2011, Esther Derby wrote a really nice article that tried to address some misconceptions related to self-directed teams. The three misconceptions she highlighted were:

  1. Self-organizing teams are completely autonomous, self-managing, and don’t need managers.
  2. All you need to do to form a self-organizing team is provide a goal and apply pressure.
  3. Since the team is self-organizing, they can accommodate moving people on and off the team easily.

http://www.estherderby.com/2011/07/misconceptions-about-self-organizing-teams-2.html

There is an overall misconception that Esther discusses surrounding the relationship, role or ‘dance’ between the self-organizing team and the leadership structure within the organization sometimes referred to as (‘management’).

In most cases, there isn’t a whole lot of guidance coming from the agile community around managing/leading agile teams. And usually what does come out emphasizes the team over management. What I mean by that is that management is basically told to “leave the team alone” or “go and handle a few impediments” as their primary role.

I really like the balanced (and necessary) role that Esther describes.

Constraints? Or do the inmates indeed run the asylum?

There seem to be two schools of thought when it comes to applying constraints to agile teams. One is that they’re inherently bad; that they undermine the empowerment and accountability of the teams.

I sometimes see this in coaching colleagues who use terms like:

  • Agile Purism;
  • Un-agile, Un-lean;
  • Arbitrary or Dogmatic;
  • Prescriptive or Prescription.

To describe anything that “forces” the team to do something against their will. Literally they want the team to be unencumbered in their journey without literally any constraints.

Unless you’re working in your own company, or for a non-profit perhaps, I’ve never encountered a job (yes, agile team members usually work) with a total lack of constraints. Usually there are quite a few, for example:

  • quality constraints;
  • appropriate working conditions (language, dress, hours, etc.)
  • business & financial constraints;
  • agile constraints – Definition of Done, agile approaches used, tooling, etc.
  • legal constraints.

But at the same time as we’re applying constraints, we need to be careful that they’re not too oppressive – that they leave some room for the team to make their own rules and their own decisions.

Definition of Done

I’ll use Definition of Done as an example. I believe teams need to have a deep and broad definition of done. I wrote about what that means here and here. But at the same time, I usually encourage teams to “extend” their DoD with team-based agreements and to make it “their own”.

I encourage the same thing to happen when the team is making other operational agreements amongst themselves.

How do we “Create” these teams?

I don’t think you do. I think the leadership team has a responsibility to create a fertile space for these sorts of teams to form, become established, and grow.

Aspects of which include:

  1. Staffing the team with the skills required to deliver on their backlog;
  2. Trying to avoid part-time team members at all costs; if you do have some, limit them and clearly define their “capacity” within the team;
  3. If you’re doing Scrum, have a dedicated Product Owner and Scrum Master. Make sure they have the experience, time, and focus to do the job well;
  4. Respect the autonomy of the team and trust them to deliver in your stated goals and directives;
  5. And engage in all aspects of the agile ceremonies so that you leverage the transparency and real-time adjustment nature of the methods.

And the team has self-direction responsibilities as well. For example:

  1. Holding each other accountable to professional ethics and standards;
  2. Having congruent discussions in retrospectives guiding the team towards continuous improvement;
  3. Having the courage to push back as appropriate on traditional leadership that might be pushing the team too hard or in the wrong direction;
  4. Holding quality dear within the team, not only from a Definition of Done perspective, but with solid professional attitudes and practices;
  5. An overall responsibility to respectfully work together (swarming around the work) and avoiding Scrummerfall behaviors – delivering as much high-quality and high-value software as possible.

Wrapping up

I’m quite curious as to how readers might react to this article. What are your experiences in achieving self-direction in your agile adventures? Is it easy or hard? And have you seen team resistance to the notion?

Have you discovered anything worth sharing about how to achieve this level of organizational balance? I’d be very interested in hearing about it.

And is it something, that once you’ve achieved it, it sticks? Or do you have to continuously work on your self-direction, autonomy, and self-organization?

Stay agile my friends,

Bob.

A few nice references

 

4 Comments