After attending Devops, Lean and Kanban conferences in Sweden and Germany, this week’s roundup is heavily loaded with links to slides, videos and photos.
News
The Lean Kanban Central Europe conference in Munich included some excellent presentations, pecha kuchas, and interactive sessions! One of four keynotes, Stephen Bungay, in the final keynote, “Back to the Future” explained how 21st century businesses can learn from 19th century military thinking. Keynotes and select presentations will be available on video soon. Unfortunately not all presentations were recorded, but slides for most are on the LKCE11 website and Interviews with several speakers are up on YouTube. Many thanks to the organizers, presenters and participants who contributed to this fine event - many of whom can be seen in the conference photos at http://www.lean-kanban-conference.de/pictures/). http://www.lean-kanban-conference.de/program/ http://www.youtube.com/user/GroetenUitDelft
We played the” IT Services and Operations” variant of the GetKanban Game simulation at Devopsdays in Gothenborg, Sweden. Participants asked about dependencies between the standard stories and the intangible tickets – hmmm - great idea for the next iteration of the Ops Kanban game! I’d say more, but Gareth Rushgrove (@garethr) already wrote up a lovely summary of the devops conference in his 42nd “Devops Weekly”. Subscribe at http://devopsweekly.com/. http://devopsdays.org/events/2011-goteborg/
Ian Carroll posted a case study on the kanbanops Yahoo! Message board. Included is a nice range of kanban boards from SysAdmin and DBA to Networks and Infrastructure. The metrics (manually captured) come with a warning to management to not use them for performance measurement (love it). http://tech.groups.yahoo.com/group/kanbanops/message/125
The Lean & Kanban 2011 Benelux conference videos are out! The 34 videos might take weeks to watch, but Don Reinertsen and Dave Snowden’s are considered must-watch-now material. Reinertsen’s keynote, “Is it Time to Rethink Deming?” indicates the need to respond to ANY random variation to reduce risk, not just assignable cause variation. Snowden’s keynote, “Practice without Sound Theory Will Not Scale” indicates the need to ABSORB uncertainty rather than reduce uncertainty- otherwise the ability to adapt is destroyed. Enjoy these along with all the other great speakers. http://vimeo.com/channels/leankanban2011benelux
Events
The Lean Enterprise Software and Systems conference (#LESS2011) is happening in Stockholm, Sweden Oct 30 – Nov 2. http://less2011.leanssc.org/
Since 2007 when I first published on the Kanban Method as we recognize it today, I have struggled to articulate how to get started and describing the thing around which we hang a kanban (WIP limited pull) system. The first of the five core practices was described as “visualize workflow” in book. In some subsequent articles and online publications I and Janice Linden-Reed played around with alternatives. We tried borrowing the term “value stream” from Lean, and later got seduced by the intellectual objection that knowledge work isn’t a linear process and we should borrow Clayton Christensen’s term “value creation network.” The publication of that particular article on Kanban (which I refuse to link as I don’t want its search engine ranking improved) represented, perhaps, an all-time low in the struggle to articulate how to do Kanban. Recently, I attended Lean Kanban Benelux 2011 and was inspired by Michael Kennedy, an expert in Lean Product Development, to adopt his language of a “knowledge discovery process.”
What exactly is the problem?
I’ve perceived for more than a decade that specialization in software development was often an emergent property of 20th Century management approaches. Specialization into analysts, designers, coders, and testers would lend itself to higher utilization metrics, greater efficiency, and perhaps economy scale through efficient analysis, design, coding or testing of large batch sizes of knowledge work-in-progress. It’s this large batch size, efficiency-oriented, software development life cycle process that is often referred to as “waterfall.” My interest was in focusing on flow through the development process and reducing lead times. I wanted to decouple the lifecycle of the knowledge work(-in-progress) from the people performing the work. I also wanted to find language that removed any implications of a batch transfer such as “phase.” Finding suitable language has been challenging.
Options
In truth I’ve struggled with the language to describe how software emerges from an idea to working code since I authored my first book in 2002. Page 18 of Agile Management describes stages of transformation. I was never happen with that terminology but it was the best I could do back then. Terms such as “phases” already carried baggage in software development.
More recently Chris Matts had suggested that software development was an information arrival process. This was inspired by his focus on Real Option Theory and the need for information to arrive in order for decisions to be made. I liked Chris’ ideas and felt it offered some improvements. However, I found that many people didn’t connect with the concept of information arriving. It seemed to them they had to make the information appear, it didn’t arrive of its own accord. However, the idea that software development was a process where we went from 0% information about a feature or function to 100% information which represented a fully working piece of code, was attractive.
Recently in my classes I’ve been asking people to map workflow by identifying state changes in the work by asking themselves “what is the dominant activity for discovering information (about the work item)?” And to consider that creation of software is an “punctuated information arrival process molded by the dominant information discovery activity at any given time.” When we find that a particular activity is no longer yielding new information, we tend to switch to a new means of generating new information, the inflection point when we switch activities indicates a state change in the work, for example, it is analyzed, or designed, or coded.
Then I watched Michael Kennedy use the term “knowledge discovery process,” and go on to describe the notion that product development was the process of going from 0% knowledge about an idea to 100% knowledge of a finished product ready for delivery to a customer. Given the historic background and my search for a simple way of expressing the flow of software development, Kennedy’s language seems like the perfect fit. Software development, for any one work item (user story, use case, feature, function, requirements) is a process of knowledge discovery, punctuated by changes in the dominant knowledge discovery activity. Hence, we can “analyze a problem” to discover knowledge, and when we reach a point of diminishing returns we can do something else, such as “design tests to validate working functionality against our understanding of the problem”, until we reach a point of diminishing returns and perhaps we choose a new activity such as “writing and compiling code.” Any software development process, no matter how iterative and incremental in its nature, can be described in these terms. Such a description is devoid of any implications of specialization of labor, hand-offs between individuals or batch transfers.
New Guidance on Visualizing Workflow
So now we can articulate a very clean and clear definition for mapping workflow when starting a Kanban initiative and designing the initial kanban system. Treat the process of creating a finished piece of work, of a given type, as a process of knowledge discovery, where we go from no knowledge (idea without substance) to complete knowledge (ready for delivery). Ask “what is the sequence of dominant knowledge discovery activities?” and draw that sequence. Use this to define the states within the workflow. Each of these states will then be visualized on our board or electronic tool. We can then define WIP limits for individual states or sets of states within the workflow.
And what of Value Streams and Value Creation Networks?
While I understand a number of Lean and Agile consulting firms are having some success with “value stream mapping” and are actively selling this to their clients, I personally never intended for this to creep into Kanban or to be part of Lean initiatives with software development and IT groups. I am naturally leery of borrowing any specific practices and tools from manufacturing industry. Such tools are often context specific and rooted in the physical nature of the work. Our work is invisible, virtual and revolves around knowledge and information not physical things. While Lean principles make sense for us, I am skeptical about tools.
My observation is that those mapping value streams focus on the hand-offs between people and departments and not on the natural progression of the work. I worry that this will lead to a focus on managing people (or groups of people such as departments) and not on managing the work. The great paradigm shift is that in Lean we are managing the work and allowing the people to self-organize to deliver against customer demand. I noticed that some consultant have picked up the Lean tools and put them to direct use with software teams, creating diagrams for value streams that look like the bones of fish picked clean on the plate. The truth is that value streams are perhaps the one area where physical systems are actually much more complicated that knowledge work. Mapping the value-chain delivery of components, sub-systems, assemblies, and the economic batch sizes for such deliveries, for a production system is often very complicated while analysis->design->code->test will generally approximate whatever we might be doing in a software development context.
Some consultants have argued with me that Value Stream Mapping has enabled them to work with clients to find improvement opportunities that have been immediately actionable. This is great news. It seems that any activity that encourages collaborative analysis of process problems and drives consensus opinions about changes, is a good thing. If this is working for you I wouldn’t suggest you stop doing it. However, David J. Anderson & Associates are unlikely to be offering Value Stream Mapping as a service nor will it be included in any of our training material.
The push for adoption of the term “value creation network” came from those, rightly, objecting to the idea that a stream implied a linear flow between people and that knowledge work flowed through a complex network of people before completion. That is we wanted to capture back flows and loops and iterative development then a stream was the wrong metaphor, a network was a stronger match. This is indeed correct. However, I feel that a process of knowledge discovery, mapping the dominant knowledge discovery activities as a sequence, complete avoids the issue.
Conclusion
Hence, I believe that value stream mapping and value creation network mapping are a potential source of waste. Mapping workflow doesn’t need to be difficult and it shouldn’t take too long. Mapping workflow should be one of the simplest and fastest parts of getting started with Kanban. For each work item type ask the simple question, “What activities do we perform to discover knowledge to create working software?” Then ask, “Which activity dominates at any given stage in the development of the software?” and sequence these to provide a framework around which to design a board and kanban system. Going forward, we’ll be aligning our language with Michael Kennedy’s. This change will also be reflected in a 2nd edition of the Kanban book. [Note: I have no firm plans or schedule for a 2nd edition at this time.]
The eagle-eyed observer of Kanban will have spotted that recently, I and my team have subtly changed some of our messaging. We’ve adopted the word “capability” where previously the term “throughput” was typically used. Why the change?
Those familiar with my Recipe for Success in its various forms published here and in my Kanban book, will know that one of the steps has gone through several changes. Originally, “Balance Demand against Capacity” was replaced in 2007 with “Balance Demand against Throughput.” Why this original change?
Well the original wording was ambiguous and if you follow Eli Goldratt then you will know that he had previously pointed out the folly in such thinking. “Capacity” he pointed out was a volume not a flow. So “capacity” in a kanban system would be the number of (virtual) kanban in circulation (or the total WIP limit of the system.) You don’t balance demand against this. You balance demand against the rate of work being delivered, so the correct term was “throughput,” where throughput means the rate (or quantity over time) of completed work being delivered out of the kanban system.
Throughput
So, why the recent change to “capability” moving away from “throughput”? This change will be reflected in the 2nd edition of the Kanban book (no planned publication date) and in all of our materials going forward. The Recipe for Success will now read “Balance demand against capability.” Why?
I came to realize that using throughput as the metric for success or of determining customer satisfaction is not always appropriate. The customer demands are seldom for more throughput. The demands are often expressed in other ways. There are many contexts where better due date performance or shorter lead times would be more desirable. “Capability” is in this sense an abstract term. Capability can be expressed in many ways. Throughput is just one way of expressing capability. Lead time, its mean, and spread of variation would be another, and due date performance (or on-time delivery performance) would be another. I think these three - throughput, lead time and due date performance - represent the three most likely choices for expressing capability when using Kanban. However, I’d like to leave the definition abstract and encourage other interpretations.
So in future look for us to be communicating that the system level problem is one of a lack of balance between demand and capability. We are pursuing improvements in order to better balance demand against capability. We are assuming that greater customer satisfaction will come from this improved balance. We will therefore design the kanban system solution from the outside, in. Well seek to understand demand and capability and to examine the reasons why capability is impaired and look at how it might be improved. Part of the solution may involve the use of a kanban system and the adoption of an evolutionary approach to future improvements. This is the Kanban Method in action.
Some readers will recognize that this new articulation of getting started with a Kanban initiative by understanding capability and demand and by seeking to identify system effects that affect capability are inspired by the work of John Seddon. This is correct. John has provided me with a better way of expressing what we are doing. Those familiar with the XIT story from MIcrosoft will also recognize that this understanding of capability and demand is exactly what Dragos Dumitriu did before we acted to implement a kanban system solution for his department. Hence, this isn’t new to Kanban but I and my team are constantly learning how to better articulate our work in order to facilitate faster and better understanding amongst those leading change in their organizations through the use of Kanban.
So “thoughput” isn’t out of fashion, it has been relegated to a context specific choice!
Deming and CMMI
There is another reason I love the word “capability”. It is a term that Deming would recognize. It is also the “C” in CMMI for the same reason. CMM (as was) was inspired by the work of Crosby (the Manufacturing Maturity Model) and Deming (the Theory of Profound Knowledge). The “C” in Capability Maturity Model is intended to be interpreted as Deming would have used it. By adopting the use of the term “capability” in Kanban, we are providing clear links to the work of Deming, which we find foundational to much of our teaching and coaching advice. Identifying sources of variability that adversely affect capability and eliminating them through kanban system design, management policy and improved capability, are at the core of Kanban and how we teach it. Further by adopting the term “capability” and providing the guidance that it should be interpreted as throughput (aka “velocity”), or lead time, or due date performance, we are providing clear hooks into CMMI and showing how Kanban can be used as part of a CMMI initiative or how it can be compatible with maintaining or improving a CMMI appraisal rating.
Complexity & Cynefin
In his key note at Lean Kanban Benelux Dave Snowden state that in the complex domain we seek to use an evolutionary approach to change that probes (or experiments) with ideas and then amplifies the successful ones (attractors). He went on to explain that unlike a typical managed change initiative (typical of the 20th Century but sadly still all to common in the Agile community) where a there is a defined destination designed to offer a particular capability - think of “We will adopt Scrum for our next project” or “We will be CMMI ML3 by end of calendar 2012” - a complex space solution must not define a destination but simply allow evolutionary steps to happen. This is exactly how Kanban is designed to operate. However, it creates a problem. How do we know if things are improving? How do we justify encouraging and promoting change? Dave explained that in the complex domain we must measure the impact of a change to know if it is an improvement. This can only be measured retrospectively.
Capability gives us the means with which to measure impact in an emergent reaction to a complex domain problem. By showing improvements in terms of throughput, lead time, or due date performance (as measures of capability), we provide a direct means to assess impact.
Summary
Adopting the term “capability” is more general than “throughput” and reflects the general application of kanban systems and use of the Kanban Method across a range of software development projects, maintenance and IT work. “Capability” is better aligned with the ideas of Deming and modern systems thinkers like John Seddon. It provides a clean way to explain from the outside, in, why Kanban makes sense and the value it is adding - allowing us to better balance demand against capability. “Capability” also better aligns with CMMI and enables those in regulated environments to communicate the value and purpose of Kanban as well as cleanly map Kanban practices such as Cumulative Flow Diagrams to required elements for an appraisal. And finally, “capability” gives us a way to measure the impact of emergent behavior when considering Kanban within a complexity science model such as Cynefin.
We’ve been making some other nomenclature changes. What out for more blog posts explaining the emergence of other new terms in the lexicon of Kanban.
We are packing our bags for Europe this week! With conferences in Sweden and Germany, we anticipate opportunities to meet and talk with some really interesting people - thought leaders of our time!
Yuval Yeret recently blogged on, “How Kanban and TOC Critical Chain Relate”. He discusses the similarities between Multi-Project Critical Chain and Kanban for driving improvement. Yuval points out that while generalization is a worthy vision of Kanban, many organizations simply cannot achieve that (ex: SysAdmins, DBA’s). Therefore, the need to understand the capability of a specialist is key to avoid overburdening them and abusing our scarcest of resources. http://networkedblogs.com/ogomM
Events
Devopsdays (the conference that brings development and operations together) is happening in Goteborg, Sweden Oct 14-15. Am really looking forward to hearing Mattias Jansson and Noa Resare present “A Case Study in Operations and Development Integration at Spotify” and how they used kanban to avoid overloading teams and dealing with “short term panicky stuff”. http://devopsdays.org/events/2011-goteborg/
Next week, I’ll be attending the 1st Lean Kanban Central Europe conference in Munich. Twitter hashtag is #lkce11. Looking forward to keynotes from John Seddon, Kent Beck, David Anderson and Stephen Bungay. And Jurgen Appelo’s is presenting “Complexity Thinking? Or Systems Thinking++?”! But Darn! it’s at the same time as Fridtjof Detzner and Sönke Rümpler’s talk on “Why Kanban Fits the Jimdo Culture”. Good thing the presentations are being recorded:-) http://www.lean-kanban-conference.de/
Please contact .(JavaScript must be enabled to view this email address) with questions.
Kanban leadership workshop in Vienna Dec 5-7, 2011
This 3-day leadership/coaching workshop with David is limited to just 12 people.
This workshop is for anyone tasked with leading a change initiative in their organization or at a client organization in 2012. It is suitable for managers, process engineers, change agents, experienced Agile, Lean, or project management coaches and consultants, existing Kanban practitioners with 1 year of experience, and those who have previously taken David J. Anderson’s Kanban class and are actively using Kanban at work. Attendees are expected to be familiar with the content of the book, “Kanban - Successful Evolutionary Change for your Technology Business.
These intensive 3 day workshops are intended to transfer the knowledge and skills to enable you to lead Lean transformations using the Kanban Method
The price for this workshop is $4000 USD per person.
Don’t miss out! Read what others are saying about this workshop.
Register today!
Regular price $4000 (USD) per person
EARLY BIRD SPECIAL $3400 (USD) per person!
Enter Discount code: EARLYBIRDCE
expires November 21, 2011
A copy of the book will be supplied upon registration. Attendees will maximize the value if they are already familiar with the material.
The intent is to have an interactive collaborative session designed to facilitate knowledge sharing and learning. Attendees should come prepared to discuss their own experiences with Kanban and challenging situations they’ve faced with change initiatives at clients or employers
The workshop will open with a round table of introductions and shared Kanban experience. Each participant will be asked for a list of questions they’d like answered over the 3 day session and from this a topic backlog will be built. David will augment this backlog with essential topics and foundational material. The agenda for the remaining time will then be set to insure the fullest of coverage and the maximum value for all participants. The focus will be on shared experience and discussion of the hard questions that clients and team members ask coaches during the introduction of Lean ideas through the use of a kanban pull system. The workshop will include the use of the GetKanban game simulation and discussion of its value as a teaching aid.
The goal is to enable participants to go back into the field and successfully coach Agile/Lean transitions using the Kanban approach. Every workshop is different because of the unique experiences of each participant and their specific focus and desired outcomes. Each participant will received a personal recommendation from David J. Anderson as a result of participating in the class.
Kanban offers agile and project management coaches another tool in their transformation and coaching toolbox. Kanban is proving to be a facilitator of evolutionary change with low resistance and an enabler of accelerated high levels of organizational maturity.
