Framework Tunnel Vision

August 9, 2013 — Posted by Al Shalloway

Disclaimer: I could have named this framework/method/process tunnel vision, but that seems a bit redundant.  So don’t infer I mean to pick on any Agile approach that is a framework over one that is called a method or a process.  I am just using the word framework generically.   For the purposes of shortness, whenever I use “framework” in this blog, pretend I’ve said “framework/method/process/…”.

I have been involved in most of the Agile and Lean methods in the last 15 years.  As one might expect, all can be misused.  But a common challenge with all of them is a tendency for practitioners of one to not attend to things that are not part of their framework.  This shouldn’t be surprising.  There is no end of evidence that when we focus on one thing we don’t notice other things, no matter how obvious they are.  Anyone who has not done the selective attention test counting how many times the white team passes the basketball (click here to view) should do so now.  Seriously, stop reading and do the test (takes only a couple of minutes and is really cool).  If you haven't seen this and continue, , as if you continue, you will lose a great experience as I am going to discuss it and spoil it for you.

Blank (watch video)

Blank (watch video)

Blank (watch video)

OK.  Spoiler alert, but I’ve warned you.  So why do most people not see the gorilla?  Because they were attending to something else.  We see this selective attention in both Scrum and the Kanban Method (which I will heretofore call LKU Kanban – see Why We Need a New Name/Meaning for Kanban).  In Scrum, it is almost axiomatic that teams new to Scrum won’t attend to limiting the amount of work on their plate.  Most new Scrum teams open up way too many stories and end up with not much finished their first sprint.  In hindsight it is obvious what they should have done, and most typically correct.  But why do they miss this in the first place?  Also, why do they not notice other things (like you need a contextual view within which to work in order to scale)?

But, let’s not pick on Scrum.  We see something similar happening to those who follow LKU Kanban (aka Kanban Method).  In LKU Kanban practitioners are told to limit work in progress (WIP) and use cycle time as a measure of how they are doing.  And they do.  Progress is often made this way – but very often other improvements are missed because of this focus.

Here’s a pattern I have seen from several teams who have been taught LKU Kanban as an approach.  A group has two teams – a front-end and a back-end team.  Cycle time appears to be relatively stable except for some outliers.  When discussing what is happening, it is often mentioned that these outliers are considered the result of special causes.  I am impressed that the people relating these stories are doing the Kanban Method (er LKU Kanban) so well they are measuring their results and understanding the difference between common cause and special cause. 

Given my experience as a Kanban person, they ask me what to do. Now, to be clear, my 7+ years with Kanban are not limited to LKU Kanban.  I mostly practice what I call Lean-Kanban, which, at first glance anyway, is somewhat equivalent to what Karl Scotland is calling Kanban-Thinking.  This means taking advantage of using Kanban as a flow management tool, but attending to all four methods of managing flow: 1) workload being pulled from, 2) team structure, 3) workflow order, 4) managing WIP.  The order I put these in is not arbitrary.  This is the order that Taiichi Ohno (the creator of the Toyota Production System) discusses one should consider things in.  Interesting that LKU Kanban does #4 first (something, by the way, that I believe is a mistake, but that’s not the point here).

In any event, the person I am talking to is wondering how to manage WIP better.  I am looking at other possibilities.  I am noticing that teams are not present in their workflow.  The team-leaders I talk to are only noticing the workflow and the queues that they are managing.   After a very brief discussion (1-2 minutes), the solution is clear.  The outliers aren’t outliers at all – they are a third value stream – one where front-end and back-end folks need to be involved.  The solution is also equally obvious – when a work item is pulled that requires a front-end and back-end person, make sure both are available and have them pull the work together.  I see this solution, not because I am smarter or more experienced, but because I am looking at a broader range of aspects of the problem

So why don’t people see this?  Well, the common answer is that people are too close to their own problems and that is why you bring in consultants, so they can see things from a different perspective.  But I ask, why is it that the person doing the work can’t see things from a different perspective? The answer, is clear – because the framework they are following has told them to look at a particular set of things – and they don’t see the obvious elsewhere.  I call this phenomenon framework tunnel vision.

People who support Scrum and LKU Kanban see this but vehemently defend their favorite approach.  Scrum practitioners are quick to remind us that Scrum is a framework and you need to put things into it.  LKU Kanbaners insist that things like teams are orthogonal to their method.  However, both of these belie the fact that both methods encourage their respective tunnel visions and ignore that their favorite approaches have nothing to do with it.  

This claim of orthogonality is particularly dangerous because at first glance it appears to make sense. While LKU Kanban may be orthogonal to teams, having teams isn't orthogonal to doing software development.  This point can best be understood by remembering the Tacoma Narrows Bridge collapse (another great video if you haven’t seen it).  The interesting thing about the Tacoma Narrows Bridge is that it was properly designed according to the best methods known at the time.  However, at the time, the potential for wind to set up a harmonic in the bridge that would cause it to collapse was not considered a factor required to be attended to.  That is, the issue of wind was orthogonal to designing the bridge (pun intended).

What can we do about framework tunnel vision?  The answer is clear, but you’ll have to wait for my next blog.

Al Shalloway
CEO, Net Objectives

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.


My answer as a non-framework-, non-method-, non-process-author, but a simple practitioner is: stay engaged in what's going on. Learn from all camps, swear allegiance to none. The hard part is not everyone has the time or energy for this and just wants to be told how to do it.

Oluf:Thanks for commenting. I agree that your's is actually the best.  But as you say, people want a solution.

I believe there is a way to provide solutions without framework myopia. 

Coming soon.

Al Shalloway

I can't resist to quote Werner Heisenberg's
"We have to remember that what we observe is not nature herself, but nature exposed to our method of questioning" or Maslow's "If you only have a hammer, you tend to see every problem as a nail". So we have to stay open-minded (or as Oluf writes "...engaged in what's going on. Learn from all camps")and update our mental tool sets.

Tomasz:You are exactly tracking my thinking.

Here's one of my favorites:

Absorb what is useful. Refect what is Usefule. Add what is specifically your own. - Bruce Lee

The moment we start believing our methods are truth is both the moment they are both a lie and that they begin to die.

Al Shalloway

Hi Al,

I like your quote. Truth is elusive, yet every one wants a simple truth in a complex world. So we give them what they want. It's like weight loss. Every one wants a simple answer to loose weight, so there is a whole industry out there selling fad diets.

Its the same in business. David Anderson makes the point about Boston Lean. He is right. The codified practices sold and marketed out of Boston are miles away from the post war Japanese culture that Taiichi Ohno was a part of and which led to Japans post war industrial success.

Similarly with Germany. It is the German work ethic and sense of social responsibility that makes them the power house of European industry. There is no way to package that and sell it to the Greeks :)

We need to be honest about this, less we repeat the mistakes of the past. I think you are making a great contribution. Thank you.

I'd like to add another dimension. You mention Myopia, blind spots. Like you say what we see is limited by the lens we choose. One of my bug bears is that we tend to be fixated on a single lens for software development. We tend to see Software Development as an ordered process. Given the dominance of control cultures in business this is hardly surprising. Yet the Agile movement was meant to offer a more rounded perspective.

One of my concerns is that this alternative is being diluted and lost. Agile has become just another process and set of practices. There are alternative ontologies. Actors don't think of what they do as an "ordered process". Order has it's place, but what about Unorder? Human imagination, creativity, and skill?

A multi-ontological perspective is what is needed IMHO. But again, this is a hard sell. It needs a transformation in management thinking/culture... Developing and enabling their people and then letting go rather then imposing top down control. This alternative takes a huge shift in thinking; a long term investment in people and of course trust. So instead we find ourselves abandoning the truth that much in life is unordered and instead we try to reduce everything to a finite set of simple rules. And of course these rules can be conveniently packaged and sold.

The wonder and the beauty of the unordered world is something to be embraced. All great software owes its existence to human skill, intuition, and imagination. There is no fixed formula for these.

The fact that this is a hard message to sell in the corporate world, doesn't mean it should be lost all together.


PS. The startup world has embraced much of this thinking and is where the real discovery and learning is happening at the minute IMHO.

Paul:Thanks for this. We are definitely keeping this in mind.  I totally understand the need to attend to complexity.  This project will be taking advantage of patterns - one of which is that we do not have predictability in the results.  We will attend to this as we go.  It's why we are considering the following as we move forward:

1) starting points - there is never one

2) how to tell how you are doing

3) how to tell when you should stop doing something

and i now realize I am starting to repeat my later blogs.

Anyway, complexity does not preclude ordered thinking - one just needs to recognize that one can get into trouble if one's ordered thinking isn't validated.  My experience is that folks aren't taking advantage of what is known very much and there is much improvement available in the complicated and even simple spaces.


I don't disagree with the general concept you're asserting in this post - but I think it'd be useful to all if you just "give it up" and - despite the possibility of incurring the "wrath of the Purists" - go ahead and give some nicely laid out examples (real OR "made up" but if the latter, examples which **could** be real) in the domain most of us work in - i.e., IT and software development in particular - AND - using examples of specific framework myopia - e.g., I'd like to see examples for Scrum, as that is still the most widely used agile "framework" out there, but also perhaps KanBan, etc.

I think many of us are starting to observe that there is a large contingent of "purists" who insist - while contradictorily also insisting that there shouldn't be "standards" on the same - very specific approaches/processes/practices that they also insist **must** be in place for "agile success" - often quite contrary to the same agile dictum of "adapt & change". Its become an "all or nothing" approach - which really leaves out a huge contingent of companies that can successfully integrate **some** agile approaches and benefit, w/o necessarily adapting all the standard "CSM-type" learnings going above and beyond Scrum per se.

Look at

the team doing kanban and missing the importance of teams is an example I have seen several times.


One I've written about before is Scrum teams' lack of noticing the importance of managing WIP.

Look at

the team doing kanban and missing the importance of teams is an example I have seen several times.


One I've written about before is Scrum teams' lack of noticing the importance of managing WIP.

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