Introduction to Team Agility

Team Agility is neither a variant of Scrum or Kanban although it incorporates practices of both. It is based on principles which have proven to be valuable and recognizes no one-size-fits-all. Team Agility is defined by looking at what is needed to be accomplished at the team level and then incorporates practices of Scrum and Kanban when appropriate. This enables a concrete set of practices while being tailored for the teams using it.

This page presents how to implement the practices of Team Agility.  See Team Agility: Lean-Agile at the Team for more information on its principles. If you are using Scrum and having challenges with it, see our Scrum as Example page.

Defining Team Agility

In order for a framework to be effective it must meet the following requirements. It has to:

  • Provide a good starting point for the team involved
  • Avoid overwhelming people with too much change
  • Be specific because people like a well-defined starting point
  • Make it clear to the team what their objectives are so they can readily refine the practices as needed
  • Set the stage for the next level of learning

The principles of Team Agility

Although Team Agility provides a description of how teams can best do their work in an Agile organization, the focus is not just on the team. Agile should not be about developer iterations but rather on faster realization of business value with predictability, sustainability and high quality. Since the team is just a part of the people, workflow and artifacts required to achieve this, Team Agility must be taught within that context. Team Agility is therefore designed with the following principles in mind:

  • A recognition that the work of the team is part of a bigger picture.
  • Teams are part of a complex system and we must consider how the teams interact with the rest of the organization and not focus on just optimizing the work being done by the team.
  • Train the team in their part of the Agile Product Management workflow of identifying and refining those parts that are about to be built.
  • Recognize we need to select practices that are appropriate for the team and not take a pre-defined set of practices that attempt to work everywhere.

The elements of Team Agility

Team Agility is comprised of the following core elements: principles, roles, workflow and artifacts. Principles are belief systems and attitudes that provide guidance for getting our work done. Our roles, workflow and artifacts will reflect these principles. Roles describe the responsibilities of the individuals involved at the team level. Workflow includes both events and how work gets done. Artifacts are information stored as separate documents or in tools that relate to the work being done as the workflow in which the work is accomplished. While specifics are needed in order for people to adopt team agility, the objectives for each practice is given to enable people to move beyond any starting point. In addition to the objectives, each practice, workflow and artifact will be presented as a spectrum of maturity levels. This will both show different options teams have as well as clarifying the objectives of each of these.

Here are essential principles of Team Agility.

  • Adopt a whole system thinking approach.
  • All work must be visible.
  • Respect both individuals and the culture within which they work.
  • Have feedback loops be as short as possible.
  • Work only on items of the greatest value to the business.
  • How Team Agility is designed to be adopted.

One often hears the goal in defining a framework is for it to be simple. This has led to many simplistic processes. The goal is to be just sufficient. I prefer to call this elegance – enough to get the job done but not so much it complicates understanding. Saying something is simple somewhat implies it’s complete and simple. But in reality, it is incomplete.

We want incomplete in an intelligent way. Incompleteness when starting a new way of doing things is important. Trying to learn it all at the beginning is too much for people. The dilemma is that we can’t stay incomplete. As people learn they need to go to the next steps. So we have to start with an incomplete understanding, an incomplete approach, but one which is designed for the people at hand. We have to be intelligent about incompleteness because the starting point has to do the following:

  1. Provide a good starting point for the team involved (a one-sized fits approach will miss much of the time).
  2. Avoid overwhelming people.
  3. Specific because people’s understanding is not deep.
  4. Make it clear to the team what their objectives are.
  5. Set the stage for the next level of learning.

Most Agile team frameworks/methods only meet the 2nd and 3rd requirement listed above. The anti-patterns for these missing requirements are:

  1. The approach is either not-appropriate or misses opportunities that are readily available.
  2. The team will not know what to do when impediments to their process come up.
  3. The team will not move to the next level when possible.

Numbers 4 and 5 often result in teams abandoning key practices without adopting other practices that would be more appropriate and thereby losing the ability to achieve the key objective the practice was designed for.

While we don’t want to be complex, the goal is not the opposite of complex. It is understanding

Anti-Patterns of not taking the approach described above

  1. Teams focus on optimizing their work, losing sight of the real objectives
  2. This optimization of the teams comes at the expense of overall value realization
  3. Teams complete stories and features but can’t deliver value as required components being built from other teams are often missing
  4. If we can’t use a practice exactly as stated teams tend to stop doing them and don’t find other practices that could meet the objectives just as well with less effort

See why there is so much bad Agile out there.

The Roles, Practices and Artifacts of Team-Agility


The Product Owner

The Product Owner is the individual responsible for what work is to be done next. They prepare and maintain the product backlog from which the team pulls their work. They work with the team to define the PBIs (Product Backlog Increments) and to establish the acceptance criteria for each of them. They represent the ultimate authority for what the team should be working on. At small scale, the product owner may directly liaise with the business stakeholders. In larger development groups they may work with Product Managers in order to determine what the business stakeholders need.

Composition of the development team

Development teams should have all of the skills required to produce the software being developed. Ideally this will be for the software being released in its entirety. In larger organizations it may be just a component or module of what is being built. While it is virtually always best for a team to be cross-functional (meaning they have all the skills necessary to implement the PBIs being built) it is often the case that some capabilities are shared with other teams.

The Team Agility Coach

The Team Agility Coach is a coach for the team and has the following responsibilities:

  • Facilitate team meetings
  • Protect the team from interruptions to whatever extent possible
  • Be a coach to the team in assisting them to get their work done in a more effective and efficient way
  • Be responsible for the non-work artifacts that the team produces and uses


Elements of workflow include the following.


Artifacts in Team Agility include the following.