Teams are the Building Blocks of Agile Organizations

If you are going to embrace any form of agile, you need to start by thinking about your teams as the elemental building blocks of your agile organization.

Teams are Elemental

Regardless of whether you decide to organize around feature teams or component teams, you need to look at the team as the fundamental unit of organizational capacity. Francois Bachmann from SprintIT has a great way of saying this... build projects around teams... don't build teams around projects.

We've got to stop thinking about how we are going to resource level across teams... or how to optimize the utilization of individuals within teams. Instead, let's think about how we can increase the performance of the team overall. Let's think about how we can develop better capabilities, greater technical prowess, and better working relationships between team members.

Great teams deliver great software... period.

With the team as the elemental unit of throughput... and knowing that over time we can establish a stable team velocity... we can begin to think about becoming predictable as an organization. We can start to see our teams as the building blocks around which we'll construct our agile organization. We'll be able to deploy teams of teams that solve our most critical business problems.

Normalizing Inputs

Think of a team as a black box that has both inputs and outputs. The primary input to the team is the prioritized product backlog. The output of the team is working software on regularly defined intervals. In order to get working software on regular intervals, you have to have a steady input of prioritized product backlog ready for the team to work on.

It is up to the business to normalize the input to the team if they expect to get a predictable output. If you put crap in the system... you are going to get crap out of the system. No groomed product backlog... no working software.

So from the teams perspective... all the normal agile stuff applies. Apply all great engineering practices... do the visual progress indicators... collocate... have daily stand-up meetings... do team building... and conduct retrospectives. That is the stuff inside the box. Regardless of scale... the team is king. They are an empowered, self-directed, self-manged unit of organizational capacity.

Everybody outside the team is responsible for making sure the teams have the proper inputs so that the business can get predictable outputs. The business has to act like a UPS that protects the team from unexpected spikes and brownouts. Scrum calls this function the Product Owner. I don't care so much what we call it... or who does it... we just need to make sure somebody or someone does it.

Context and Coordination

Regulating inputs to the teams means providing context... what we are going to do and why; as well as coordination... when we are going to do things and in what order.

Over the past few posts... we established that the Product Owner in Scrum is the single person that acts as our UPS for the team. We've already explored how in any moderately complex organization, this role is too big for a single person to handle. What I am saying here is that naming a single person to play the role of Product Owner is not nearly as important as fundamentally making sure that each of our agile teams has stable input.

We need stable input so the teams can deliver predictable and coordinated outputs that align with the broader organizational objectives. This is not a product owner problem, it is not a team problem, it is a business alignment problem. Abstracting this problem behind the Product Owner concept only hides the mess.

This problem is further exacerbated as we start putting multiple teams together in order to deliver on broader organizational objecives. Remember... the problem is not finding single person to serve as a Product Owner... the problem is making sure that teams of teams have proper context and coordination.