Why Agile Teams are awesome!

My book on Agile Organizational Design is based on the premise that a resilient organizational design is built by scaling out agile teams, and putting structures in place to support those agile teams. What do we mean by an "Agile" team, and why would we want to use this concept as our primary unit of organization?

Here is my attempt to describe the why and how behind agile teams. My description will be devoid of any particular methodology or framework, so we can focus on the underlying structure and behaviors.

Like this article? Download my book on Agile Organizational Design.

We got this!

Teams need an outcome, a mission, a mandate, a reason for being. They need ownership and autonomy to achieve that outcome. They need the freedom to experiment, to both succeed and fail. Some teams are give a direction, and some teams create their own, but with a purpose, all other attributes of a team are worthless.

Teams! Team! Cross functional Teams!

If our primary organizing principle is to place people into teams, then we want those teams to have cross functional capability. What this means is that the team is in possession of, or can very quickly get access to, everyone and everything they need to achieve on the outcomes they are trying to achieve. The concept of cross functionality applies not only to the team as a whole, but also to how individuals in the team grow their skills over time, from highly specialized to T- shaped people. We want people to be able to play many roles on the team.

Team Membership is a full time commitment!

In the traditional working world, the concept of a team is ephemeral and vague at best. People in a team are only there part time. People are part of many teams. The team is never really together at one time, and the team, well never actually does any teaming. Gelling doesn't occur, alignment doesn't happen. An Agile team is made up of full timers, who are dedicated to the team. The majority of a team member's time is spent working with the team. Not spent with their functional group, not spent with their boss, but spent with the team.

Team Members Need to be Teaming

Team is not just a noun, ie my team. It's also a verb. Teams need to be Teaming! yo. Teaming is the act of gelling, bonding, norming, and forming. The act of becoming a real team, one that exhibits real teamwork. Teaming takes trust, teaming takes shared experience, teaming takes time. Teaming is a lot easier when team membership is stable. If the roster is constantly changing, it becomes really hard to establish norms, we don't get to understand how to work with each other.

The Customer is Part Of the Team!

A truly cross functionality team will be made of people responsible for doing the work, as well as made up of people who represents the customers of the work. In the software world this means at a minimum, both business and technology people are part of the team. Better (much better)would be frequent interactions with real users! One of the things customer representatives do is help the team prioritize work by sorting value increments into a highly visible backlog. But really, we want a lot more from our active customer(s). Co-creation, evaluating problem and solution fit, prioritization, and evaluating outcomes are also part of the package.

Small Number of Things That Are Small!

The team tries to work on only a small number of increments of value at a time. This helps the team increase focus, and minimizing the time it takes to get an increment of value delivered to production, or minimally get the work to a production ready state. Typically teams will break work down into small increments in order to promote fast feedback and learning. Working on a small number of items that are small helps make problems obvious, and exposes opportunities for the team to improve.

Minimize the Leakage!

In order to foster an environment of effective teamwork we try to ensure that the team can deliver value with independence. Independence from other teams allows decisions to be made while minimizing the impacts to other teams. We encourage people to try and organize around outcomes, not around functions (eg testing team, product team). This allows teams to start evolving into little independent, micro organizations. These types of teams can start to own the planning, delivery, and operational activities required to realize their outcomes, and do so in a way that minimizes dependencies on other teams

Make It Visible! No, Really Make it Visible! Stop What you Are Doing and Make It Visible!

The team will often take advantage of visual work management. Teams often visual their backlog, as well the work they are currently doing. Team events are used to add further transparency. Events can include some form of team planning, demos of accomplished work to customers, daily coordination and impediment discussions , and periodic team improvement sessions. Teams do this to create radical transparency for themselves, and their stakeholders. When team members strive for greater awareness of the what and why of each other’s work, they are more able to effectively hold each other accountable to the outcome they are trying to achieve.

If you aren't changing it, you aren't doing it!

Events, work visualization, team performance metrics and market oriented metrics are used by teams to inform a constant and virtuous cycle of continuous improvement. The team uses small experiments to frequently plan, execute, and adapt both the way the team is working as well as determine what value the team should focus on delivering.

Now for a little dose of reality

Uh oh, out comes the agile skeptic in me.

It turns out there are some very real dragons in these hills. I have only seen a few cases where agile teams neatly fit into this definition, and many more cases where they do only partially, into a couple of the points I mentioned.

The reality is that very few organizations of any scale are religiously operating according to my pure definition of agile teams, and when they try they often start encountering some very real, almost intractable problems.

In my book on Agile Organizational Design I discuss some some truths about organizing people into agile teams, in order to help you avoid some of these common traps. I'll recap this as part of my next post as well.