Agile Teams in a nutshell

Agile teams are awesome. The how and why of agile teams are relatively straight forward concepts. The value of why you would want to rethink your organization as a set of agile teams is reasonably apparent to most people I talk to, but let's do a quick recap and touch on some of the key concepts.

1. Teams! Team! Cross functional Team!Our primary organizing principle is to place people into teams. We want team to have cross functional capability. What this means is that the team is in possession of, or at a minimum is able to very quickly get access to, everyone and everything they need to deliver on the outcomes that the team is 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 more generalized. We want people to be able to play as many roles on the team as the team requires.
2. 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 team. The team is never really together at one time, and the team, well never actually teams. 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 with their functional group, not with their boss, with the team.
3. Team Members Need to TeamTeam is not just a noun, ie my team. It's also a verb. This group of people need to team. The act of gelling, bonding, norming, and forming into 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. It can be hard to understand how everyone works. So we try to make sure the roster doesn't fluctuate.
4. The Customer is Part Of the Team!This cross functionality means that the team will have people responsible for doing the work, as well as have participation from people who represents the customers of the work. In the software world this means at a minimum, both business and technology people are in the teams. One of the things a customer representative does is help the team prioritize work by sorting value increments into a highly visible backlog. But we want a lot more from our active customer(s). Co-creative solutioning, problem and solution fit, and validation of value are also part of the package.
5. 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 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.
6. Minimize the Leakage!In order to foster an environment of effective teamwork we try to ensure that the team has some quality independence. Independence from other teams allows decisions to made while minimizing the impacts to other teams. We encourage people to try and organize themselves not around leadership accountability, but around work based on how much collaboration is required to devote work . We want teams to evolve into a mini organization, encouraging the team to own the planning, delivery, and operational activities required to realize an outcome, and do so in a way that minimizes the cross team dependencies.
7. Make It Visible! No, Really Make it Visible! Stop What you Are Doing and Make It Visible!The team will often often take advantage of visual work management and events, run reoccurring events held at a steady cadence to manage the life cycle of the work. Teams often visual their backlog, as well as the state of the work they are currently doing. Team events can include some form of team planning, demos of accomplished work to customers, daily coordination and impediment discussions , and period 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 mission they are trying to achieve.
8. 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 the value is being delivered.

So, when teams strive to do these things, regardless of framework, method, or methodology, we have a set of operating principles that when taken together, supports the team's ability to effectively self organize. Note the emphasis on the word organize. Agile does not mean anarchy, or a free wheeling laissez-fair approach to value creation. Agile teams are a way for organizations to structure themselves into cohesive units that require minimal management intervention. The combination of radical work transparency, constant customer feedback, continual experimentation, and diversity of opinion acts as a complimentary set of corrective mechanisms that keep individual teams iterating towards delivering the most valuable work they can, in the best possible way, while minimizing the need for command and control.

This lack of command and control further fosters a sense of ownership and social density, which in turn decreases the need for any traditional management.

Now for a little dose of reality

There are some dragons in these hills. You may be skeptical that all of this can work in your context, and rightly so. The reality is that very few organizations of any scale are religiously operating according to this pure definition of agile teams. People see the mantra of agile teams, get wowed by the possibilities, start the process of moving folks into teams, and then start encountering some very real, almost intractable problems right away. What follows next is retrenchment, disillusionment, and some really bad hacks that bring back old ways of working and thinking. Some issues I have seen include:

• If I put everyone I need onto a team the team will be huge! 30 people! 80 people! 200 people!
• The work requires really specialized individuals, and its never the same ones! Someone is always idle on my teams, and its usually never the same person!
• My software architecture is so fragmented that every team structure I can think of results in a spaghetti of dependencies!
• I have to many customer, and they are all competing with each other! How I can I pick a dedicated customer to act as my customer representative for my team!
• My teams are all going in a different direction on something that would benefit from some consistency! I cant get this consistency if every team is self-organizing on every aspect of what they do!

Here are what I see as some truths about organizing people into teams, understanding these truths will help you avoid some common traps you encounter as you think about how to form people into teams across your organization. It will also pave the way for a more robust discussion of agile teams. How to set them up, how to support them, and how to help them evolve as things change.

Truly Stable Teams Erode Agility

That is a strong statement. But lets think about that Agile is trying to address.

Uncertainty.

Complexity.

Change.

Agile provides us a means to deal gracefully with a world that is complex and constantly changing, and it does so through mindset and methods that allow you to take feedback and alter your solution. This means you constantly shift both the what and the how of your value delivery. This shift will need to include what people are formed into what teams.

Lets say you have analyzed the demand for your organization, mapped it to capability, formed an ideal set teams around those capabilities, and staffed those teams with people that possessed those capabilities. You can now sit back and let those teams deliver, right? You're done right?

Wrong

Now something changes, demand has changed, priority has shifted, our understanding of the effort for a piece of work has evolved, we have a new understanding of what things we need to deliver. We uncovered the need for a new capability. We have two options here. The first is to keep our structure stable.

Perhaps some other team has those missing skills we need to deliver value? Couldn't we send the portion of work over to that other team? We could, but now two team need to coordinate to deliver value, which interferes with each teams ability to independently self organize.

Maybe a piece of work involves more effort than we thought. Cant we keep the team the same size and take longer to deliver? We could, but we may delay feedback and learning, and depending on how important that is to the team, we could miss out on a market opportunity

Perhaps we have discovered a new opportunity, unlike anything we have done before as an organization, delivering it would require collaboration that spans across our entire team structure. Couldn't we just coordinate the work across the teams? We could, but I think you get the idea. Coordination requires classical, old school management. One informed by agile backlogs, stories, visual flow, etc, but its still management. The more teams become dependent on each other, the more they they will require dedicated people to manage this dependency, the more they will lose their ability to self organize.

The reality is that stability and independence are concepts that contradict each other. You need stability, absolutely. Without stability people in teams do not have a chance to well, team. Remember team is also a verb, teaming takes active thought and participation over time from it's members. But stability can't mean static. Static teams don't flex when demand changes. Static teams mean you have hand offs across your teams as the cracks in your original org team design start to show. And we need teams to have independence.

The answer is an an evolutionary approach to designing team structure, conducted frequently

Refinement of team design can be held at a cadence, done as part of the initial exploration of new opportunity that enter our system of workers. We take care to minimize the impact to team stability when we refine our make up of teams. Better stated, we try to minimize changes to our team to accommodate changes in demand while relentlessly avoiding team hand offs. Its a balancing act. Unfortunately one where people sacrifice team independence for team stability. It is a counter intuitive truth that team independence trumps team stability. Visual backlogs, visual flow and other agile practices make it easier for people to self- organize around the work. This includes getting accommodated with a new team structure. But it takes courage, and it takes practice.

Team reformation can be accomplished as part of a an Agile style events held at cadence, dedicated to coordinating this type of planning. We can use flow visualization systems at the Initiative / MVP level to inform this cadence. We can facilitate informal, high level Epic /Feature analysis to inform our team structure. We can spot bottlenecks to inform where hand offs are acceptable and where they indicate a need for a structure with less hand offs. We will go through each of these techniques in the upcoming chapters in this book.

There Are No Truly Autonomous Teams

Ok, I just sacrificed team stability for the sake of team independence. Now I am going to tell you there is no such thing as team independence. Please don't hate me. Again, take a second a think about the value your team is trying to create. Perhaps it is a delivery team with 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 what the team need before it starts working on any one increment of value. Is there another team in our organization that does market or competitive research? Do we use it? Should we? Is there a common business model the team is leveraging? Do other teams have input into it? Do we? Is there a common strategy? 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 autonomous way? Do we help set it up? Or does someone else do it? 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 many 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. Preferably, a team is independently accountable for all the direct activities required to deliver on a customer outcome. Hopefully, the team is also independently accountable for many, or even some of the direct activities required to operate and support a customer outcome. Even better, the team is accountable for all the direct activities required own the customer outcome, up to owning the P & L. Rarely, do I see teams able to deliver, operate, and own all of the direct and supporting activities required to achieve a customer outcome over time . And in an organization of any scale I don't think they could or even should own all of these activities. Some capabilities are better shared across teams. Even in an agile world economies of scale can, and will be be used to our advantage.

The truth of the matter is that the classic customer facing, outcomes oriented, fully dedicated , agile team is only one type of team that we can use when thinking about organizing for agility. The classic agile team is probably the most important structure, it is definitely the most obvious one. The classic agile team certainly gets the most (all ) of the attention in literature today.

But the classic agile team breaks down without considering other, supporting structures. When trying to provide agile teams with scarcer skills, skills that are needed on a more ad-hoc style, we can allow them to pull on people just in time, people who are organized into Traveler Pools. When teams could benefit from leveraging common assets, connections, or knowledge to increase their effectiveness, we can provide them access to people organized into Enablement Centers. In rare cases a team does not feel the need to have any ownership over a specific type of work. In this instance, an agile team can submit a work request to another team that has people organized as a Service Center, in effect the team issues a work ticket to the supporting team, and forgets about it until the work output is handed back to them.

In the coming chapters, I'll go over each of these team engagement patterns, as well some supporting team linking patterns in more detail. I'll show examples of these patterns in play and discuss trade offs and benefits when thinking about using them. Ill go into quite a bit of detail around how support teams can operate. How they connect to other teams, how they can visualize their work, and evolve to a true enablement model, versus doing the work themselves.

It's Not About the Team

All right. Now I am sure some of the Agilists are going to come out with the pitch forks. Ok, hjow about it's not just about the team? Hear me out. A lot of Agile puts focus on the team. How is the team velocity? Can the team meet the teams's Sprint commitments? How did the team retrospective go? It's not that there is anything wrong with a strong team focus. We want a strong team focus. But a team view can be myopic, especially if you are working in a larger organization. We can optimize on team health, but have no effect or even harmful effects to the overall organization or customer value.

Let's take an example, Team A is a software delivery team that works with Team B who delivers end user training to customers. Team A is rocking it! They deliver and quickly! Team B is not keeping up. They can't get users trained fast enough to keep pace with all the changes to software Team A is making. Worse, Team B starts to compromise quality to keep up. This leads to poorly trained users. These users make mistakes using the software, which causes further problems with customers. None of this is apparent from team practices, team metrics, or single team focus.

It's important to realize that the team is a social construct with a high degree of social cohesion, but other larger social constructs are also valuable for us to manage. In the coming chapters I'll talk about some fundamental agile organizing structures, such as the Edge, Outer Cores, and Inner Cores. Ill discuss organizing team into context boundaries where multiple teams can share in a mission, outcomes or platform. They can leverage common identifying artifacts, such as business models and overarching backlogs.

Ill connect the work to the concept of domains, and discuss how many organizations are achieving agility at scale by matching groups of tightly aligned team to ind-pendant domain contexts. Often achieving team independence by implementing using micro-services.

Organizing For Agility, In A Nutshell

So, Organizing For Agility is about looking at your demand, your outcomes, your roadmap, whatever.

Asking your self "How can people form into self organizing social structures that can effectively deliver on the the things we want to deliver on next?" and refining those structures accordingly.

And then asking "What support structures need to be in place to help my teams operate at scale?" and standing them up.

And finally asking "What has changed in my context, and how does my organization need to flex in response?" and doing it all over again.