There Are No Independent Teams

In my last article I sacrificed team stability for the sake of team independence.

In this article ill state there is no such thing as (completely) independent teams.

Please don't hate me.

Again, take a second to think about the value your team is trying to create. Perhaps we are talking a software application delivery team. The team has accountability for everything from prioritization, through delivery, all the way to roll-out and operations. Sounds like a truly independent team right?

Now think about all the things that team needs deliver on any one increment of value. Is there another team in our organization that does market or competitive research? Do we rely on this research to make decisions? Should we? Is there a common business model the team is leveraging? Do other teams have input into it? Do we have input into it? Some other questions we could ask:

• Is there an overarching strategy being used to guide our work? Do we help build it or validate / invalidate it?
• Are there common cultural artifacts that we share?
• Do teams share a common physical work-space?
• Do multiple teams want to or need to share a common software platform, even if that sharing is in a completely voluntary or autonomous way?
• Do other teams help set that up?
• Does the team share any common data with other teams?
• Do teams share common customers?

Tired of these questions? Hopefully I have made my point. In an organization of any scale the answer to at least some of these answers will be yes. Even in organizations of high agility, independence, is a relative concept. It is safe to say we want teams to be as independent of each other as they can be.

I often think of independence as graduated concept:

• Contribute: Our team is only independently accountable for a subset of activities required to contribute to a market outcome. Boo. But we all have to start somewhere.
• Deliver: At a minimum, we want a team to be able independently accountable for all the direct activities required to deliver on a market outcome
• Operate: It quickly becomes apparent that we don't get good agility unless the team is also independently accountable for the direct activities required to operate and support that market outcome.
• Own: We are really moving the agility ball forward when we can empower teams to be independently accountable for the direct activities required own the market outcome, up to and including being responsible for market Profit & Loss.

Notice how I used the term independently accountable for the direct activities. There are also indirect or enabling activities. Think of a sports team. The team is responsible for winning, but a lot more activities go into winning than playing the game. Talent scouts, logistics, getting people into the sporting venue, career counseling, are all things that are required, but we don't want the team doing all of these things. We want the team to focus on the game.

Likewise, in a an organization of any scale, it will be rare to see a single team that is able to deliver, operate, and own all of the direct and indirect activities required to achieve a customer outcome over time .Some capabilities are better shared across teams. Even in an agile world, economies of scale can, and will be be used to our advantage.

Support Structures are critical to support Agility at any scale

The classic agile team can break down without considering other, supporting structures. The good news is that the classic agile team is only one type of team that we can use when organizing our people to support agility at scale. The classic agile team is the most important and definitely most obvious organizing structure,. it certainly gets the most (all ) of the attention in literature today.

The trick is to set up these other, supporting structures such that we minimize enforcement, hand offs, or approval gate, as all of these items erode agility and team independence. We want to set up supporting structures so that support is given to teams when they need it.

Here are some patterns that can help people collaborate across teams while maximizing team autonomy.

When trying to provide agile teams with scarcer skills, skills that are needed on a more ad-hoc style, it can make sense to pull in people just in time, These people, known as Travelers, can come from other agile teams, or be organized into Traveler Pools.

When teams could benefit from leveraging consistency, common assets, or common knowledge to increase their effectiveness, we can provide them access to people organized into Enablement Centers.

In some cases a team does not feel the need to have any ownership over a specific activity. In this instance, an agile team can ask another team to do the work, a team where people are organized as a Service Provider. The team issues a work ticket to the supporting team, and forgets about it until the work output is handed back to them. This is a pattern we want to avoid for the most part, as it results in a hand off.

Sometimes we want to align a group of people that are to big to fit into a single team, In this case we can structure people into an Agile Ecosystem. Within the ecosystem we can determine the right combination of classic Agile Teams, Traveler Pools, and/or Enablers. All of these teams would be focused on a common overarching outcome, and be considered full time mebers of the Agile Ecosystem. An Agile Ecosystem is a good way to focus on a common purpose, one that is more fined grained than the overall purpose of the organization.