Search
Close this search box.
Search
Close this search box.
Search
Close this search box.

Lean/Kanban approach to Teams

Facebook
Twitter
LinkedIn
Pinterest
WhatsApp

To Team or not to Team?

If you look at the definition of Kanban or Lean, you wouldn’t find teams anywhere there.

If you look at the Agile Manifesto, you can find “The best architectures, requirements, and designs
emerge from self-organizing teams”

Scrum is quite clear about the topic (Quoting the Scrum Guide)

"Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to 
accomplish their work, rather than being directed by others outside the team. Cross-functional 
teams have all competencies needed to accomplish the work without depending on others not 
part of the team. The team model in Scrum is designed to optimize flexibility, creativity, and 
productivity."

So, if you are a manager of an organization on the Kanban train of evolutionary improvement, what does it mean for team structure? Should you keep the current structure? Adopt the Scrum Feature Teams concept. Do something else altogether? How should you organize your people to be as effective as possible in delivering value for the stakeholders?

Teams as an emerging property?

I personally believe that even if kanban the tool doesn’t talk about teams (obviously since it’s just a visualization and process-driving tool), despite the fact that the Kanban Method for evolutionary change doesn’t talk about teams (obviously since it starts from where you are, respecting your current structure, letting changes be pulled from actual need), more effective patterns for team formation will emerge when Kanban is really used.

At their core, Teams affect communication bandwidth. They partition the organization to enable increased communication bandwidth among people in a team while counting on the fact that communication bandwidth to people outside the teams is not that important.

Since we are talking about people, not network nodes, teams also allow communication bandwidth to increase, the longer the team is working together, due to the team formation model. I recently read “The Talent Code” where the behavior of our brain around learning new skills using myelin to wrap neurons to increase bandwidth reminded me of how teams behave.

So it seems like teams can really increase our effectiveness, and everyone in a reasonably sized organization cannot even bear to think about getting rid of the partitioning, right?

Well, some of the Kanban thinking says that since Kanban massively reduces coordination costs via hyper-visualization and the pull system, the size of teams can increase significantly. Since we advocate using classes of service to allocate capacity to demand, thereby maintaining flexibility, we shouldn’t allocate people to demand.

The main reason not to go to teams is that teams might be local optimization. If our workload/demand was certain, and the uncertainty as to what effort/ specialty is needed to deliver it was low, we could build the teams that optimize our performance. If that workload/demand didn’t vary over time, we could maintain the same teams and still have optimal effectiveness. But since in most environments we are facing a complex system with uncertainty/variability in the workload/demand, as well as the implementation effort/ specialty required, it seems like sustaining stable teams will cost us in some optimization.

Team Modes

When asked to provide my view on this question of team formation and Kanban I described the following progression:

  1. Functional/Component Teams based on specialization
  2. Teams On-Demand – whenever pulling a new Feature for work, associate the relevant people with it. They will deliver that feature, and after a few weeks return to their home teams. This approach provides lots of flexibility but typically has relatively high coordination costs. It also doesn’t really benefit from the improved communication bandwidth among the team members that you get from persistent teams. This is very similar to the Feature Driven Development team mode by the way.
  3. Project/Initiative Teams – whenever pulling a new Project/Initiative for work, associate the relevant people with it. They will work together as a virtual team for the duration of that project/initiative, and after a few months, return to their home teams. The benefits of this approach are lower coordination costs as the teams don’t change that often. In addition, the people working towards the same business goal are working together. The communication bandwidth increases as well over time, as well as the feeling of purpose and alignment. On the other hand, flexibility goes down. It is harder to shift people into projects/initiatives. It is harder to shift people out. If there is significant variability in the specialization required along the life-cycle of the project, selecting the right team becomes hard. If you work on the versatility of your people, or already have a great group of generalizing specialists, this will be less of a problem. It can also be addressed by keeping a slack of several people working outside of project/initiative teams, that can be easily shifted in and out of activities on demand. It makes even more sense if those people are your experts/heroes. I’m seeing this mode in action in several organizations.
  4. Teams pull work – The next mode is where you create stable work cells that are able to handle almost everything you throw at them. These work cells stay together as the main organizational unit and pull work based on the next business option the organization wants to exercise, regardless of whether it is to accelerate an existing initiative or start something new. Here the communication bandwidth grows stronger and stronger. The flexibility and agility to shift business priorities and help swarm to work in the process remain quite high, but the internal team flexibility remains an issue. The same slack of people not associated with teams can help here as well. I’ve seen this specific mode in action in several organizations, and it works great, assuming you are ready for the change.
  5. On-demand teams – Wait, didn’t I mention this one? Yes, I did. The difference here is that assuming you somehow have a tightly knit group that already managed to create lots of communication bandwidths among the WHOLE group, you can have a win-win. Total flexibility and global optimization. This should be the holy grail of any manager of about 20-40 people I would imagine. A force to reckon with…

Mixing it up

You don’t have to decide on one model. Not all work is created equal, so not all teams should follow the same structure. Some interesting examples:

  1. 80% on-demand, 20% focused on an initiative
  2. 80% on-demand, 20% cross-functional work cell (A-Team)
  3. 80% project teams, 20% on-demand able to swarm to a team in distress and help, or join a team to teach them some new skill as appropriate.

Evolutionary Change

Some organizations will jump in, create work cell teams, and start working. I’ve seen it in action, and when you REALLY have enough energy in the organization to make this maneuver, by all means, go for it.

In other cases, you will not have enough energy. Or you will THINK you have enough energy, but reality will hit you in the face when all the middle managers/team leads that led you to believe they are on board are not that supportive once it is time for action and for supporting the actual new structure.

So think hard about what is your case. And if you want to go for a more evolutionary change mode, consider the following:

  • Start with on-demand teams
  • Pilot one initiative/project team – especially useful when you have a risky initiative with a lot of uncertainty and dependencies, that is mission critical. Assign the success of this team structure to one of your best and most trusted people, if not yourself. Whether he is the Coach, the actual Lead, or something else is secondary. The important thing is that he will be in charge of making the team structure work, and together with the team making the learning from that available to the rest of the organization
  • Move to more and more initiative teams as necessary
  • When a project/initiative finishes consider turning the team to a work cell to pull more features in that area, or more features in general
  • Ideally, teams will have the capability to take on almost all work. If not, use a talent matrix showing what teams can do what and what gaps to invest in. As well as a talent matrix inside a team that will help teams grow some internal versatility (note not everyone on a team needs to know everything at the same level)

Cautionary Notes:

When creating teams be careful not to spread yourself too thin. If you have too many small teams it might be an indication you are not managing flow effectively at the Initiatives/activities level. I love teams of 4-5 people by the way.

If you find many people need to be on many teams, you have a real problem. It is ok for a minority of people, especially specialists, to be needed by many teams. Maybe they should stay as auxiliary on-demand while spending some of their capacity offloading knowledge to the teams. But if it’s not a minority, then you really need to work on versatility, or the on-demand might be a better fit. The whole point of the teams is to create communication bandwidth. Without that, they’re just overhead.

Conclusion

I presented a couple of team modes here, as well as one way you can use them. This is really context-specific stuff, so I cannot tell what will work for your case. But I hope the modes help you relate the Lean/Kanban effectiveness principles to the options of team formation.

This blog was originally published on my personal blog way back… I think it is evergreen and even more appropriate these days when we’re talking about Professional Scrum with Kanban

Subscribe for Email Updates:

Categories:

Tags:

AI Artificial Intelligence
Scrum With Kanban
Implementing SAFe
Artificial Intelligence
Nexus and SAFe
A Kanban System for Software Engineering
ScrumMaster Tales
Agile Techniques
What Is Kanban
Releases Using Lean
Lean and Agile Principles and Practices
WIP
Kanban Game
Jira admin
RSA
Product Management
Introduction to Test Driven Development
Jira Cloud
Quality Assurance
Agile for Embedded Systems
NIT
Jira Plans
Lean Software Development
Elastic Leadership
Agile Program
Lean Agile Basics
Continuous Delivery
Agile Release Planning
Test Driven Development
Operational Value Stream
Agile Testing Practices
RTE
Risk Management on Agile Projects
Implementation of Lean and Agile
Agile Development
Sprint Retrospectives
SA
Lean Agile Organization
Kanban 101
Nexus vs SAFe
Jira
Agile Project Management
Professional Scrum Product Owner
System Integration Environments
Scrum Master
predictability
Enterprise DevOps
Release Train Engineer
Covid19
Scrum Guide
Lean Budgeting
Risk-aware Product Development
ATDD
Nexus and Kanban
Software Development Estimation
Accelerate Value Delivery At Scale
Risk Management in Kanban
SAFe Release Planning
Engineering Practices
EOS®
Scrum Primer
Agile Marketing
agileisrael
Scrum
Agile Product Development
ART Success
Agile Release Management
DevOps
LAB
Agile Assembly Architecture
IT Operations
Agile Basics
AgileSparks
Slides
Built-In Quality
Agile India
Agile Product Ownership
Kanban Kickstart Example
Product Ownership
ALM Tools
Agility
Atlaassian
Lean-Agile Software Development
LPM
Pomodoro Technique
Development Value Streams
Code
An Appreciative Retrospective
Large Scale Scrum
AI
PI Planning
Value Streams
Lean and Agile Techniques
Business Agility
Certification
Continuous Integration
Professional Scrum Master
Video
System Archetypes
Change Management
POPM
LeSS
Self-organization
Introduction to ATDD
Frameworks
speed at scale
Lean Agile Leadership
Kanban
Lean Startup
GanttBan
User stories
Agile Delivery
Daily Scrum
SAFe DevOps
Process Improvement
Amdocs
Agile Mindset
BDD
Managing Risk on Agile Projects
Planning
Agile
Portfolio for Jira
The Kanban Method
Story Slicing
Agile Project
Scaled Agile Framework
Agile Games
Kanban Basics
Effective Agile Retrospectives
Entrepreneurial Operating System®
Professional Scrum with Kanban
Managing Projects
The Agile Coach
ATDD vs. BDD
Kaizen Workshop
Kaizen
Scrum.org
Agile Games and Exercises
Hybrid Work
Agile and DevOps Journey
Keith Sawyer
Advanced Roadmaps
ROI
Iterative Incremental Development
Nexus
Scrum Values
SAFe
QA
Legacy Enterprise
Lean Risk Management
Spotify
Agile Contracts Best Practices
Continuous Improvement
Systems Thinking
Applying Agile Methodology
Sprint Iteration
Scrum Master Role
Perfection Game
Software Development
Scrum and XP
Nexus Integration Team
Webinar
Agile in the Enterprise
Lean-Agile Budgeting
SPC
Agile Outsourcing
Limiting Work in Progress
Games and Exercises
Agile Exercises
Manage Budget Creation
Coaching Agile Teams
Team Flow
ARTs
Atlassian
Certified SAFe
Continuous Planning
PI Objectives
Agile Risk Management
TDD
Rapid RTC
Principles of Lean-Agile Leadership
Lean Agile Management
Achieve Business Agility
Agile Israel
chatgpt
Program Increment
Agile Community
Acceptance Test-Driven Development
lean agile change management
RTE Role
Presentation
Sprint Planning
Lean Agile
System Team
speed @ scale
Reading List
Tips
Legacy Code
Continuous Deployment
Agile Israel Events
AgileSparks
Logo
Enable registration in settings - general

Contact Us

Request for additional information and prices

AgileSparks Newsletter

Subscribe to our newsletter, and stay updated on the latest Agile news and events

This website uses Cookies to provide a better experience
Shopping cart