The number of #kanban tweets continues to grow with the expansion of kanban use in areas outside of software development. From the classroom to Portfolio Mgmt, we look at some examples this week.
News
According to HashTracking.com, Twitter hashtag “#kanban” generated 70,130 impressions, reaching an audience of 52,009 followers from 97 tweets within the past 24 hours (Jan.25, 2012). Also displayed are the top ten peeps by number of tweets, followers and impressions. Makes for interesting data points.
Jim Collins new book, Great by Choice, is a study on winning behavior when confronted by uncertainty. Collins compares companies that win with companies that languish. It’s a terrific read from a Kanban practitioner’s perspective due to the uncanny parallels between the behavior of winners and key Kanban concepts for coping with risk. I was so intrigued; I wrote a blog post on it. http://agilemanagement.net/index.php/Blog/how_do_teams_continue_to_win_during_times_of_turmoil_and_uncertainty/
There’s been a lot of talk lately on Kanban for Portfolio Mgmt. Here’s a post on Kanban for Customer Portfolio Mgmt showing the board layout with Swift Kanban. Intangible tasks are on a separate board which in some ways sounds appealing, but I’m wondering how they visualize priority between business tasks and intangible tasks. http://www.valueinnova.com/?q=content/kanban-customer-portfolio-management
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.
By Dominica DeGrandis
It is fun to discover articles sprinkled with Kanban properties, even though they don’t specifically mention Kanban. I stumbled across several good ones this week.
Having worked for their competitor for many years, I find this list of principles from Getty Images very interesting. They flow, they pull, they stop the line, they optimize the whole, etc… It sounds too good to be true. http://blog.gettyimages.com/2012/01/17/from-our-lean-and-agile-dev-team/
Disclosure - this article isn’t really about Kanban, but “What’s in Store for 2012: A Few Predictions” offers all around good insights for us. In particular, the value of software will continue to decline as open source contributions continues to rise and bring an overload of choices – perhaps too many. http://redmonk.com/sogrady/2012/01/13/2012-predictions/
The New Year has people experimenting with new ideas and challenging popular arguments.
This week, we check out ideas and arguments across four different countries.
“The Project Portfolio Kanban Story: A Basic Approach”, by Pawel Brodzinski (@pawelbrodzinski).
This post captures a portfolio experiment. I like how the last column is titled “Maintenance” instead of “Done” – a friendly reminder that projects once deployed will need to be maintained. http://blog.brodzinski.com/2011/12/project-portfolio-kanban-basic-approach.html
Kanban for IT Services & Operations - Dearborn, MI Mar 12-13, 2012
David J. Anderson’s
An Official “Kanban - Successful Evolutionary Change for Your Technology Business” Class
with Dominica DeGrandis (instructor)
IT Operations & Services teams are often plagued by problems related to the constant flood of demands for their time. This 2-day workshop introduces how the Kanban Method can help Ops teams balance that demand against their capability to deliver. Teams who build and maintain software systems can realize many benefits from a strong alliance with internal and external customers. We will look at how using a service-delivery approach can help unify teams and promote cross-functional collaboration.
We begin by studying the demand on your team, department or organization and learn how to gather data to understand the capability of your system and how it operates. Discussions and interactive exercises on the Kanban Method will address the following topics:
- Specialization and bottlenecks
- Dependencies on external groups
- Interlude from never-ending work
- Early input mechanisms
- Variable task size
- Interrupt driven work
We will also look at ways to manage risks related to the increasing complexity around software delivery and support. Attendees play the “Kanban for Ops” version of the GetKanban game.
Working in small teams, class attendees will analyze and design a Kanban system that they can bring back to the organization to implement right away.
Based on David J. Anderson’s book “Kanban - Successful Evolutionary Change for Your Technology Business”, attendees of the class will receive a copy of the book.
Class Schedule
Day 1
Kanban Mechanics
- Demand Analysis
- Workflow Mapping
- Visualization
- Work Item Types
- Work-in-progress Limits
- Classes of Service
- Kanban Simulation Game - customized for Operations
Day 2
Kanban Progression
- Kanban System design
- Operations Review
- Case Studies
- Risk Management
- Metrics
- Service Level Agreements (SLA)
- Variability and predictability
- How to Get Started with Kanban
Is this for you?
This training provides a useful perspective for improving work done on the periphery of software development. If ever-more frequent deliveries from software development are increasing pressure on your teams and creating bottlenecks in the delivery process, look at Kanban to extend agility and balance to IT services and operations teams. From Data Administrative Services to Deployment & Release Managers to Help Desk, this class covers beginning to intermediate level material.
About the presenter
Dominica specializes in Kanban for IT Services and Operations - with teams interacting with software development. She spent her first 15 years in software engineering deeply embedded in Development teams performing builds, deployments and environment maintenance. She has worked in organizations of all sizes, from the US Army, Boeing, and AT&T to small start-ups. Dominica first worked for David Anderson at Corbis in 2006 where she helped deliver the first implementation of Kanban for software engineering in the US. Adept at leading teams performing Configuration Management and Release Management, Dominica found a passion for improving the way development and operations teams work together.
