Originally posts August 2013.
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.
Please watch video
Please watch video
Please 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:
- workload being pulled from
- team structure
- workflow order
- 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.