(This is Part I in a five part series.)
As the two of us compared notes about clients and their ability to use agile approaches, we realized something that surprised us. Although agile approaches owe their history to lean principles, we see very little lean thinking in many supposedly agile endeavours. We decided to explore that observation in this article.
We tried to keep it short and focused on four major issues we see in current “agile” teams:
- The focus on “agile” as a project framework instead of using lean thinking to manage both discovery and delivery.
- The pervasiveness of coaching as interpersonal skills, instead of coaching for technical or management skills to create excellence in the teams and management skills to create management excellence.
- Understanding pull as a kind of “personal freedom” (to choose what to work on) instead of a property of the system (a pull system)
- The focus on useless metrics such as velocity, instead of cycle time, lead time, and useful visualizations to make decisions.
When we say “lean thinking,” we mean the ideas of lean as applied to knowledge work, not to manufacturing. While the ideas of lean apply to all work, we might apply the ideas differently, depending on the context.
Why We Focus on Lean Thinking
When teams and organizations move to agile approaches, they often create “push” and “wishful thinking,” instead of real risk management. That push and wishfulness arises at all levels: the team, and the various leaders in the organization. Not just management as leadership, but the technical, product, and peer leaders across the organization.
When leaders push commitments to a team, especially without risk management, the team feels overloaded, overwhelmed, and “fails” to produce the necessary results.
Pushing commitments doesn’t help anyone.
Instead, we find that pull thinking—as a system— helps everyone get what they want faster.
Michael likes to say that pull is much more much more a property of the system than an attitude towards selecting work as we will discuss below.
Johanna likes to use pull as a way to see what we have in progress, what’s up next, and when we could take more work.
We both find that many teams, product people, and managers prefer to push more work to teams. Not because these people are bad. They don’t realize two important things:
- The more people try to push work into a System, the more cognitive load the people feel and the less they can complete.
- Pulling work creates better flow of items through the system and optimizes throughput.
That means too many people miss the ideas of throughput and flow when they create their agile approach.
And building on top of the idea of throughput, the idea of flow as the concept of not only managing the number of things that are completed, but also taking into account how predictable the order and the lead time of each piece of work is, goes beyond most agile implementations.
The order of the work and the lead time for each piece of work is so important. If your team has 10 items in the queue, and they’re not ordered correctly, your team might work on the first three items and finish them. However, items 4 and 5–the most important–still sit in the queue.
Flowing work through the team is one area of flow. Ordering the work to flow through the team is another area. That’s why ranking the backlog and the roadmap are so important. Ordering the projects well–that allows the organization to fulfill its need for revenue. As long as you make sure that things are –more or less– completed in the order in which they are started.
Flow works at all levels.
Lean Ways to Structure an Agile Project
If we take the ideas of flow and throughput, we can apply those ideas to projects.
Most agile teams say they use Scrum to organize their work. Scrum is a useful framework to manage a team’s WIP (Work in Progress), and create a cadence of planning, feedback, and retrospectives.
However, much of the way we see teams use Scrum does not match either the Scrum Guide or lean thinking.
We find that many teams improve their ability to deliver, regardless of literal adherence to the Scrum Guide. However, these teams miss several golden opportunities to use ideas of lean and flow to improve their work and their products.
We’ve seen teams miss these opportunities:
- Work as a team to limit WIP.
- Frequent kaizen-meetings, instead of waiting for a retrospective.
- Mapping their flow to a board that fits their needs, instead of using a generic board.
- Conscious local process variations instead of an unmodifiable default process
- Standups that focus on a team’s throughput instead of an individual’s work.
We’ll start with a team’s limit of their WIP.
Work as a Team to Limit WIP
Most agile approaches don’t specifically explain how a team should work together. That means too many teams try to work the same way they did before they started to use an agile approach:
- Each person worked according to their specialty
- They handed off work to the next person when they were done
- They took the next item of work.
- Everyone tries to be busy all the time
This approach to work looks and feels efficient. It’s not. In fact, it’s the slowest way to work because of all the handoffs.
Resource efficiency, where each person works independently, focuses on optimizing for each person. We’re accustomed to that, mostly as Western cultures. However, flow efficiency, where people optimize for the team, or even for the whole organization, challenges everything about our work, especially our reward systems.
Every time we see handoffs inside of teams, we see the risks of multitasking. Here’s an example: Amy, the architect, creates a high-level architecture and design document for an entire feature set. Ulysses, the UI designer, Mary, the middleware developer, and Peter, the platform developer, all work separately on their pieces. They finish. If they think about their work, they spend time to make sure all their pieces work. However, because they feel pressure, they might not. They hand all the pieces to Tina the tester.
Tina tries to test the feature (or features). She finds a problem in the UI, so she tells Ulysses. Ulysses drops his current work to fix the problem. Ulysses now multitasks.
Tina continues her testing and finds a problem in the platform. She informs Peter, who was deep in the middle of a difficult task. He pops up to address the problem Tina found. He needs three days to fix the problem because he didn’t anticipate it. He multitasks on this problem—and because the team “committed” to all that push work, he feels pressure to work on the other problems, too.
What if the team collaborated as a team to solve these problems and implement and test features together? We know of several ways to collaborate: pair, swarm, and mob. (Pairing occurs when two people work together on one item. Swarming occurs when the entire team works on one item, but each team member works first in their area of expertise. When they’re done, they pair or otherwise collaborate with another team member. Mobbing occurs when the entire team works on one item, all the requirements gathering, analysis, development and testing.)
If a six-person team decided to pair on everything, they would only have three items open at any one time. If that same team decided to swarm or mob, they would have one item open at any one time.
We see several levels to limiting the team’s WIP:
- Reject multiple items for one person at a time. Each person limits their personal WIP. I won’t take on more items, because I collaborate with my team members.
- Collaborate as a team => limit team’s concurrent WIP (necessary, not sufficient). We, as a team, choose to work together, to limit our team’s WIP.
- Reject excess work => Limit Team’s overall WIP. We choose to not add more work than our team can handle at one one time. If someone requests a new item, we, as a team, reject that item until we have the capacity to consider it.
When teams collaborate like this, they limit the team’s overall WIP.
The fewer items the team has open, the faster the team’s throughput, and the less multitasking the team does. The team proceeds as fast as it can.
In addition, if the team sees an opportunity for improvement, the team can take it. Continuously, not only in intervals. We recommend frequent kaizen meetings for that improvement.
Frequent Kaizen Meetings
Lean thinking introduces us to the need for quick feedback.
Like Toyota’s andon cord which enables (and empowers) every line worker to stop the whole process (of their manufacturing line) within 45 Seconds to prevent erroneous behaviour somewhere in the process to create more damage, these feedback-loops enable timely responses to things that need to be changed before work can proceed.
We find the same challenge in knowledge work. Waiting to solve the root cause of a problem until the next scheduled improvement meeting creates a huge waste of time and money. Those delays allow the issue to persist and possibly create more problems.
And as much as we deem retrospectives an absolute necessity, waiting with process corrections until the next retrospective comes up seems unhealthy to us.
Kaizen – consisting of Kai: change and Zen: good – is a Japanese term that characterizes a whole approach to problem solving as well as a very specific kind of intervention.
Even without taking the whole approach you can easily follow the idea of kaizen meetings. Those meetings are short interventions, driven by a “signal” – any observation that warrants immediate improvement.
Here’s a typical agenda for a kaizen meeting for a software team:
- Someone has a problem that prevents them from proceeding. They call for a kaizen-meeting.
- The entire team –and everyone directly concerned outside the team– agrees to meet now, or within about 15 minutes of the time someone recognizes the Problem.
- The team makes a quick assessment about the observation, its potential impacts and whether or not the organization needs to remedy the problem immediately.
- The team decides what to do for now, and possibly for later. Teams might even decide to use the retrospective later for more thorough problem-discussion and problem-solving.
- Usually these meetings take less than 15 minutes and end up with suggestions for improvements. These improvements might be in the team’s process, the team’s tooling, or even how they treat each other. (People might need some practice to create short meetings.)
How do teams use these ideas? Boards can help.
Boards that fit Needs
Different teams need different boards. We’ve seen teams that have very few interruptions. Those teams mostly create products.
On the other hand, we’ve seen teams that mostly do production support and manage to create new features infrequently.
We’ve also seen support workgroups where people mostly work alone—unless the time to solve the customer problem exceeds the agreed-upon service level agreements.
And, we’ve seen those teams in the same organization. That’s why each team needs its own board and to customize its own board.
Many managers seem to think they own a team’s board. The managers dictate the columns in a board, and who can change the board. That doesn’t work for any of these teams.
Instead, each team needs to create and manage its own board.
When teams create their own unique boards, they can choose how to use the three ideas of limiting WIP.
In this post, Part 1, we introduced the idea that lean thinking can enhance any work based on agility. However, the examples we presented in this part are not enough. Please read Part 2.
Part 1: How Much Lean is in Today’s Agile?
Part 2: Adaptability Enhances How We Work
Part 3: Looking at Systems to Enhance Outcomes.
Part 4: Explain dates to anyone with forecasts based on your historical data
Part 5: A Little Lean Can Create a Whole Lot of Positive Change
![[Case Study] Lessons from descaling 25 Scrum teams](https://www.agilealliance.org/wp-content/uploads/2024/12/descaling-teams-1200x630-1-150x150.jpg)
![[Case Study] Lessons from descaling 25 Scrum teams](https://www.agilealliance.org/wp-content/uploads/2024/12/descaling-teams-1200x630-1-300x158.jpg)
