Introduction
Lean-Agile at the Team: A Lean Approach to Scrum and Kanban describes how to use Lean-Agile at the team to be effective. Lean-Agile at the Team is a combination of Scrum, Kanban and eXtreme Programming (XP) based on Lean-thinking. It can be considered an operating model based on applying Lean Thinking to Agile at the team-level. Lean-Agile at the Team 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:
- Team Agility (this can be implemented as pure Lean or as a variation of Scrum and/or Kanban)
- Net Objectives’ Approach to Scrum
- 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 for ‘Lean-Agile at the Team’
A Lean Approach to Scrum (Article)
Achieve Cross-Functional Teams to the Greatest Extent Possible (Article)
Adopting SAFe® at Small to Mid-Scale (in Depth) (Article)
Common Challenges Faced by Teams New to Scrum, Remedies to These Challenges, and Related FAQs (Article)
Daily Standups (Article)
Essential Aspects for Training New Scrum Teams (Article)
Getting Out of the Trap of Scrum (Article)
Getting Started with Team-Agility or Scrum (Article)
Guardrails for the Team and Agile Coach (Scrum/Kanban Master) (Article)
How to Use Scrum in Mid to Large Scale Organizations (Article)
Introduction to Team Agility (Article)
Iteration Planning Meeting (Article)
Lean-Agile at the Team: A Lean Approach to Scrum and Kanban (Book in work) (Article)
Scrum as Example (Article)
Team Agility / Scrum Support System (Article)
Team Agility Templates Available (Article)
Templates for Team Agility (Premium Content) (Article)
Templates that are Useful for Scrum Teams (Article)
The Importance and Myth of “Consistency” (Article)
The Objective of Time-Boxing (Article)
The Relationship Between Acceptance Test-Driven Development and Design Patterns (Article)
The need to understand the principles that drive your practices (Article)
Tips for Agility (Article)
What is Agile at Scale? The Different Approaches to Achieve It | FLEX from Product Management to the Team (Article)
Why Agile Coaches Need to Know Both Scrum and Kanban (Article)
Why You Should Grow Your Own Scrum Masters Instead of Bringing in Outside Scrum Masters (Article)
Why You Should Rethink How You Are Trained in Scrum (Article)
