Team Agility: Lean-Agile at the Team

Related Pages

Related Articles

Recommended Resources

Provide Feedback

Team Agility is essentially taking the principles of Lean-thinking, mixing in the intention and lessons of Agile and doing what works for your team. 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 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: We are not claiming a ‘new and improved’ approach here nor only one we do. We know of dozens of great consultants/instructors who follow essentially what we describe as Team Agility. 

Net Objectives is framework/method agnostic. We don’t subscribe to any particular approach. We base Team Agility on what works – on key principles that apply everywhere. These are:

  • delays in workflow (waiting), feedback, and between getting and using information creates additional work
  • small batches inherently remove these delays
  • visibility of work, workflow and workload improves our collaboration
  • systems-thinking
  • double loop learning
  • have a focus on quality (both of the information you are using and the work being produced)
  • trust people to get their job done if you put them in a healthy environment
  • manage via a pull (kanban) system

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 viable.​

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.

Providing consistent behavior across an organization

Large organizations have the dilemma of wanting consistency across their organization while enabling teams to self-organize. Team Agility solves this problem by providing common objectives and approaches to the teams. While teams will self-organize they will achieve consistency by striving to achieve similar objectives. To do this requires the following:

  • Be 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.
  • Incorporate core practices that have been demonstrated to work.
  • Tailor practices to the team’s abilities, culture and context.
  • Work within the context of the enterprise.
  • Adjust when new practices would be more effective.
  • Be based on principles.
  • Attend to the team’s culture.

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 and Team Agility

How to Use Scrum in Mid to Large Scale Organizations (Article)
Introduction to Team Agility (Article)
Iteration Planning Meeting (Article)
Learning Team-Agility with Scrum & Story Writing with Test Specifications (Article)
Scrum-But: Not Using Cross-Functional Teams (Article)
Team Agility: Lean-Agile at the Team (Article)