Insights at Agile 2014, Part III: Lean-Agile Development, 3rd Generation Agile

August 4, 2014 — Posted by Al Shalloway
The thinking that got us here won’t get us where we need to be. - Einstein

This Blog Post in a Nutshell

This blog is a culmination of some ideas that started at Agile 2013 and was presented in an open jam session in Agile 2014. Product developers should adopt a Lean mindset.They can then look at their situation, ask a few questions, and decide on the particulars of the development process adapted to their situation. While it may appear the choices are more complex than this, the reality is otherwise. There is much that both the common practice of Scrum and the Kanban Method leave out. And they both take non-Lean attitudes about different things, which they shouldn’t. The approach described in this blog post enables novice teams to be given a set of practices to start with, but a set that fits their situation a lot better than arbitrarily picking Scrum or the Kanban Method.

The Wrong Question: Use Scrum or the Kanban Method?

Scrum and the Kanban Method are two extremes on a spectrum of possible approaches, point solutions in a varied space. What accounts for the difference between them is the mindset that each holds. By 'mindset' I mean the set of beliefs one brings to solving one's problems.  This includes assumptions you make about how to solve problems and what you look at (and ignore) in solving them.  Scrum has a mindset of starting with a framework and removing impediments the framework exposes. The Kanban Method focuses on how to transform organizations with evolutionary change. (Waterfall, another point solution, had the mindset of prediction, being able to hand things off and achieving productivity through high utilization of people by working in phases on big batches.)

And this is the challenge: Each approach is based on a mindset that may not fit your situation. For whatever reason, these approaches have focused on practices based on fairly narrow mindsets.  While each approach applies well in certain situations, the mindsets on which they are based makes them limited as overall approaches. As we've learned more about Lean, a more generalized mindset has become available. The causes of challenges and opportunities for learning have deepened.  Understanding the Lean mindset, and then choosing the practices to follow is a much more effective approach than arbitrarily picking a point solution.

This is quite different from picking practices and putting them in your tool box and and not worrying about whether you are doing Scrum or the Kanban Method.  The challenge with this approach is that it ignores the fact that each of these mindsets (Scrum, Kanban Method, Lean) represent different toolboxes. Doing Lean practices within the Scrum “toolbox” (i.e., mindset) is not the same as doing Scrum within the Lean “toolbox.” The toolbox you start with really matters because it shapes the tools you use or would even be aware of.  Although the mindsets overlap, they are not the same.  This is graphically shown in the following picture:

The Better Question: What Mindset Should We Adopt?

Waterfall and Agile are different mindsets.  As Agile as advanced, there are several mindsets to choose from.  But which is best? Is there a best? We believe there is.  There is actually a mindset about mindsets though. In Scrum and the Kanban method, both take the attitude that one must select a limited number of things to look at.  After all, software is complex, so you can't look at everything?  Right?  Wrong.  Unexpected behaviors come about in complex situations more because relationships between things you are not attending to has side-effects you hadn't expected.   Lean suggests one should consider the value of teams, time-boxes, frameworks, managing flow and more before starting down a path.  Merely focusing on one or two of these is not an holistic approach and not systems thinking.  Let's look at three mindsets: classic Scrum (as defined by and the Scrum Alliance), the Lean Mindset (which is what we use at Net Objectives and what we have found works in most organizations), and the Kanban Method.  You should notice how Lean attends to all of the issues the others attend to.

Comparison of Mindsets

Classic Scrum

Lean Mindset

The Kanban Method

Explicit policies inside the team

Bad to neutral

Good and must have them

Good and must have them

Management’s role

Remove impediments for team.

Management is often considered not to be as committed as the team.

Responsible to improve ecosystems within which teams work.

Management is as committed as the team.

Responsible to improve ecosystems teams within which teams work.

Management is as committed as the team.

Regarding change

Do what it takes to implement Scrum’s practices.

See the current situation. Then look for possibilities for change that can immediately improve the ecosystem within which people work.

Use a combination of large and small change.

Avoid change at the start. People will resist it.

Use evolutionary change only at the beginning.

Cross-functional teams

Cross-functional teams are a core part of Classic Scrum.

Use cross-functional teams economically viable.

Cross-functional teams are orthogonal to the method.

Importance of Lean

Use Lean if the team finds it of value.

Lean laws must be understood. They are like gravity to bridge building.

Use Lean laws that relate to managing flow. Other Lean laws are optional.


Iterations are a core part of Classic Scrum.

Use iterations when they make sense.

Do not use iterations.

What to attend to


The value stream

Flow and WIP

Where to start

Start with the framework to fill in.

A holistic view with a lightweight method.

Consider immediate improvement to ecosystem after seeing where you are.

Start with the current situation with no change other tan creating visibility.

Note: Since kanban (small "k" kanban) sprang from Lean, and it is a core part of the Kanban Method, it may surprise people that the Kanban Method, while attending to some aspects of Lean, is not a true implementation of Lean-Flow. This is because the Kanban Method somewhat ignores until much later aspects such as load balancing before work items hit teams, the size of the work (e.g., using MVPs), and the structure people find themselves in. The Kanban Method is based on the assumption that any significant change up front, even when designed for the situation one finds oneself in, will result in resistance.  At Net Objectives, our experience is that this delays value delivered and that the risk of improvement petering out is much more likely to occur.

A Continuum of Approaches

Think of Scrum and the Kanban Method as existing on a continuum of approaches.  However, it is worth noting that the continuum is not complete.  Neither talk much about technical practices (although fortunately, Scrum has recently endorsed XP style technical practices).  When presenting the continuum of approaches, we'll add in test-first methods because we believe they are not only critical, but can often be a first step in Agile adoption. Our continuum therefore has additional practices outside of Scrum and the Kanban Method:

  • Scrum 
  • Scrumban
  • Scrumban with technical practices
  • Kanban with technical practices and teams
  • Kanban with technical practices but without teams
  • The Kanban Method

The bolded approaches are the ones that we at Net Objectives find can satisfy the needs of most organizations while providing the essential core practices. 

Here are points in the transition:

  • If you were following the Lean Mindset, you would probably start with Scrumban. Now, Scrumban is supposed to be an approach to transition from Scrum to Kanban but nothing says you have to go all the way. You could stop at the point of removing impediments and you would have Scrum with visibility, explicit workflow, managing Work-in-Process (WIP), including management, and having an appreciation that the ecosystem within which people works has a significant impact on them.
  • To Scrumban, add test-first methods. At a minimum, you should use acceptance test-driven development which is more of a change to the workflow order than it is a new technical practice. See How To Start With Acceptance Test Driven Development to understand how easy this can be. This is the minimal set of practices that a team doing iterations should have.
  • If you choose not to do iterations, you would be doing Kanban with technical practices and teams.
  • There are two reasons for doing iterations: assisting planning and creating an ecosystem that provides discipline for the team. Iterations - or at least a set, regular cadence - help planning. Iterations provide discipline to development teams because stories have to be small and delays (such as lags between testing and coding) become obvious.
  • If you cannot t economically create teams, then Kanban with technical practices can be done. 
  • Avoid starting with the Kanban Method. It often leaves opportunities for quick advancement on the table. Change is not always bad, but when change is imposed and it makes work and life harder, it is bad.

Picking a Framework / Method / Approach

Once we've adopted the Lean Mindset, and understand the continuum of Agile approaches within it, selecting what our practices should be is not very difficult. It only requires three questions:

  1. To what extent can you create cross-functional teams? (totally, partially, or not at all)
  2. To what extent do you need iterations to enforce the discipline to:
    1. Have developers and testers be in sync with each other
    2. Ensure developers work on small stories
    3. Make sure stories do not take longer than they should
  3. To what extent do you need to be able to predict what you will get in the next 1 to 2 weeks? 

What we do can be summarized in the table below. Start with the core approach. Then,

  1. The answer to the first question above identifies the column: Cross-functional teams can be totally implemented, partially implemented, or not at all.
  2. The answer to the second question identifies the row: If you need discipline of iterations or just want to be safe, use iterations. Remove them when no longer needed.
  3. If you need to make predictions then estimate your work and calculate your velocity. Even if you are not doing iterations you can see how much work you get done in a particular period.
Choosing an approach

Need for Iterations

Core Approach

Cross-Functional Teams

Partial Cross-Functional Teams

No Cross-Functional Teams


Scrumban with test-first

Core approach works

Use dynamic teams as needed within iteration

Cannot use

No Iterations

Kanban w/ test first

Use cross-functional teams

Use dynamic teams

Pure flow management

It is remarkable how simple this becomes when we stop trying to defend a particular point solution. The bigger picture becomes more visible and it is easier to see what to do. 

Our recommendation is to pick an approach and start with it following the suggested practices so there is a default set of agreements. Then, as you learn, decide how to transcend the practices and learn through gradual improvement taking advantage of the visibility in your work you have created.

Feedback Welcome

The approach described in this blog post has been building for a year. It just came together for me at Agile 2014. I have already written much about them in the following blogs:

I would love to get feedback on this thinking. This will likely be a topic I will discuss at the Lean Systems Society Reactor Conference. Please comment or ask me questions on the Lean-Systems Society Linkedin Discussion Group.

Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Al Shalloway

Al Shalloway is the founder and CEO of Net Objectives. With 45 years of experience, Al is an industry thought leader in Lean, Kanban, product portfolio management, Scrum and agile design. He helps companies transition to Lean and Agile methods enterprise-wide as well teaches courses in these areas.


Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Guy Beaver
Business and Strategy Development, Executive Management, Management, Operations, DevOps, Planning/Estimation, Change Management, Lean Implementation, Transitioning to Agile, Lean-Agile, Lean, SAFe, Kanban, Scrum
Israel Gat
Business and Strategy Development, DevOps, Lean Implementation, Agile, Lean, Kanban, Scrum
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Agile Design and Patterns, Software Design, Design Patterns, C++, C#, Java, Technical Writing, TDD, ATDD, Certifications, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Marc Danziger
Business and Strategy Development, Change Management, Team Agility, Online Communities, Promotional Initiatives, Sales and Marketing Collateral
Max Guernsey
Analysis and Design Methods, Planning/Estimation, Database Agility, Design Patterns, TDD, TDD Databases, ATDD, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile
Steve Thomas
Business and Strategy Development, Change Management, Lean Implementation, Team Agility, Transitioning to Agile
Tom Grant
Business and Strategy Development, Executive Management, Management, DevOps, Analyst, Analysis and Design Methods, Planning/Estimation, Innovation Games, Lean Implementation, Agile, Lean-Agile, Lean, Kanban