Team Agility is based on Lean-Thinking and Agile. It can be considered an integration of Scrum, Kanban and eXtreme Programming based on Lean-Thinking. 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 Scrum as Example.
Using a predetermined set of roles, events, artifacts and rules is like having a GPS that just gives you the directions without the map. If you get lost or you can’t make a turn or you miss it you are lost.
Being given a map with alternatives to get there provides not only options that work for you but provide a way of getting back on track when you get lost. In the complex world of software development it is even more likely you’ll need this ability.
Many people require a given set path. But have it include where you are and have it provide you with a reset option when you get lost. This is what Lean-based team Agile does. Scrum doesn’t even try because you are out of Scrum by this time. Scrum proponents just call this Scrumbut and go on to the next team. This doesn’t mean you can’t use Scrum, it just means that when you do Scrum you should do it within the context of Lean.
In order for a framework to be effective it must meet the following requirements. It has to:
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:
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 it’s more likely to be incomplete and simple.
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:
Not having numbers 4 and 5 above 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.
The objective of team agility is to help the organization achieve business agility – the quick realization of business value predictably, sustainable and with high quality. This requires both collaboration across teams and teams working within the context of the organization. This implies agreements such as the Guardrails for the Team and their Scrum Master must be made.
Systems thinking is considering a system being an interrelated and interdependent set of parts which is defined by its boundaries and is more than the sum of its parts (subsystems). Changing one part of the system affects other parts and the whole system, with predictable patterns of behavior. Positive growth and adaptation of a system depend upon how well the system is adjusted with its environment, and systems often exist to accomplish a common purpose (a work function) that also aids in the maintenance of the system or the operations may result in system failure. The goal of systems thinking is systematically discovering a system’s dynamics, constraints, conditions and elucidating principles (purpose, measure, methods, tools, etc.) that can be discerned and applied to systems at every level of nesting, and in every field for achieving an optimized end state through various means.
The foundation of Team Agility is Lean Thinking which essentially adds the importance of leadership, attending to time and a commitment to quality. Continuous improvement is based on improving the system being used and creating an environment within which teams can self-organize while attending to the needs of the whole.
While from the Scrum Guide, “Scrum’s roles, events, artifacts, and rules are immutable” none of Team Agility is. As an operating model it is intended to be used to find the best roles, events, artifacts and rules applicable to a team’s situation.
Objective: Our intention is to achieve business agility. We should not striving for local optimization at the team level. Looking at the entire system, or at least at that aspect we have influence on, improves our effectiveness.
Why: We want self-organization to occur within the context of the value stream the development group is in.
Options: Self-organize within the context the development group finds itself in. This requires collaboration between management and the team-coach.
Team Agility is consistent with the Scrum values of commitment, courage, focus, openness and respect. Team Agility is designed to help facilitate these values when the system people are make it hard for them to become evident.
Here are the anti-patterns, the patterns of undesirable behaviors, that result when you not take the approach describe above.
A common anti-pattern is when teams just decide to use Scrum or Kanban instead of looking to see which is more applicable. In reality, one should not be chosing but taking what works from both. One useful step, however, is to see if Scrum is applicable to your team.
When following Scrum the suggestion (demand actually) is not to change any of its core practices, roles, rules or artifacts. However, nothing in Team-Agility is sacrosanct other than ensuring you’re working on your real problems, we must be more careful. Changing one aspect of Team-Agility will undoubtedly have an impact on others. In the same way you can’t take the transmission out of a better car than yours and expect an improvement (it probably won’t even fit) you can’t change practices without attending to how that interacts with others. For this reason a sub-section entitled: Related practices, etc.: will be included for each aspect of Team-Agility when effectively changing it requires attending to other practices, etc.
Team-Agility is not a variant of Scrum. However, because most people are familiar with Scrum, this page, with just a few exceptions, describes Team-Agility on an outline based on Scrum. The intention for each role, event, artifact, and rule of Scrum, as described in the Scrum Guide, will be discussed here. However, Team-Agility is based on Lean-Thinking, human psychology and organizational development. Therefore, other practices that both extend Scrum and are sometimes inconsistent with Scrum are presented as useful.
Team-Agility does not require changing the roles of the team to be Product Owner, Development Team and Scrum Master. Scrum’s objective here is to have a team that focuses on delivering value. Different roles imply different responsibilities. Team-Agility fosters the intended alignment with its focus on time from start to finish as well as an alignment around value realized.
Objective: Have a clear liaison for the team to go to understand what work needs to be done and why.
Why: The team requires direction on what they should be working on.
Options: Model after Scrum’s Product Owner. Responsibilities include:
See more on the product owner’s role here.
Coaching is the practice of supporting individuals, teams, and an organization through the process of achieving a professional result. It differs from consulting, mentoring, and training. It involves more questioning and facilitating than doing particular tasks for the person or team or group. It is more focused on process, discovery, transition, leadership, and mindset than it is on particular projects. The goal is to help people to develop new mindsets to do Lean-Agile, to acquire a new set of tools, and to make adjustments to processes and structures.
The coach helps them gain confidence and effectiveness so that they can sustain the gains.
Coaches seek to build the capability of management, teams, and individuals so that they can quickly become self-sustaining. This involves ever-increasing competency in specific knowledge and skills. The end result is an organization that is well on its way in the transition to an enterprise with the foundation, direction, and process guidance to get there.
The ideal case of having a cross-functional development is undeniable in most situations. However, as Agile has spread to organizations with multiple levels of architecture, shared services and ops, it is rare to actually be able to achieve this. In many cases it is not even cost effective to do so. The intention is to reduce handoffs, increase collaboration and create an environment for innovation.
Objective: Have all of the capabilities needed to create value quickly in a predictable, sustainable and high quality fashion. This does not include dependencies between other teams doing work, but relates to when people’s capabilities that are shared across several teams are needed, for example, business intelligence or UX. 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.
Why: Cross-functional teams facilitate the removal of delays and handoffs, while speeding feedback and delivery of value. They also foster creativity and a team spirit.
Options: Where-ever possible create cross-functional teams. When not possible, see if teams being dependent upon can provide team members needed for the necessary time. If all capabilities cannot be made to exist in the team then manage the dependencies on the shared capabilities via a Kanban board so that the delays created by using people outside of the team can be known and managed.
See Achieve Cross-Functionality to the Extent Possible for more.
Cadence means to have a regular beat.
The heart of Scrum is the sprint (called an iteration outside of Scrum). A sprint provides a time-box within which work takes place. This “time-box” is from the time after planning to the time set for the end of the work to be completed. Using time-boxing has many positive side effects and should be abandoned with care. Otherwise any changes to the sprint will almost certainly cause damage to the team’s work.
In Scrum, sprints provide the regular beat. The start and end of a sprint provides timing for the following.
Scrum uses the sprint to set the cadence of the above actions.
Kanban’s flow model does not require a time-box. However, a cadence to do the above collaborations is useful. In either case the cadence provides for different teams to have a set time for collaboration. A flow model requires the addition of other practices in order to achieve what Scrum achieves with its sprint. These include:
Objectives: There are several objectives of the sprint. These include:
Why: Short cycle times of work minimizes delays in workflow feedback, communication. This lessens the creation of unplanned work. Visibility of work and a common cadence improves the collaboration of teams working together.
Scrum without sprints is not kanban
We often hear teams saying they are doing Kanban when what they’ve really done is abandon sprints. This is not Kanban. Kanban requires that teams work in a manner that directly provides what sprints provide as side effects.
Suggestion for improving sprints
If a team is having difficulty with their sprints I suggest that they don’t just abandon them. Instead, start following the practices in Kanban in an attempt at doing your sprints better. Improvement is almost certain. One of two things will likely happen. You might find that your sprints improve and doing them is advisable. You might also find that you no longer need them and get the objectives they were trying to achieve.
This section has been put in its own chapter. Read it here.
See full chapter Manage Work In Process (WIP) By Focusing on Finishing.
With the exception of teams which cannot plan their work (e.g., some maintenance organizations, shared services to some extent) planning to some degree is usually useful. If time-boxing is being used it is important to plan the time-box at the beginning of it. In Scrum this is called Sprint planning. If a flow model (e.g., Kanban) is being used, planning is not require except that enough work must be on the product backlog for the team to pull when they need it.
Objective: Improve people’s focus and help people to see the work in order to enhance dependency management.
Why: While planning too far out is usually wasteful, no planning creates surprises and chaos. A blend of micro-planning (what is the next thing we’ll do) and macro-planning (what are we going to do over the next period of time is require both for focus and to see what’s coming up. Longer term planning is often necessary for stakeholders to see when value will be realized.
Options: Micro-planning – a focus on finishing and the use of kanban. Macro-planning can be accomplished by iteration planning or SAFe’s program increment planning. Macro-planning likely will require some form of estimation and velocity
Teamwork requires people know what each other is doing, what they can do to help, and who they can call on to help.
Objective: Continuously improve the rate of value delivery in a predictably, sustainable manner with high quality. This spans improvement of workflow, quality of code, and fitness for use.
Why: Impediments slow the team down. If they are not made visible then fixing them is often put on a back-burner unintentionally. After initial gains many people are satisfied. The risk is that teams make initial improvements only to fall back and end up where they started. The level of wasted effort in software development is typically extremely high and can be significantly reduced.
Options: Improvement can be made on three time-frames:
True continuous improvement requires explicit workflow and all work being visible. Scrum’s approach with daily standups and retrospectives are also recommended with the exception of daily standups are sometimes not required when pairing or mobbing is also being done.
Do regular retrospectives. Have explicit workflow (Kanban). Make all work visible. Do daily standups. Recommend all of these except can skip daily standups if mob-programming. Attend to the value stream impedance scorecard during retrospectives to see if it is improving. Track impediments discovered on a list so they are visible and not forgotten.
In Scrum: Inspect and adapt anytime a challenge is encountered. Take time to consider how to improve during the retrospective. Anything that slows down delivery is an impediment. Daily standups and retrospectives should also look for impediments.
In addition: Ensure all impediments and blockages are visible.
Why: It is easy for teams to get caught up in their work. There are also often opportunities to improve things if they are kept top of mind. If they are not made visible then fixing them then they may be forgotten about or opportunities to fix them may be lost.
Options: Keep a list of impediments and make any blockages visible on the board.
Depending upon whether a time-boxed based model such as Scrum or a flow based model such as Kanban is being used there will be 2 or one backlog. In both cases a product backlog will contain the items to be built. These are specified by the Product Owner (or equivalent). When time-boxing is used, another backlog, one specifically for the time-box is required. In a flow model, the product backlog will contain both unrefined and ready to develop items.
It is important to have clarity on what is being built. The product backlog and, if time-boxes are used, the iteration backlog (see below) con
Requirements and Backlog Refinement
Ensure items to be worked on are ready to be worked on
The appropriate number of items on the backlog are ready to be worked on at the appropriate time
The sprint backlog only exists when time-boxing is being used as in Scrum or Scrumban. When a flow model is being used, the same objective must still be met, but the items are just the next ones to be pulled on the product backlog.
When time-boxing (e.g., Scrum, Scrumban) is being used this is the output at the end of each sprint. When a flow model is being used the team must ensure they have increments built on a regular basis.
Definition of Done mindset is one of not starting the implementation (or even the next step in a workflow) until you’ve determine how you will know you are done. This includes not only immediate functional acceptance criteria but can also adhering to standards and regulations, and meeting non-functional criteria such as creating or updating documentation and obtaining approval from specific stakeholders. We have found that starting work before making these criteria explicit is one of the leading causes of unpredictability and re-work.
A Definition of Ready mindset is one of not starting the implementation (or the next step in a workflow) until you’re ready to get it to Done. Over time, a team’s Definition of Ready will expand to incorporate additional readiness elements that the team has found to cause failure, rework, and other types of waste when not attended to.
Scrum is a partial implementation of Lean principles. It therefore encourages, perhaps even forces, several improvements. Lean Thinking prescribes transparency in intention. The items listed in this section are somewhat implied by Scrum, but Team Agility suggests making them explicit.
Commentary: The Scrum Guide tells us:
The heart of Scrum is a Sprint, a time-box of one month or less during which a “Done”, usable,
Sprints contain and consist of the Sprint Planning, Daily Scrums, the development work, the
During the Sprint:
The best way to accomplish this is to have small stories that are ready to be worked on when the iteration starts. If the stories are able to be completed in 3 days or less, and if the team focuses on finishing open ones before starting new ones, the chances of having completed stories be completed throughout the iteration rise.
This removes delays in workflow, feedback, getting & using information which create unplanned work. It also makes explicit that we shouldn’t have separate analysis, design, code and test sprints. Options: stories always need to be small In Scrum: Implied but not explicitly stated Unfortunately, this is not always understood. Understanding the why of a practice always makes it more likely it will actually get done
Use Visual Controls
Agile is intended to create a new culture. Many agilists talk about being Agile instead of doing Agile. The challenge is that it is difficult to change one’s being. While trust and respect is a key value of Agile, it should be a key value for every approach. The question isn’t if trust and respect is a good idea, it’s a question of how do you create it if the culture isn’t already demonstrating it. This chapter discusses how cultures are a result of management systems in an organization and how to change both the management system and thereby the culture of an organization.
Read the chapter How to improve your culture.