FLEX at the Team Level: Team Agility

FLEX

Steps of FLEX
  1. Understand Your Value Stream
  2. Typical Challenges and Intentions They Hurt
  3. FLEX Solutions
  4. Creating a Roadmap with FLEX
FLEX and special topics

Exploring Team Agility With Scrum

Here are some useful resources for those who have adopted Scrum:
  • 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 is a specialized version of Team-Agility for Scrum that incorporates Systems-Thinking and Agile Product Management.
  • 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' Scrum Support System provides templates, solutions to common challenges and more for those doing Scrum
Recent updates
Provide Feedback

Team Agility is an operating model based on applying Lean-Thinking to Agile at the team-level. Team Agility enables companies to have consistent intentions and interactions across all of their teams while allowing for each team to tailor it to their needs. 

There are many options to use at the team level – Scrum, Scrumban, Kanban, and homegrown methods. If we were not concerned about where the teams we were training were, we’d use what we call Team-Agility. Team-Agility is using Lean-Thinking as a basis and folding in Scrum, Kanban and XP practices as they are appropriate. But many people want to build around Scrum. The Scrum Guide tells us that “Scrum’s roles, events, artifacts, and rules are immutable.” At some point, however, we have found that teams need to change the framework. Of course, at that point they are not technically doing Scrum. Therefore, when someone wants to “do Scrum” we start out with thinking of Scrum as an example of what you could do with Team-Agility.  This is essentially Scrum directly taking advantage of Lean-Principles as well as considering the bigger picture of Agile Product Management in how teams work off of their backlogs.

We therefore have three different approaches:

  1. Team Agility (this can be geared towards Kanban if desired)
  2. Net Objectives’ Approach to Scrum
  3. Scrum as Example (regular Scrum but taught as a drawer in a toolbox)

An overview of Team Agility

There are two ways to come to Team Agility. The first is to consider what practices are suggested by Scrum, XP, and Kanban. The second is to understand what needs to happen and decide which of those practices to do. Since learning is easier when we contrast what we’re doing with what we could be doing, we’ll describe Team Agility in the first way.

Note: “Team Agility” is not a “new and improved” approach. We know of dozens of great consultants and instructors who follow essentially what we describe as Team Agility. At Net Objectives, we are agnostic about frameworks and methods. We don’t subscribe to any particular approach. We base Team Agility on what works, on key principles that apply everywhere.

Here are some of the key principles on which Team Agility is based.

The challenge is that although these principles apply everywhere, how to use them differs based on the context you are in. We have been using Scrum, XP and Kanban from near the inception of all of them. One observation we’ve made is that many of the practices of each of those should be done regardless of your situation (albeit the exact way of doing the practice will vary according to your context).

This is shown in the diagram below. We use the terms ‘Lean-Scrum’, etc. to indicate we are referring to these frameworks/methods being used with a Lean context.

For all the discussion about Scrum vs. Kanban it may be surprising that most of the practices of each should be used by anyone doing either. In our view, all of the XP practices should be being used as well. They are left out of the center only because it is often difficult to get teams to use them immediately. Deciding on the flavor of Team Agility depends upon your context. Here are some examples:

  • Mostly cross-functional teams doing IT or product development who are new to Agile. It is likely that sprints will be useful to provide discipline.
  • Individuals doing maintenance work. Since planning may not be viable here, a flow model would be more appropriate. Use cadence to coordinate with other groups.
  • Teams doing IT/development but not able to form into cross functional teams. Attempt to create teams to the extent viable but adopt a flow model with cadence to coordinate with other teams.

XP practices should be adopted as soon as it is viable to do so.​

Essentially, if you are in a situation where you have a team, can plan and can use the discipline of sprints, then doing Team Agility as a Scrum like process makes sense. If any of these three characteristics aren’t present, you do a flow like process. But in all cases do those practices that make sense for everyone.

Creating consistent behavior across an organization

While there is value for consistency, there is also risk.  Let’s first explore the intentions of consistency and the risks involved in different ways of achieving them.  The value of consistency would be:

  • people using good methods
  • enabling people to move from one team to another easily
  • creating information flow across the organization that everyone can use

In achieving these, however, we must recognize that different parts of the organization are different. That different contexts require different solutions. This includes attending to the cultures of the teams.

Large organizations therefore have the dilemma of wanting consistency across their organization while enabling teams to self-organize. While consistency in process may not be effective, consistency of intentions and attitudes often are. These would include:

  • Being business driven; that is, be committed to working on those items that realize business value quickly. This requires a focus on business value not merely the teams.
  • Incorporating core practices that have been demonstrated to work.
  • Tailoring practices to the team’s abilities, culture and context.
  • Working within the context of the enterprise.
  • Adjusting when new practices would be more effective.
  • Having practices be based on principles.

The objectives of the practices

Scrum, Kanban and eXtreme Programming are all defined by values and practices. But not all practices are the best everywhere. It’s important to understand the intention of the practices. Go to Team-Agility Objectives of Practices.

Why Team Agility is especially important at scale

One advantage of taking the Team Agility approach is that everyone is on the same page, they’ve just adjusted their methods to their context. Although we don’t recommend moving people around willy-nilly, when people do have to move, they will be much more able to adapt to their new team because the principles driving it will be the same as where they came from. The explicit workflow endorsed by Team Agility will also make it easier for newbies to understand the agreements of the team.

The incorporation of managing WIP for all teams will also enable greater visibility into when teams will be available as well as making all teams more uninterruptible when it is required. Be clear, lowering interruptions is critical, but to pretend they won’t happen is poor planning.


All resources in FLEX at the Team Level: Team Agility

Achieving Cross-Functional Teams to the Greatest Extent Possible (Article)
Common Challenges and Their Remedies Faced by Teams New to Scrum and Related FAQs (Article)
FLEX at the Team Level: Team Agility (Article)
How to Use Scrum in Mid to Large Scale Organizations (Article)
Introduction to Team Agility (Article)
Iteration Planning Meeting (Article)
Net Objectives' Approach To Scrum (Article)
Scrum with Agile Requirements: Achieving Sustainable Agility (Article)
Templates that are Useful for Scrum Teams (Article)
What You Need to Get Started with Scrum (Article)
What is Agile at Scale? The Different Approaches to Achieve It | FLEX from Product Management to the Team (Article)
Why You Should Grow Your Own Scrum Masters Instead of Bringing In Outside Scrum Masters (Article)