Introduction to Team Agility

Lean-Agile at the Team: A Lean approach to Scrum and Kanban (online book)

  • Introduction to Team Agility describes how to do Team-Agility but also provides insights on alternative practices you may find useful in Scrum.
  • Net Objectives' approach to Scrum uses Scrum as a foundation within the context of Lean-Thinking while incorporating Agile Product Management.
  • Starting with Scrum describes how teams should start learning Scrum.
  • Scrum as Example is a way to start simple by thinking of Scrum as the top drawer of a big toolbox, only going into the bigger toolbox when needed to solve problems.
  • Net Objectives' Team Agility / Scrum Support System provides templates, solutions to common challenges and more for those doing Scrum
Provide Feedback

Contents

Introduction

The objectives, theory and values of Team Agility

Describing Team Agility from a Scrum perspective

Roles

Planning and managing the work

Getting and responding to feedback

Artifacts

Explicitly use Lean Thinking

Understanding culture and change

Introduction

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.

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.

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 objectives, theory and values of Team Agility

The objectives of Team Agility

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.

The theory of Team Team Agility

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.

For more, see Systems Thinking Philosophy as it Applies to Frameworks, Methods, and Approaches.

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 values

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.

Anti-patterns of not taking this approach

Here are the anti-patterns, the patterns of undesirable behaviors, that result when you not take the approach describe 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.

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.

Describing Team-Agility from a Scrum perspective

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. But, since Team-Agility is intentionally an operating model, so in it, as well as our approach to Scrum, other ways of manifesting these intentions will also be presented. The main difference between Team-Agility and Scrum is mostly that Team-Agility does not use Scrum terminology while Scrum does.

Roles

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.

Options:

  • Scrum: Product Owner, Development team, Scrum Master
  • Team-Agility: Use Scrum’s terms or use the roles in place that people are attached to

The Product Owner (or equivalent)

Objective: Have a clear liason 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:

  • be available to the team to answer questions
  • help the team understand the definition of done (DoD) for each story
  • manage and refine the team backlog as needed
  • sequence the work on the team backlog appropriately and coach the team if they are not working in the proper order
  • assess and accept work completed
  • work with release management
  • In larger development groups they may work with Product Managers in order to determine what the business stakeholders need.

See more on the product owner’s role here.

The Team Agility Coach

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.

  • Objective: Have a coach for the team to assist them in improving their definition of workflow and in following it. They are responsible for being the liaison between the team and the rest of the organization.
  • Why: Development team members tend to get heads down on their work. Someone needs to be attending to continuous improvement as well as people following their own agreements with each other. Sometimes team members will get stuck but want to push through when an outside observer can notice and help them
  • Options: Having a Team Agility Coach be responsible for shepherding the team, creating a trustful environment, facilitating team meetings, asking the difficult questions, removing impediments, making issues and problems visible, keeping the process moving forward, and socializing Lean-Agile within the greater organization. They will also:
    • 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

The Development Team

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.

Planning and managing the work

Cadence of the team

  • Objective: Have minimal delays from the start of working on an item until its completion.
  • Why: Short cycle time of work minimizes delays and waste. It also improves feedback.
  • Options: Decompose work into small stories before designing and writing stories.
    • If using iterations: focus on having any stories that are started in an iteration to get completed in the iteration
    • If using a flow model: have a focus on finishing stories prior to starting new ones

A sprint provides a time-box within which to fit work. This “time-box” is from the time after planning to the time we set for the end of work. The sprint probably has another day for the demo and retrospection. Scrum’s time-boxing has some interesting side effects which are quite useful such as the following.

  • Stories must be small enough to fit into the time-box. Rather, they should be small enough to take no longer than a third to half of the time-box. We prefer even shorter.
  • A set time to see what’s been done and stop working whether done or not.
  • A reality check on if stories have been completed or just coded.
  • A deadline that keeps things a little bit urgent but not too urgent.
  • Provides visibility of the work going into the sprint and what is being accomplished
  • Provides the rate at which work is being accomplished (velocity)
  • Gives us a planning cycle
  • Creates focus on what is to be worked on
  • Provides discipline to the team

Cadence means to have a regular beat. There are two different approaches to accomplish this:

  • Use time-boxing (called a Sprint in Scrum)
  • Use flow with a regular time-frame to have events occur. This is the common approach in Kanban.

In Scrum, sprints provide the regular beat. The start and end of a sprint provides timing for the following.

  • Ensuring the product backlog is ready for the sprint
  • When to do planning for the sprint
  • When to see what has been completed
  • When to demo the work of the sprint
  • When to do a retrospection

Scrum uses the sprint to set the cadence of the above actions. Scrum’s structure provides a great degree of discipline for the teams. This is one reason Scrum is a good starting point for many teams wanting to become Agile.

See Creating the beat for the team.

Estimation

This section has been put in its own chapter. Read it here.

Manage WIP by Focusing on finishing

  • Objective: Speed delivery, lower unplanned and wasteful work, create a focus on completion.
  • Why: Too much WIP causes delays and unplanned work.
  • Options: Focus on finishing and managing work in process.

See full chapter Manage Work In Process (WIP) By Focusing on Finishing.

Planning the work

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

Getting and responding to feedback

Keeping people aligned on a daily basis

Teamwork requires people know what each other is doing, what they can do to help, and who they can call on to help.

  • Objective: Have everyone know what each other is doing so they can help out when needed.
  • Why: Without awareness of what each of the team members are doing they can’t really be a team. It also won’t be possible to pivot as needed.
  • Options: Daily retrospectives (we no longer call these stand-ups out of respect for disabled people and daily retrospectives are more intention revealing) are recommended unless mob-programming or paired programming is being done and they are not necessary. Kanban style boards with explicit workflow, while not eliminating the need for the stand-ups, can make standups shorter.
  • In Scrum: Daily stand-ups.

Feedback on the work

  • Objective: Get feedback from Product Owners and make any necessary corrections on direction. Also, get analysis, design, code and test done in short cycles to get feedback on each step.
  • Why: Even with good requirements until the product is demonstrable there is always risk that the wrong thing is being built or something better might be better.
  • Options: Demonstrate the software on a regular basis. if the Product Owner is close to the team frequent demonstrations is advisable. Demonstrations can still be done on a regular cadence for people other than the Product Owner.
  • In Scrum: Feedback from Product Owners at end of sprint. Feedback on analysis, design, code and test accomplished by having to complete stories in a sprint.

Continuous improvement

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:

  1. Continuously
  2. Daily
  3. On a cadence

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.

Artifacts

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.

Product Backlog

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

  • Objective: Items are not ready to be worked on until it is known what it takes to complete. This includes having success criteria and knowing what capabilities it takes to complete them.
  • Why do it: Working on well-defined, understood, right-sized items improves both effectiveness and efficiency.
  • Options: Use Given-When-Then or the equivalent. DoR includes size limits, dependencies DoD includes testable specifications. This requires the use of Definition of Ready and Definition of Done.
  • In Scrum: Not discussed, but implied.

The appropriate number of items on the backlog are ready to be worked on at the appropriate time

  • Objective: Have enough backlog items be ready to be pulled from as appropriate. If Scrum is being used then at the beginning of iteration planning enough stories need to be ready to work on that will sill the sprint. If a flow model is being used the backlog should be refined in a just-in-time manner to give the team work to pull from as needed.
  • Why: If too many items are ready then too much refinement will have been done and there is possible wasted effort. If too few are ready then the team may not have enough work to pull.
  • Options: Refine the backlog on a periodic or continuous basis.
  • In Scrum: Not discussed, but implied.

Iteration (Sprint) Backlog

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.

  • Objective: Have a list of stories that the team can work on and finish by the end of the sprint.
  • Why: Creates focus. Enables planning. Provides visibility on what needs to be done next.
  • Options: Best to have items on the sprint be focused on creating value either through delivery or feedback.

Building the increment

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.

  • Objective: Create potentially shippable product on a regular, frequent basis.
  • Why: If it can be released, value can be realized. If it can’t, feedback on what is being built can be achieve.
  • Options: Start with minimum business increments and create vertical slices from it (use business evolution).

Artifact transparency

Definition of Ready and Done

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.

Explicitly use Lean Thinking

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.

Mitigate and manage dependencies across teams

  • Objective: Minimize the cost of dependencies across teams.
  • Why: Dependencies between teams usually result in delays in the workflow and can create additional work and unpredictability.
  • Options: There are several different approaches that can be taken to eliminate or mitigate dependencies:
    • Using technical practices. The use of mocks, quality design and proper use of dependency injection can either eliminate or at least mitigate many technical dependencies.
    • Changing the structure of the teams. Core teams that are not quite cross-functional can often be temporarily supplemented with people on the teams on which they are dependent upon.
    • Improving the workflow. By creating visibility of the workflow and managing queues between the teams, the adverse affects of these dependencies can be mitigated.
    • Large scale planning. Events similar to SAFe’s program increment planning event can identify dependencies across teams and help teams prepare for their management.
  • In Scrum: Scrum does not discuss cross-team dependencies.

Use Visual Controls

  • Objective: Use visual controls to:
    • show rate of completion of work (e.g., burndown charts)
    • see if stories are being worked in proper order
    • see time taken for each step (e.g., CFD)
    • see type of work being done
  • Why: Executives, managers and others dependent upon the team need to see their progress. Visual controls helps the team stay coordinated
  • Options: Burn-down / burn-up charts. Cumulative flow diagrams. Special charts as needed.
  • In Scrum: Scrum uses information radiators, not visual controls.

Have visible and explicitly-defined workflows

  • Objective: Improve collaboration within teams and make it easier for people to move from team to team when required.
  • Why: Teams have a great deal of tacit knowledge about their work. While many members may believe that they understand the agreed upon process, experience shows otherwise. Visible and explicitly defined workflows convert this tacit knowledge into explicit knowledge. This also makes it easier for people to move from one team to another.
  • Options: The use of Kanban boards (even when doing Scrum) accomplish this with very little overhead. The test is if someone outside of the team can read the board for a few minutes and then after a 10 minute conversation with someone on the team can understand what the team process is.
  • In Scrum: Scrum does not discuss explicit workflows.

Test-First at the team

Understanding culture and change

Improving your company’s culture

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.