How do Teams Continue to Win during Times of Turmoil and Uncertainty?
By Dominica DeGrandis
We had a big snow this week. Twelve inches total, a forty-three year record in our part of Puget Sound country. We lost power for ten hours – no furnace, no computer, no lights. No problem - I cozied up to an emergency kerosene stove and opened Jim Collins’ new book, Great by Choice, a study of winning behavior when confronted by uncertainty - with comparisons between companies that win and companies that languish. I was especially fascinated by the parallels I see between the behavior of Jim Collins’ winners and key concepts that we teach with Kanban for coping with uncertainty.
Collins begins with a story of two competing teams far removed from our 21st century business world. The location was Antarctica. The year was 1911. The competition was a race to the South Pole between a Norwegian team led by Roald Amundsen and an English team led by Robert Falcon Scott.
Each team’s leader was an experienced Antarctic explorer. Each team departed its home base at about the same time. Each faced a roundtrip of 1400 miles, all of it ice and snow. What was different?
The Norwegian team planted its flag at the South Pole on December 15, 1911 and returned safely to home base by January 25. The British team reached the Pole on January 17, 1912 - and never made it back, freezing to death near 79 degrees latitude.
The point of the story is that Collins attributes the difference between Amundsen’s success and Scott’s tragic failure to some fundamental concepts that apply to business management in the 21st century.
And I was almost startled when I realized that those same concepts apply to the Kanban method that we teach in our classes. These concepts are:
Amundsen lived and studied with Arctic Eskimos before going to the South Pole. Among the practices he observed was how the Eskimos never hurried, moving slowly and steadily, “avoiding excessive sweat that could turn to ice in Arctic temperatures.”
The Norwegian team, traveling on skis and using dogs to pull its sleds, set an attainable daily goal. And when they had reached that goal, the team stopped for the night. They set work-in-progress limits.
They managed risk by providing buffers. They provided three tons of supplies for five men. The British team, using ponies to pull its sleds, carried one ton of supplies for seventeen men. The Norwegians placed 20 pennants to mark supply depots. The British placed only one. Amundsen brought four thermometers to measure altitude. Scott brought only one – and it broke.
KANBAN PARALLELS
Studying is the essential first step to designing a Kanban system. Studying the “what and why” of an existing system’s performance leads to understanding improvements and understanding what prevents goals from being achieved.
Limiting work-in-progress (WIP) is a self-imposed constraint and a core practice of Kanban, where a limit is set on the number of tasks worked on at any one time. Collins uses the metaphor “20 Mile March” to describe an attainable and sufficient goal for a day’s work, identifying multiple benefits:
- It reduces the likelihood of catastrophe when you’re hit by turbulent disruption.
- It helps you exert self-control in an out-of-control environment.
Limiting WIP does not mean reducing WIP to near zero. The British had too little (food) inventory. The Norwegian’s had a lot more. Less inventory (traveling light), isn’t always better. This is especially true in knowledge work. The more important factor is controlling the WIP with a limit. Maintaining a healthy level of WIP creates options that mitigate specializations in the workforce and balance against uncertainty in the market or business domain.
Buffers improve predictability. Because the initial analysis of software development is never perfect, there are always unforeseen events. Service-level-agreements (SLAs) based on observed behavior buffer time expectations while WIP buffers in front of capacity constrained resources smooth flow and improve predictability.
The use of Kanban can be seen as an active part of risk management for IT organizations and product or service development groups. Organizations that know how to manage risk will have an edge in a volatile world. The more turbulent the world, the more you need to study your situation, keep an even pace (set WIP limits) and use buffers to meet expectations and improve predictability.
Apologies for missing last week’s post. I was completely immersed working with a team in NYC helping them design their first kanban board. Hopefully the extra content will make up for the delay.
An article titled, “Scrum and Kanban: Both the same only different”, by Liz Keogh includes an especially interesting section, “Kanban visualizes what’s happening; Scrum visualizes an ideal.” It points out that with Kanban, a key ingredient is making process policies explicit, so they can be addressed and improved upon. http://lizkeogh.com/2011/11/20/scrum-and-kanban-both-the-same-only-different/
In a twitter exchange of ideas about kanban board designs - primarily between Pawel Brodzinski and Jabe Bloom, concern was expressed that showing people other peoples’ designs can stifle creativity and cause harm.
Well, it depends. It depends upon the people, the project, the chemistry in the room, and other stuff. People have different learning styles. The creative people may want to start from scratch with their very own design. But the “I’ll know it when I see it” people appreciate the opportunity to learn from others to avoid reinventing the wheel.
I have found that it can be very helpful to show people a variety of board designs and let them judge for themselves how a given design may or may not apply to their work. People understand that these are just examples that have been uniquely tailored for someone else’s use and can be modified without limit. People take what they want and toss the rest.
Kanban’s board design system is a marvel of adaptability. I show many board examples both from development and IT services, as well as from operations. People understand that their ultimate designs are for them and for them alone. There is no standard. There is no best practice. Nothing is cast in concrete. Their designs are meant to be re-designed as their work changes.
Kanban board designs should be uniquely tailored for the current process in use. Board designs, in reality rarely stay the same. They are more likely to change – perhaps even tomorrow, from someone seeing something from another board that looks promising. Often, perhaps usually, it’s a big help to have a starting nudge from an example or two or ten kanban board designs.
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.]
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.
