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:
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:
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.
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:
Most Agile team frameworks/methods only meet the 2nd and 3rd requirement listed above. The anti-patterns for these missing requirements are:
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
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:
Elements of workflow include the following.
Artifacts in Team Agility include the following.