PM Articles > Alan S. Koch > Small, Self-Directed Teams

Small, Self-Directed Teams

The Essence of Agility
What makes a project "Agile"?
Part 3 of 4

by Alan S. Koch, PMP

The Essence of Agility consists of those sets of behaviors that distinguish a truly Agile team from a bunch of hackers who are claiming to be Agile. They are the markers that any concerned stakeholder can use to answer an important question, "Are they being Agile? Or just lazy?"

In my last two columns I addressed three of the key behaviors essential to Agility in projects: Learning and adaptation, collaboration, and customer focus. In this article, I will address the next key characteristic: Small, self-directed teams.

Small Self-Directed Teams

Agile project teams are small (generally fewer than 12 individuals), and they self-direct (or manage themselves).

"Small" is easy to see. If the project consists of 20 or 50 or more contributors, it is unlikely that they will be able to self-direct as an Agile team should. (Although there are ways to break a large project into several self-directed teams who work in parallel with each other, we will not address that option in this article.)

"Self-directed" is less obvious. What behaviors would indicate that a team is self-directing? Some people use the term self-directing synonymously with self-organizing and self-managing. The easiest way to think about these ideas is to watch the team's relationship with their management.

In traditional organizations, project teams rely upon their managers to prepare their plans, tell them what to do, track their status, and take corrective action. Some managers do these things more or less collaboratively with the team, considering their input, but the teams almost exclusively rely on management for these things. The net result of this mode of operation is that the manager carries all of the accountability for the team's work.

An Agile team turns the tables on these traditional arrangements, taking responsibility not only for their technical work, but also for making commitments and performing according to their commitments. How can they do this? It is achievable when the team consists of the people who have the requisite experience and perspective, both technical and business.

Product Owner

An Agile team includes a very important member who is often called the "Product Owner" (using the terminology of Scrum, one of the Agile methods). This person is accountable to the members of his or her end user and business stakeholder communities to ensure that the best possible product is built within the constraints of the project. This person owns the requirements of the project, and is responsible for defining a Product Vision, elaborating the product requirements, and prioritizing them so the technical members of the team have a clear objective to achieve. (We will discuss this Progressive Requirements Elaboration in a later installment of this series.)

To be clear, the Product Owner is a member of the team! This person does not chuck the requirements over a wall to the developers then await the end of the project. He or she collaborates with the developers regularly throughout the entire life of the project, providing direction and clarification about the product, then real-time feedback as the product is being built.

Planning Their Own Work

With the Product Owner as an active member of the team, the technical members of the team have all of the information they need to plan and manage their own work. Planning is done in a workshop format, with the technical members using their experience to establish a plan and estimate the work. They determine what is achievable, where the risks are, and what can be done to make the project both achievable and aggressive.

Many people worry that a team that plans their own work will not plan aggressively. First, this is rarely the case with software professionals. (Really! How often have you seen a software professional over-estimate the effort required for a task?) But the presence of the Product Owner in these planning sessions ensures that pressing business needs will always be a part of the discussion. These deliberations can produce the best plans—plans that meet the real business need, and can actually be delivered upon without turning the engineers into lemmings marching toward a cliff.

Another thing that makes this type of planning work well is that the team produces only a broad roadmap for the entire project. They build detailed plans only for the work they will do in the next iteration or so (about a month at a time). This incremental planning (which we will explore in a later installment in this series) allows the team to capitalize on what they have learned to date to produce the best possible plans.

When a team establishes their own plans in this way, they feel a real ownership, and this gives rise to careful managing of their work and taking corrective action when things begin to go awry. Yes, things still go wrong on an Agile project. But they can't go very far off course before the Product Owner and the technical members of the team have convened a meeting to figure out what to do about it.

The Coach

The remaining role on the Agile team that we have not mentioned is that of the Coach. Self-directing teams absolutely need a Coach to keep them on track. The good part about having technical people plan and manage their own work is that they are the people with the requisite experience and knowledge. But technical work can easily draw the best engineers into its details, causing them to lose focus on the big picture. The Coach's role is to be the team's conscience.

The Coach acts as the facilitator of the team's planning and status meetings, encourages and guides the players (as a sports coach would), and regularly draws their attention to the big picture of their team goals, and how they are progressing against their commitments. Unlike the traditional project manager, the Coach doesn't tell the technical team what to do about problems. His or her job is to be sure the team recognizes problems when they come up, and to facilitate their decision-making about how to address those problems.

Self-directed teams are not a new concept of the Agile methods—they are merely an important enabler of the behaviors that are required of an Agile team.

Becoming More Agile

We will discuss the last four behaviors of the Essence of Agility (Lean principles, Progressive requirements elaboration, Incremental delivery, and Iterative planning and adaptation) in the remaining installments of this series. But becoming truly Agile can begin today.

We can empower our project teams to self-direct by engaging a Product Owner to provide guidance and leading them in their first halting attempts at self-management. This is a big step for many of our technical people, and they will need to learn how to do it. But once they have learned, they will embrace each project with the enthusiasm that comes from a sense of ownership. This won't keep things from going wrong. But it will keep the project real—achievable, and aggressive.

This will help us to become a bit more agile. But these behaviors will be difficult to achieve without the other parts of the Essence of Agility. So stay tuned!

Not all comments are posted. Posted comments are subject to editing for clarity and length.

I am curious what sources you used to compile these observations, as what you have written has a smattering of Xp practices, Scrum Practices, and generic Agile Practices mix in with a dash of Spiral Development and a touch of Zachman.
As a practitioner of Agile I can state that so far you have completely missed the essence of Agile and why it is the most disciplined of all work frames.
Your consistency in missing the point is a common error and it has to do with confusing that the processes that Agile uses are core to the surety Agile provides upon completion. It also involves the assumption that errors are bad and risk can be mitigated.

The comments to this entry are closed.

©Copyright 2000-2017 Emprend, Inc. All Rights Reserved.
About us   Site Map   View current sponsorship opportunities (PDF)
Contact us for more information or e-mail
Terms of Service and Privacy Policy

Stay Connected
Get our latest content delivered to your inbox, every other week. New case studies, articles, templates, online courses, and more. Check out our Newsletter Archive for past issues. Sign Up Now

Got a Question?
Drop us an email or call us toll free:
7am-5pm Pacific
Monday - Friday
We'd love to talk to you.

Learn more about ProjectConnections and who writes our content. Want to learn more? Compare our membership levels.