Exploring Team Agility With ScrumHere are some useful resources for those who have adopted Scrum:
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:
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:
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.
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:
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:
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)