Archive for September, 2009
Oh wait, I don’t, and neither does Matt Heusser. In his most recent post over at Testing at the Edge of Chaos, he devotes a section to challenging why we co-locate at all any more. As somebody who has recently shaped my life to get out of that geographical lock-down and start moving with my family to the places we want to be, I’m very interested in the lessons and perspectives of others that have created similar situations for themselves.
The situation creates a natural pull between my agilist nature wanting to be entirely located with my team and my human side that wants to be in natural settings that work for me, instead of in a sterile office environment. Luckily, it feels like technology is coming to the rescue and allowing me to recoup some of the proximity benefits through social networking, video chat and the like, while still allowing me to live and work where I want. Unfortunately, it’s not at the point where I can just wave my hand and have a peer checking out my work in 1 second, or to where I can pick up from body language that my team’s getting frustrated and needs a disruptive event to help focus things again.
I’ll be thinking about this, and maybe I’ll have answers someday. Until then, I hope to see Matt and others like him continue to write about their experiences!
My friend Matt Heusser recently posted a perspective on kanban that I feel warrants a bit of discussion. I greatly respect Matt and his opinions on testing, software, and life in general. I feel that this post provides me a great opportunity to address some of the perspectives about kanban that have been expressed that don’t align well with what I perceive to be the essence of the community.
As with any two-sided argument, the reality will be somewhere in the middle and a few steps off in a third direction. I hope that the kanban community as a whole pays attention to the perception that we’re giving and focuses on communicating ALL of our values, not just those that we feel set us apart.
I have reproduced Matt’s post in its entirety below, with his permission. My comments are tagged in blue and I used blockquote on them to set them apart from Matt’s content. I have edited his work for format only, no text changes have been made.
[Edit] Matt has a number of comments showing up on his original post.
Thursday, September 17, 2009
In Japan, a kanban is a little card that is used as a signal device. The idea, in manufacturing, is that teams downstream “pull” new work, instead of having work “pushed” to them, which creates bottlenecks.
A European named David Anderson took the idea and applied it to software to create Kanban Development, [ERW1] a surprisingly popular movement, to the point that it has its own user groups and conferences.
[ERW1]This greatly oversimplifies the multi-year evolution process. He actually started with Drum-buffer-rope, realized it wasn’t a good fit due to the variability, and then tried Kanban signaling. While this, unfortunately, is the name that stuck, it didn’t stop there. Instead, it went deeply into Lean Design (ala Don Reinersten) approaches (NOT MANUFACTURING) but kept the name because of the ongoing focus on Value Stream Mapping and queue management.
How did David do it? Well, first he [ERW2] was a Theory of Constraints, CMMI, and Agile-Management Guy. He went to Microsoft and worked with an internal development team, where he wrote: “From Worst to Best in 9 Months – Implementing Drum-Buffer-Rope in Microsoft’s IT Department.” It’s interesting. You can read it for yourself, and I’ll try to summarize below.
[ERW2]My understanding is that first he was a video game developer, then later he was a User Experience guy doing work on Visual State modeling where he was involved in the first FDD project, then he was an FDD guy for a while, until he realized that the CMMI was based on Deming and everybody screwed it up, then he dug deeply into Deming and Goldratt while writing a different view of the CMMI for Microsoft, where he dug deeper into Deming and focused on identifying systemic issues instead of blaming the team (authoring the XIT paper), then he took these new ideas around Kanban & Lean and used them at Corbis to great success, but failed to institutionalize the changes effectively, at which point he went independent and suddenly had a vested interest in the brand known as “Kanban”.
That’s right folks; without any specific skills training, and people interaction, any changing of the office environment, he got something like a 150% increase in the number of tickets the team could handle in a month. How did we do that?
- [ERW3] He eliminated the time the team spent planning and estimating
- Technical staff took stories that makes sense that they were actually capable of doing (rewards well-written, well-conceived change requests)
- They moved from a push system to a pull system
- They made the process transparent
- They stopped batching up User Acceptance Test and Deployed a ticket at a time
- He got the team out of meetings
[ERW3]This list is accurate, but the order is misleading. “They made the process transparent” is the biggest thing, and getting political acceptance for an SLA based approach is the second biggest thing (from my memory)”
Now, the idea of Kanban for software – where we make the work visible by having a board, limit the work in progress, achieve pull, have no fixed iterations but (possibly) continuously deploy, arguably [ERW4] came out of this case study.
[ERW4]I strongly disagree, but you can argue it I’d say this is a formative part of the transition from an FDD iteration perspective to a continuous perspective. The problem is that it’s the only published (or even public, possibly) experience from that time frame b/c he was building the CMMI template for Microsoft.
Personally, I have a different interpretation: That if you take a team doing CMMI 5 and PSP/TSP and /stop doing/ a lot of required practices, moving your team from 20 hours of meetings a week to three or four, throughput will go up. Further, by working on a story at a time, you’ll have technical staff actually talking to each other instead of throwing work over the wall via electronic tools. This will work wonders for eliminating the “hot potato” game.[ERW5]
[ERW5]All true, and none unique to Kanban… that sounds a lot like the core point of Agile to me.
Finally, and most importantly, if you live in an environment where the customers can make as many ill-conceived change requests as they want, and you have to constantly estimate, evaluate, and shuffle the deck, then take all that away, yes, productivity will go up.
So, I agree, what Mr. Anderson did at Microsoft can work for certain kinds of projects – namely, a maintenance team working on legacy applications that are small, separate, and distinct. That way, you can test one entire ‘system’ at a time and deploy continuously. (This is pretty much exactly what we did with the small projects team at Priority Health, about the same time, with good results.)
[ERW6]Here’s where I start to argue strongly. What happened at XIT is not what we call Kanban today. I don’t think he did at the time, other than possibly mentioning the scheduling mechanism.
First of all, it’s universalism. “This process worked for me one time so it should work for everyone all the time.”[ERW7] Just like labeling a good idea a “best practice”, it’s a rookie mistake.
[ERW7]Two comments here.
First, few involved people call it a process. Unfortunately, it received that label by people talking about it.
Second, I will say that applying the lean thinking mindset will work everywhere all the time, but would never say that a Kanban system will be the result of that thinking every time. Unfortunately, people that don’t understand it got excited and started calling it things its not.
But now we have the Kanban discussion list, which I have tried to be involved with. I see a lot of smart people with good ideas, but there are things about it … something I can’t put my finger on just yet. Here’s what I’m struggling with:
1) There’s something odd about the way this community talks. I mean, I have a master’s in CIS, I study software (and manufacturing) process, one of my writing/speaking partners is a Six Sigma black-belt and process engineer, and there’s something … odd there. Why call it a “Value Stream Mapping”? [ERW8] Why not just call it “How we get from concept to cash?” Why is it that skills, training, experience, and expertise just never come up in discussions with these groups? [ERW9] Why is it that instead of talking about development or testing, we call it “workflow” or “process mapping?”[ERW10] I have an inkling on why, and I’ll come back to that in number 4, but also …
[ERW8]Because this is the terminology from our source literature. It’s a useful piece of our local vocabulary when talking amongst ourselves. I explain it in terms of “User to user” or “end to end including all business functions” typically.
[ERW9]Because we treat these as the assumption. Think Deming – we believe the system is the problem and not the people, and we assume the people will do the absolute best they can under the circumstances. It’s an implicitly assumed aspect that we ought to give a lot more time to.
[ERW10]While the people are the most important part of the system, the goal of the system is to produce value, hence focus on the flow of value and words like “value steam”. Workflow is a casual use of the same concept, and process mapping is usually only used specifically when referring to applications of that technique when we feel it’s appropriate… which is rarely (I hope)
2) It seems to me this community uses a lot of 20th century worship words. Productivity. Throughput. Optimize. Lead Time. Cycle Time. Flow. Leveling. There’s nothing wrong with these words (although, if you can measure productivity at all is a different discussion.) I see these terms thrown around in a naive, cavalier way. Like “New and Improved”, “Hyper-Productive” and “Best in Class”, they almost guarantee attention and receptivity for an audience – management and executives[ERW11].
[ERW11]Yes, we use those words because they have a strong meaning and very specific connotation to the current generation of management and executives. It’s about effective communication, and most management I’ve worked with outside of the valley culture get “lean” terms instantly… saving us from having to spend precious face time explaining the underlying concepts. I have to use different terms when dealing with management that rose from the techie ranks… then we talk about development, testing, etc more specifically.
But does that make them right? Certification is another worship word[ERW12] . And, the day I first heard of ISQTB, at the STAREast conference in 2004, an ISTQB trainer told me literally “You can charge twice as much for training if you give away a certificate at the end of it.”
[ERW12]Where does this fit in your argument against kanban? This feels directed at Scrum at the moment. While the LSSC is looking into something… I don’t know that it’s really getting much support right now within the kanban community.
Is that right?
In fact, the Cavalier way those terms are thrown around [ERW13] (compared with, say, the way you’ll see metrics talked about on this blog), tells me that there are a number of possibilities, ranging from over-optimism to universalism to genuine deception. I’m not excited about any of them.
[ERW13]Have you considered that they’re not being casually thrown around, but generally (at least among the leadership of the community) being used with very specific meaning and intent based on the local language of the community?
3) Kanban works best if you start out slow and stupid. As Dave Nicolette pointed out recently, if hyper-productive means a 10x or so improvement, then the companies likely to see that kind of improvement are traveling at a snail’s pace to start with. In other words, if you team is already dragged down, spending 20-40% of it’s time planning, estimating, and writing stories for work, that are 6+ months out, then yes, you can see improvements with Kanban. Or, if, say, you batching up work to be release only once or twice a year then do heavy-weight trade offs through an electronic system, instead of having people talk to each other.[ERW14] But in those cases, systems thinking can lead to improvement directly, without using a label or brand[ERW15].
[ERW14]This is about agile, not about Kanban. We don’t expect people to stop doing or ignore any other techniques they learned from agile.
[ERW15]There’s two possibilities here: Having a label for a perspective and a set of practices, or having a brand around it. Are they fundamentally different?
4) What about people and skills? I don’t see any of this in the Kanban literature. It’s as if people are cogs that can be interchanged in some sort of machine that is stable, predictable, and repeatable. Hey – wait a minute – I’ve heard that before! Yesterday I saw a Kanban history post that claimed that Toyota had adapted the ideas of Frederick W. Taylor, and Kanban came out of that[ERW16].
[ERW16]This is entirely inaccurate, and should be ignored. The earliest presentations David did around Kanban (and the CMMI for that matter) were centered around Deming’s concepts. I believe there is one where he has a slide of Taylor and talks about how this single man set back manufacturing by XYZ years.
That is factually inaccurate. The Toyota Production system did not come from Taylor, it came from a number of consultants, most notably W. Edwards Deming, as an explicit rejection of the work of Taylor.
I don’t have time to get into Taylor and his philosophies, but suffice to say, Taylor was an elitist who believed in separating the worker from the work – having a class of scientific managers tell the workers how to do it – and Deming believed in engaging the worker in the work.
If Kanban comes out from the philosophy of Taylor, [ERW17] then having your process designed by “experts” who don’t want to deal with the fiddly-bits of requirements, development, and testing, but instead design a meta-process that turns software development into an assembly-line makes perfect sense. In that world, you might not call it “development” at all, but instead, something like “Workflow” or “Work Products.” (Notice issue number one, above.)
[ERW17]See comment above… incorrect basis material invalidates this entire section.
If, however, software development is actually knowledge work, which requires the whole person to be engaged, and can be done better or worse — well, then, hopefully, we’ll use the work Taylor as either a door-stop or a cautionary tale.
5) The Kanban movement just isn’t interested in discussing testing[ERW18] . I’ve brought the issue up several times on this list, and get a number of non-answers. That could be because the list members haven’t really done much development. Or it could be that they are working on internal applications, where if you type in an invalid entry, the VP of Finance can say “use Internet Explorer Seven ONLY” or “if you want your reimbursement check, ignore the bizarre error, click the back button, and enter it correctly!” Or they could be working on very small, non-connected systems where the testing burden just isn’t very high.
[ERW18]This is marginally true, because we don’t have any activist testers within the movement.
Cathy @ inkubook is one of the best testers I’ve ever worked with, and we worked continually to integrate her role with the rest of the team and up into the marketing definition of the work. Kanban doesn’t ignore testing at all, but it assume s competent testers and assumes the team will include the testers as part of the team for all quality improvement. “Testers aren’t special, but they’re not second class either”… same reason we don’t talk in detail about dev practices… they’re assumed to be done, and if not they’ll be one of the system impediments that needs to be worked through to help the team perform better.
But on a real project – a large software project – not something a pair of developers can bang out in three or six months. A project where you want end-users to pay out of pocket, fall in love, and recommend it to friend? Well, a big part of what I do is risk management, and I see continuous deployment with a simple CI suite as naive[ERW19] , perhaps even reckless.
[ERW19]Focusing on this is a logical fallacy. We say that we can (and have) done this, but not that it’s always a good idea. The aspect we focus on is on decoupling input and output cadence… it’s the freedom this enables that allowed us to achieve multiple releases a day at Inkubook for those times we needed them (and weekly when things weren’t going as well).
So I see Kanban/deploy per feature moving from limited environments where it can work to general acceptance, and in that, I see serious risk.
Note: In North America, we like our westerns – with Good Guys in white hats and bad guys with bandannas. It would be all too easy to paint the entire Kanban for SW community as “bad.” In reality, the ideas are a mixed bag that can be helpful in some environments. Some members of this community are strong system thinkers that have good ideas, and can separate when an idea might work from when it might not, taking in actual feedback and adjusting. Sadly, in general, due to over-hype, I have a final concern [ERW20] …
[ERW20]This note is appreciated, and points at the real problem. Kanban, like scrum, XP, waterfall, and every brand/label ever used has a dark side to it. People can easily point at the brand, say “I’m doing Scrum” and ignore the discipline and practices that actually make it useful.
6) Some people will actually listen to these jokers. We’ll see a lot of hype about Kanban, there will be Kanban certifications, a Kanban alliance, and “Kanban conversions.” There will be Kanban instructors, tutorials and lots and lots of books.
[ERW21] And, two years from now, or perhaps five or ten, a lot of companies will have a code mess all over the floor, the consultants will have moved on, and we’ll be embracing a new process – perhaps the 5s process, or Kaizen, or perhaps it will be from Northern Europe.
[ERW21]I respect your opinion, although I do not appreciate your characterization.
I believe XP, Scrum, and Kanban each have contributed (and will continue to contribute) to the capability and evolution of our field. None of them are perfect on their own, and very few truly new ideas were introduced by any of them. However, the label, and the awareness created by the label, will combine to improve how we build software.
Let us all honestly hope that I am wrong.
A recent discussion on the kanbandev list interested me because it really brought a focus on what we mean when we say “kanban”.
First, David Anderson posted:
On Fri, Sep 4, 2009 at 2:35 PM, netherby_uk wrote:
(#1) kanban (small k) - meaning signal card – original literal meaning is closer to "shingle" (in American), usage "to hang out your shingle". Signal cards (kanban) are used to facilitate self-organization on a shop floor. With the correct policies they can be used to enable a pull system.
(#2) virtual kanban pull system (small k), generally shortened to "kanban" for convenience – the tool, mechanism of method of using kanban (signal cards) to implement a full pull system in a value-stream. In most of the Taiichi Ohno quotes he is using "kanban" in this sense. Note this includes visualization. Generally speaking the visualizations are not the kanban(#1) but representations of the actual work as knowledge work is invisible.
(#3) Kanban (large k), a method for change management (in software engineering and knowledge work), an enabler of a Kaizen (continuous improvement) culture and process. To do continuous improvement there is a need to incorporate a number of bodies of knowledge including the full suite of Lean thinking, Theory of Constraints, Deming’s Theory of Profound Knowledge, Risk Management / Option Theory, and more will doubtless be added to this list.
After some discussion, Joakim Sundén added:
On Sat, Sep 5, 2009 at 7:27 AM, Joakim Sundén wrote:
1. Kanban (or Kanban Boards) as visualization of project status that helps teams to make work self-directing. This seems to have been Kenji Hiranabes and Poppendiecks early application/understanding of kanban, see e.g. Hiranabes 2007 InfoQ article "Visualizing Agile Projects using Kanban Boards" or Poppendiecks "Implementing Lean Software Development". It is all about visualization and there is no notion of limiting WIP etc. Speaking to Hiranabe and other agile japanese developers on a study tour in Japan this spring most of them referred to kanban in this meaning although some, e.g. Hiranabe, were aware of the other meanings as well.
2. Kanban as a tool. Includes the definition above and extends it with mechanisms as pull and limiting WIP. It can be used with agile methods as well as with waterfall approaches. People who use this definition seem to think of kanban as a tool particularly (and sometimes _only_) useful in software maintenance departments, e.g., where Scrum doesn’t cut it because the constant emergencies ruins the sprint planning.
3. Kanban as an application of lean thinking to software development that is somewhat different to, but not necessarily in opposition to, Poppendiecks flavor of Lean Software Development.
Echoing what David wrote in a later post on this thread, I don’t recognize Joakim’s #1 at all. In fact, when I speak I generally recognize it explicitly as an antipattern because of the pain and chaos it caused the team at Inkubook (as compared to both Scrum and WIP limited pull based systems).
David and Joakim somewhat share the same perspective for their respective #2 and #3’s, so i won’t distinguish between them from here forward. I have seen these 3-level splits before and I find them not working for me because I feel that they miss an important progression. Dividing them into explicit steps loses the important aspect of transitioning between them. I responded with a ShuHaRi perspective that I feel fits the real situation better.
I don’t see what we’re calling kanban as having any real Shu level components at the process level. I suppose working as a member on one of these teams could be considered a Shu level behavior as you learn and copy what your team is doing. A team attempting a kanban system on a Shu-level understanding will degenerate into cargo cult and likely failure. It certainly misses the opportunity to improve itself.
Ha is the entry point for most teams. You read a bunch of different people’s approaches to how kanban is being done, and you take a shot at it based on the set of practices you know. You put up the visual control board, throw some WIP limits on it, and start managing your work that way. You find some success, and you try different practices that sound useful as they are discussed on the boards. Your level of success goes up and down as you try them, and you learn.
Ri behaviors emerge when you start feeling the need for changes and see the appropriate places to make the changes. This is very similar to David’s original #3 at the top of the discussion, but without the explicit statement of the bodies of knowledge involved. I do pull from all of those areas David lists, but I also pull from adult education, hospital management (a special flavour of lean), NLP, software architecture, design & patterns, physical architecture, science fiction, military history, a study of politics, and anything else that inspires me to a better solution at the time. Thus, I argue with David’s #3 on semantics, not on intent. The core goal is to "achieve continuous improvement through continual application of approaches and techniques from a variety of sources".
Ha->Ri is a process of continual improvement itself, and I suspect this is why I don’t see #2 and #3 as different things… I see it as an axis of progression and learning on which #2 is the starting point and #3 is one of many possible futures.
Feature, and feature, and feature,
Slide in their petty pace from queue to queue,
To the last release of recorded value;
And all our builds have lighted fools
The way to techie debt. Out, out, beta users!
Code’s but an indented shadow, a poor representation
That grows and flows for hours upon the screen
And then is patched no more. It is a tale
Specced by an idiot, full of sound and fury
Signifying nothing." — Manifesto (Act 5, Scene 5, lines 17-28)