Teams 101

The notion of forming complete cross functional teams is one of the most well understood concepts in the agile community but maybe one of the least implemented in practice. Many folks adopting agile either don’t understand the importance of teams, or if they do… they don’t have the power to influence the organization to build them. Often, there just aren’t enough people with the right kinds of skills and experience to get every team everything they need… so they compromise.

What happens when we compromise this foundational principle of agile?

Assuming for a moment we actually have the ability to create a well-formed backlog… and theoretically the ability to produce a working, tested increment of the product at the end of the iteration… an incomplete team won’t be able to establish velocity, won’t able to communicate progress, won’t be able to validate the product as they go or get any meaningful feedback. Furthermore, they’ll create an indeterminate backlog of unfinished work as they go.

This is a huge problem for organizations, especially those in the early stages of adopting agile.

Why? Well think about what we are asking folks to do. We are asking them to buy into a system of delivery that is not based on heavy up-front planning and one that doesn’t make commitments to delivering a specific scope within a specific time and cost constraint. We are asking people to let us change direction when we learn new information without requiring change control. This is scary for most folks, and viewed as fundamentally irresponsible to others.

The tradeoff we are selling is that our stakeholders will have continuous input into the process, total transparency into the evolving product, the ability to unambiguously validate progress, and the opportunity to put product into market early and potentially realize an earlier return on investment. The deal is this… if you trust me to work in an agile way, I can create better economic outcomes for you in return. That is the agile value prop for our customers.

Now… think about all the things we break in this deal when we don’t form complete cross-functional teams. We cannot be stable. We cannot be predictable. We cannot produce a working tested increment of the product at the end of the sprint. We cannot get meaningful feedback on the emerging product. We cannot release early. We cannot fundamentally honor the contract we have entered into with our customers. We are frozen.

One of the most subversive things about incomplete teams is that they stop believing they can plan an iteration and deliver value for their customers. They stop believing that they can make and meet a commitment. They stop believing that they can do what they say they are going to do. They stop taking responsibility and can’t be held accountable. They go through the motions of doing agile but can’t produce any of the business benefits that come from it.

Here is my take…

There are lot’s of ways to be successful. I’ve run great waterfall projects. I’ve run projects with fundamentally no process at all. With the right people and the right focus you can make just about anything work. That said, if you want to make agile work, you have to form teams. If you are not going to form teams, don’t do agile. The worst thing you can do is adopt a process based around teams without creating the very construct that allows the process to work.

Up next…

1. Teams 102… A quick history of agile and how our beliefs about adoption and transformation might be impacting our ability to form teams

2. Teams 201… a more advanced treatment of what it means to form an agile team, what to do with specialists, and where to put folks that don’t go on agile teams.

3. Teams 301… patterns for forming teams in larger, more complex organizations with legacy platforms, shared services, and shared components