cutter on kanban from leankit kanban

The Journal of Information Technology Management

Cutter IT Journal

REPRINT

The Viral Growth of Kanban in the Enterprise

Opening Statementby Masa K. Maeda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

An Agile Evolution: Why Kanban Is Catching On in Germany and Around the World by David J. Anderson and Arne Roock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Demystifying Kanban by Alan Shalloway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Kanban at an Insurance Company in the Netherlandsby Dan Verweij and Olav Maassen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Kanban for Help Desks: Managing the Unplannable by Roland Cuellar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Use of Kanban in Distributed Offshore Environmentsby Siddharta Govindaraj and Sreekanth Tadipatri . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Replacing a Bad ProcessProduces Better Results

An organization that is operating poorly isbetter off getting rid of its current processand taking on an entirely new one. Thatway the bad habits are eliminated at once,and things are done better from day one.

Evolving a Bad ProcessProduces Better Results

Taking your current process as a startingpoint and gradually improving it significantlyreduces resistance to change. It also reducesrisk because a small bad change is easierto fix and a small good change is easierto achieve.

LeanKit puts Kanban in the cloud witha whiteboard and sticky notes that areavailable from anywhere in the world,updated in real time, and configurablefor any industry. Whether it’s on a bigLCD screen in the team room, a PC ona desk, or your mobile phone or tablet,everyone can see what’s really goingon at a glance. And, since the historyof each card is automatically recorded,we can give you on-demand metrics tovalidate project dates, measure deliveryspeed, determine process variability,and balance workload.

http://www.cutter.com/itjournal.html

http://www.leankitkanban.com/

Cutter IT Journal®

Cutter Business Technology Council:Rob Austin, Ron Blitstein, ChristineDavis, Tom DeMarco, Lynne Ellyn,Israel Gat, Tim Lister, Lou Mazzucchelli,Ken Orr, and Robert D. Scott

Editor Emeritus: Ed YourdonPublisher: Karen Fine CoburnGroup Publisher: Chris GeneraliManaging Editor: Karen PasleyProduction Editor: Linda M. DiasClient Services: [email protected]

Cutter IT Journal® is published 12 timesa year by Cutter Information LLC,37 Broadway, Suite 1, Arlington, MA02474-5552, USA (Tel: +1 781 6488700; Fax: +1 781 648 8707; Email: [email protected]; Website:www.cutter.com; Twitter: @cuttertweets;Facebook: Cutter Consortium). PrintISSN: 1522-7383; online/electronic ISSN: 1554-5946.

©2011 by Cutter Information LLC. All rights reserved. Cutter IT Journal®is a trademark of Cutter Information LLC.No material in this publication may bereproduced, eaten, or distributed withoutwritten permission from the publisher.Unauthorized reproduction in any form,including photocopying, downloadingelectronic copies, posting on the Internet,image scanning, and faxing is against thelaw. Reprints make an excellent trainingtool. For information about reprints and/or back issues of Cutter Consortiumpublications, call +1 781 648 8700or email [email protected].

Subscription rates are US $485 a yearin North America, US $585 elsewhere,payable to Cutter Information LLC.Reprints, bulk purchases, past issues,and multiple subscription and site licenserates are available on request.

Part of Cutter Consortium’s mission is tofoster debate and dialogue on the businesstechnology issues challenging enterprisestoday, helping organizations leverage IT forcompetitive advantage and business success.Cutter’s philosophy is that most of the issuesthat managers face are complex enough tomerit examination that goes beyond simplepronouncements. Founded in 1987 asAmerican Programmer by Ed Yourdon,Cutter IT Journal is one of Cutter’s keyvenues for debate.

The monthly Cutter IT Journal and its com-panion Cutter IT Advisor offer a variety ofperspectives on the issues you’re dealing withtoday. Armed with opinion, data, and advice,you’ll be able to make the best decisions,employ the best practices, and choose theright strategies for your organization.

Unlike academic journals, Cutter IT Journaldoesn’t water down or delay its coverage oftimely issues with lengthy peer reviews. Eachmonth, our expert Guest Editor delivers arti-cles by internationally known IT practitionersthat include case studies, research findings,and experience-based opinion on the IT topicsenterprises face today — not issues you weredealing with six months ago, or those thatare so esoteric you might not ever need tolearn from others’ experiences. No otherjournal brings together so many cutting-edge thinkers or lets them speak so bluntly.

Cutter IT Journal subscribers consider theJournal a “consultancy in print” and likeneach month’s issue to the impassioneddebates they participate in at the end ofa day at a conference.

Every facet of IT — application integration,security, portfolio management, and testing,to name a few — plays a role in the successor failure of your organization’s IT efforts.Only Cutter IT Journal and Cutter IT Advisordeliver a comprehensive treatment of thesecritical issues and help you make informeddecisions about the strategies that canimprove IT’s performance.

Cutter IT Journal is unique in that it is writtenby IT professionals — people like you whoface the same challenges and are under thesame pressures to get the job done. Cutter IT Journal brings you frank, honest accountsof what works, what doesn’t, and why.

Put your IT concerns in a business context.Discover the best ways to pitch new ideasto executive management. Ensure the successof your IT organization in an economy thatencourages outsourcing and intense inter-national competition. Avoid the commonpitfalls and work smarter while under tighterconstraints. You’ll learn how to do all this andmore when you subscribe to Cutter IT Journal.

About Cutter IT Journal

Cutter IT Journal

Name Title

Company Address

City State/Province ZIP/Postal Code

E-Mail (Be sure to include for weekly Cutter IT E-Mail Advisor)

Fax to +1 781 648 8707, call +1 781 648 8700, or send e-mail to [email protected]. Mail to Cutter Consortium, 37 Broadway,Suite 1, Arlington, MA 02474-5552, USA.

SUBSCRIBE TODAY

Request Online LicenseSubscription Rates

For subscription rates for online licenses,contact us at [email protected] or+1 781 648 8700.

Start my print subscription to Cutter IT Journal ($485/year; US $585 outside North America)

Opening Statement

3REPRINT CUTTER IT JOURNAL

MOTIVATION

Let’s take two premises as a starting point: time is rela-tive, and technological advances have effectively mademany things happen faster. An expert is not necessarilysomeone with lots of gray hair or very little hair, and aproven technology is not necessarily one that has beenaround for a long time.

The Kanban method (not to be confused with thekanban developed as part of the Toyota ProductionSystem) was originated in 2004 during an attempt torescue a small IT team at Microsoft that was operatingso poorly — despite being certified as CMMI Level 5 —that it was about to be shut down. While assisting theteam, David J. Anderson developed a method whoseimpact was so impressive that the team won Microsoft’sEngineering Excellence Achievement Award just fivefiscal quarters later.1 Anderson applied and furthermatured the method at Corbis in 2006. When heshowed his work to some well-respected people in thelean and agile communities, they concluded it was anew and powerful method. Anderson published hiswork,2 and in 2008 Kanban’s actual growth began.

A method that made its public debut just three yearsago could be considered by many as very high risk andunproven. But if we consider that ISO took a couple ofdecades to be developed, published, and used world-wide, while the CMM took around 13 years to achievesimilar adoption and agile just six, then the pattern sug-gests that good things can happen more quickly now, astechnology allows us to communicate and collaboratemore effectively. In the September 2010 issue of CutterBenchmark Review on Kanban,3 I led a worldwide surveywhose results indicate that Kanban is already beingadopted in all regions of the world and by companiesfrom very small startups (fewer than a half-dozenemployees) to very large businesses (more than 50,000employees). Furthermore, around 60% of reports indi-cate an increase in productivity, around 65% report anincrease in quality, and around 70% report an increasein customer satisfaction from adopting Kanban as away of working.

CHALLENGES

I think Kanban is facing, and will face for a while, someunique challenges until it becomes better known:

What’s in a name? The first challenge is the nameitself. As I bring Kanban offerings to potential cus-tomers and am about to begin talking, time and timeagain I get that “Why is he telling us this is a newmethod when kanban has been around for decades?”look, because naturally they are thinking of kanbanin manufacturing. The Kanban method is not thesame as kanban for manufacturing, although theyshare the teachings of W. Edwards Deming as a com-mon base. The second challenge has to do with itsorigin. The Kanban method is a unique developmentinfluenced by the work of Deming (as noted), EliGoldratt, Donald D. Reinertsen, Mary and TomPoppendieck, the Agile Manifesto, the Declarationof Interdependence, and some kanban from manufac-turing. Such a pedigree motivates some people to callKanban an agile methodology, a second-generationagile methodology, a lean methodology, or a lean-agile methodology (my preferred term). Such diverseclassification tends to confuse those who are makingtheir first contact with Kanban.

Counterintuitiveness. Kanban is counterintuitive ina number of respects. For example, Kanban limits theamount of work in progress, which actually allowsyou to get more work done and with better quality.This makes most leaders stop for a moment andwonder whether such a thing is actually possible.As a result, some leaders decide not to try Kanban,whereas others see the potential and try it out.

Changes. Kanban is about gradual change — a gentlebut highly effective approach. We are so used to bigchanges and radical changes … the modern world isfast-paced, after all. So a gradual, incremental changecould be a challenge to the patience of some. Patiencewill pay off, though, as results show an actual accel-eration in the improvements the organization needs.

by Masa K. Maeda

Get The Cutter Edge free: www.cutter.com

http://www.cutter.com/research.html

©2011 Cutter Information LLCCUTTER IT JOURNAL 4

Unusual. We are used to replacing methodologiesor processes to make improvements. The Kanbanmethod is neither a project management methodol-ogy nor a process. It brings change and improvementto the way some activities — such as communication,coordination, planning, analysis, and reporting —take place. In other words, it will help you incre-mentally improve your current process, not replaceit. Adopting the Kanban method as a plug-in to anexisting process instead of as a replacement for itmay strike some as a bit odd.

Now, where does the rubber meet the road? Is Kanbanreally delivering? Are adoption results astounding,modest, or poor? Is Kanban for your organization? Thisissue of Cutter IT Journal brings you Kanban experiencesfrom diverse parts of the world to help answer thoseand other questions you may have.

KANBAN IN A NUTSHELL

Kanban was developed in response to the need toreduce resistance to change, handle risk and variabilityeffectively, exercise continuous improvement, andimprove the quality of work life. Improvementsfocus on:

Visualizing and managing the workflow

Limiting the amount of work in progress (WIP)

Making the process policies explicit (e.g., in the formof classes of service to define the behavior of, say,tasks, defects, and urgent tasks)

Identifying opportunities for improvement andcollaborating to address them

The Kanban wall shown in Figure 1 is a visualizationof a process that flows from left to right. It indicates themaximum amount of work in progress at each stage,differentiating classes of service by color (and with aunique lane in the case of expedited tasks). Notice thattasks are not clustered by blocks all together at onesame stage but rather flow through the process as eachindividual task is finished at each stage. Policies suchas classes of service are put into practice upon mutualagreement among all the stakeholders involved. AKanban wall does not have a fixed shape. It reflectsthe unique process for each project and changes as theproject itself matures.

IN THIS ISSUE

In our first article, David J. Anderson, the creator ofthe Kanban method, and Arne Roock, a lean and Kanbancoach in Germany, take Kanban’s adoption in that coun-try as a starting point to discuss aspects of the methodthat influence its adoption around the globe. The authorsdiscuss how Kanban went from being virtually unknownto “one of the most discussed topics in software develop-ment” in Germany and list what they consider to be thefive main reasons responsible for its introduction there.I would dare to say that diverse combinations of thosereasons are also applicable to most other countries inwhich Kanban is being adopted. The authors warn usthat Kanban’s growing popularity can lead to what theycall a “Kanban veneer” — implementations in which thevisible elements of Kanban (the Kanban board, WIP lim-its, stand-up meetings, etc.) are embraced but no truepull system develops. Such implementations, they say,leave Kanban’s full potential untapped. The last sectionof the article offers some eye-opening data that showsUPCOMING TOPICS IN CUTTER IT JOURNAL

DECEMBER Patrick Debois

Devops: A Software Revolution in the Making? — Part II

JANUARY Vince Kellen

IT Trends 2012

FEBRUARY Israel Gat

Big Agile

Figure 1 — A Kanban wall.

5Get The Cutter Edge free: www.cutter.com REPRINT CUTTER IT JOURNAL

how corporate and national cultures influence the speedof adoption.

Kanban’s adoption worldwide has been so quick thatthere is a risk some adopters will misinterpret it. AlanShalloway, founder of Seattle-based NetObjectives,begins his article with a comparison between Kanbanand agile methodologies, such as Scrum and XP, distin-guishing Kanban from the others by calling it a “sec-ond-generation” agile method. His paper has a strongenterprise flavor — unlike earlier “team-based” meth-ods, Shalloway says, Kanban addresses the entire valuestream. He discusses the four faces of Kanban, describ-ing its use as a lean-agile team method, a transitionmanagement system, a means of learning, and an aid toproduct portfolio management. He also addresses vari-ous misconceptions that have sprung up about Kanban.These discussions are helpful in understanding whatKanban is and is not. And if an organization is stillunsure, Shalloway closes with a test for determiningwhether or not an organization is actually doingKanban.

Next, Dan Verweij, a program manager at ASRInsurance in the Netherlands, and Olav Maassen, aprincipal consultant for Xebia (also in the Netherlands),tell us about the adoption and evolution of Kanbanat ASR. This case is a very good example of viralgrowth in the enterprise. They begin by relatinghow the company had adopted Scrum for projectwork but discovered that the method wasn’t a goodfit for its maintenance and operations (M&O) teams.So in August 2009, ASR launched a pilot project tointroduce Kanban as the M&O teams’ new way ofworking. Eighteen months later, 160 people in 18 teamsare successfully using Kanban at ASR. The authorscover the benefits of Kanban and the cultural, business,and communication difficulties ASR confronted duringadoption. They conclude with a set of their experience-gained recommendations for adopting Kanban.

In our next article, Roland Cuellar, director of programmanagement at Three Pillar Global in Washington, DC,gives us a case study on Kanban implementation at ahelp desk organization. He discusses the unique chal-lenges of a help desk organization’s work (what hecalls the “unplannable”) and explains why traditionaland even agile methodologies don’t quite fit in thatkind of organization. He then details how the team hewas working with was able to obtain immediate bene-fits simply by implementing some of the practices ofKanban and how those benefits increased over time.He closes with a discussion of the challenges the teamconfronted and the evolution of their implementation.

Last but not least, Siddharta Govindaraj, founder ofSilver Stripe Software in Chennai, India, and SreekanthTadipatri, an agile coach based in Bangalore, India, pre-sent their experiences using Kanban in outsourced proj-ects. They begin by discussing the limitations of typicalagile methods (e.g., Scrum) in such environments andoffer guidelines, punctuated by experience reports, forapplying Kanban to outsourced projects. The authorsidentify pitfalls to avoid and address some culturalchallenges that could derail Kanban adoption. Thisdiscussion is a good complement to the cultural aspectstouched on by Anderson and Roock.

NEXT STEPS

We hope this issue offers you diverse perspectives andenough information to help you make a decision onyour next steps regarding Kanban. It is also our hopethat you feel encouraged to further explore this recentbut rapidly growing and highly effective method.

ENDNOTES1Anderson, David J. Kanban: Successful Evolutionary Changefor Your Technology Company. Blue Hole Press, 2010.

2Anderson. See 1.3Piccoli, Gabriele (ed.). “Kanban for Project Management:Should We Buy In?” Cutter Benchmark Review, Vol. 10,No. 9, 2010.

Masa K. Maeda is a Senior Consultant with Cutter’s Agile Product &Project Management Practice whose primary focus is on Kanban andlean-agile project management. Dr. Maeda is also the founder ofShojiki Solutions, a coaching and training firm based in the SanFrancisco Bay Area that focuses on Kanban, lean-agile, and valueinnovation, and an associate with David J. Anderson & Associates.His over 24 years of experience include work at Apple Inc. doingdevelopment for the Mac’s operating system and as a founding teammember at startups in the life sciences (Ingenuity Systems), onlinevideo (Vuze Inc.), and online socialization (When.com) industries.Dr. Maeda was also a consultant who developed AI prototypesfor commercial applications and core technology algorithms forJustsystems Corporation, a leading software company in Japan.In Mexico, he worked for the financial and services industries.

Dr. Maeda founded the Bay Area chapter of the Limited WIPSociety and the Mexico chapter of the Agile Project LeadershipNetwork. He will begin teaching value innovation at UC BerkeleyExtension this year. He has a PhD in software engineering and arti-ficial intelligence and a master’s degree in intelligent systems engi-neering and information science from the University of Tokushima inJapan and a bachelor’s degree, with honors, in computer engineeringfrom the National University of Mexico. Dr. Maeda can be reached [email protected].


In April 2009, we conducted the first public Kanbantraining seminar in Germany — with two paying par-ticipants! At the time, Kanban was largely unknown inGermany; we assume that no more than a handful ofpeople had ever heard of it. No German Wikipediaentry existed for Kanban, let alone German-languageblogs or professional articles on the subject.

Today, a mere two years later, the situation haschanged completely. Without doubt, Kanban is oneof the most discussed topics in software development,and not just in the agile community. At each of thelarger software conferences, there will be at least onetalk focusing on Kanban, and IT magazines regularlypublish articles and experience reports about it. Wehave encountered a growing number of people whoalready implement Kanban in their teams.

How can one explain this rapidly increasing dissemina-tion? For what reasons do more and more teams andorganizations rely on Kanban? What pitfalls can pre-vent a successful introduction of Kanban? And do thephenomena we observe in Germany apply only to thiscountry? To what degree do they differ from the popu-larity and implementation practice of Kanban in otherEuropean countries and on other continents?

KANBAN: THE STATUS QUO

Contrary to popular belief, Kanban is neither a devel-opment process nor a management framework. Rather,Kanban is a method for advancing incremental, evolu-tionary changes in IT organizations through the adop-tion of kanban1 systems, which limit work in progress(WIP) and create a pull system where new work canonly be started as existing work is completed. TheKanban method is based on three foundationalprinciples:2

1. Start with what you do now.

2. Agree to pursue incremental, evolutionary change.

3. Respect the current process, roles, responsibilities,and titles.

In addition to these principles, five core practices havebeen observed in organizations that have been success-ful in achieving a culture of continuous improvementusing Kanban:

1. Visualize the workflow.

2. Limit WIP.

3. Manage flow.

4. Make process policies explicit.

5. Improve collaboratively (using models and thescientific method).

Kanban suggests that we start out with the actual stateof our process — no matter what this may look like —and proceed to further develop it in small steps. Wecannot foresee where our path will take us, and there isno predefined final state. If Kanban is understood cor-rectly, it will result in an organization that experiencescontinual improvement as time goes by and as the orga-nization becomes more familiar with its techniques. Insuch a kaizen (i.e., continuous improvement) culture,problems are individually identified and solved. Theteam will consistently make suggestions for improvingthe process and test these suggestions.

As evolution in nature creates highly specializedspecies (e.g., the bird-of-paradise, with its elaborateand long tail feathers, or the long-necked giraffe),Kanban leads to the creation of highly specialized sys-tems that are optimized to function in their respectivecontexts. Copying and applying a working Kanbansystem to another context will very likely not yield thedesired result.

A SHORT HISTORY OF KANBAN’S DISSEMINATION IN GERMANY

In less than two years, Kanban has emerged almostfrom thin air to become a method that is used by agrowing number of diverse teams and organizations.Besides Kanban’s various advantages and the publica-tion of David’s book Kanban: Successful Evolutionary


An Agile Evolution: Why Kanban Is Catching On in Germanyand Around the World by David J. Anderson and Arne Roock

KANBAN ON THE MARCH


Change for Your Technology Business3 in April 2010, therapid proliferation of this method can be explained bythree phenomena:

1. Conference reports. Some early adopters beganto use Kanban in spring 2009 and reported on themethod at several conferences. The key impetusfor these early adoptions was Kanban’s focus onflow and the absence of obligatory iterations. Forexample, Markus Andrezak, who pioneered Kanbanat mobile.de, always felt that the WIP of a Scrumsprint was still too much to manage in meetingswith the company’s offshore partner.

2. Influential articles. A number of IT magazinesdeveloped an early interest in Kanban, which ledto the publication of various articles about thismethod. First and foremost, the popular IT magazineOBJEKTspektrum published a special issue aboutlean and Kanban in March 2010, as it recognized thetremendous potential of Kanban, which was then rel-atively unknown. Besides introductory articles, thesame magazine also featured two experience reports:one by mobile.de (the biggest German Internet salesportal for used cars) and one by XING (a professionaland social networking Web site similar to LinkedIn).Kanban’s popularity was further fostered by a com-prehensive feature published in the June 2010 editionof the monthly computer magazine iX, as well as byan online article on Heise Developer Channel. Thelatter is one of the most frequently called-up articlesever posted by the channel.

3. The insufficiencies of Scrum. Kanban became popu-lar in Germany at a time when many companies hadbeen using Scrum for several months and found it —for various reasons — to be very challenging. Theevolutionary character of Kanban was and is attrac-tive to these organizations, which face the task ofimproving (partially incomplete) Scrum implementa-tions in small increments. While Scrum blazed a trailfor agile in Germany and provoked a lot of interest inagile ideas, it appears that it is not the best cultural fitfor all companies. It might be said that the adoptionof Kanban is partly a learning effect of up to 10 yearsof experience with Scrum (and XP).

The quote “It is difficult to make predictions, especiallyabout the future” (attributed to everyone from NielsBohr to Yogi Berra) definitely applies to Kanban.However, we feel it is safe to assume that Kanban’s pop-ularity and usage will continue to grow in Germany in2011. David’s Kanban book is now available in German,and it’s supplemented by an additional chapter contain-ing an experience report about portfolio management

with Kanban at mobile.de. The publisher reported thatinterest in the first week of sales was greater than forany other technical book the company had previouslypublished. This is a further indicator that interestin Kanban continues to grow strongly in Germany.Moreover, Siemens and at least one other leading inter-national German corporation are currently introducingKanban. This should further help to establish Kanbanas a suitable method for big businesses. In addition,several large enterprises, among them a major Germaninsurance company, have explicitly added Kanbanknow-how to their requirements for hiring internalcoaches.

THE MAIN REASONS FOR USING KANBAN

There are five main reasons for the introduction ofKanban in Germany:

1. Iteration Problems

Like agile methods, Kanban firmly relies on simplicity,regular feedback, direct communication, empowermentof employees, and teamwork, but it does not requirethe use of the timeboxed increments referred to as“iterations” in most agile literature. Due to Scrum’soverwhelming success in the last few years, many orga-nizations had high expectations regarding this methodbefore they realized that sprints (the Scrum term fora timeboxed increment of functionality) are not wellsuited to their purposes. This has proven particularlytrue in the media industry, which globally has been asignificant early adopter of Kanban, with examples suchas the BBC, Sky, IPC Media, the Financial Times, andLonely Planet.

When organizations attempt to adopt agile methods,a mismatch between the process prescription and thenature of their domain can cause them to reject thenew approach and revert to their previous (typically“conventional” or “traditional”) way of doing things.This has been particularly true with Scrum, where thecommunity has encouraged adoption “by the book”and publicly discouraged adaptation. Kanban, on theother hand, offers the opportunity to build on what isalready working well and design out existing problemsand challenges one at a time.

The key impetus for the early adoptions wasKanban’s focus on flow and the absence ofobligatory iterations.



Teams that frequently run into considerable problemswith timeboxed iterations include those performingongoing maintenance and production support orshared organization resources such as architecture,security, user experience design, database administra-tion, business intelligence, and devops (or configurationmanagement). Such teams have to tackle vastly differenttasks (with regard to scope, origin, technology, urgency,etc.), and their work is dominated not only by unpre-dictable events, but often by emergencies as well.Usually even one-week sprints are too restrictive forthem. At the same time, it is becoming clear that someWeb startups feel hampered by iterations, too, becausethey perceive a flow-based work method to be morefavorable (and more innovation-friendly) than strictiterations. This is exemplified by the strong adoption ofKanban among such online service firms as CityGridMedia, Constant Contact, Ultimate Software, XING,mobile.de, Spotify, BWin, and ICA.

2. Evolutionary Changes

Large organizations in particular have a hard time mak-ing disruptive changes that would result in completelychanged work methods and roles. In many cases, suchchanges will be enforced only if a company stands withits back against the wall — perhaps because an impor-tant project is about to fail or competitors are gaining.Cutter Senior Consultant Kent Beck shared this assess-ment during a lecture in Hamburg in October 2010: “Thepace of change is what people are willing to accept. Onlywhen an organization is close to death will it changevery fast.” Therefore, changes made in small increments— as with Kanban — are generally preferable.

3. Affinity with Lean

Top management — especially in big corporate groups— is often familiar with at least the basic ideas behindlean approaches and already know some lean conceptsfrom production. Since Kanban is recognized as partof the lean body of knowledge, its chances of beingaccepted and supported by top management teamsare good.

4. Portfolio Management

Kanban can be applied with good results for visualizingentire projects on a strategic level, speeding up theirimplementation, and improving the process for port-folio management. The latter explains why more andmore organizations use Kanban to manage their portfo-lios, whereas single projects are run using Scrum. Thefact that portfolio management with Kanban is compar-atively popular in Germany can probably be attributedto Andrezak, who did some groundbreaking work inthis field at mobile.de and early on made his experi-ences available to the public.4

5. Multitasking

During the past few months, it has become increasinglyclear that Kanban is of interest to a large field of userswho, for the most part, never dealt with lean approachesor agile methods before. We are referring to small andmedium-sized Web agencies, which traditionally strug-gle with an extremely high degree of multitasking (oftenwith individuals working on 20 or more tasks simul-taneously). Kanban enables such firms to visualize theamount of work and they have to focus on a smaller setof urgent and critical tasks. This enables them to getmore work done, faster, and to deliver it when mostappropriate.

BEWARE “KANBAN VENEER”

The most common problem we observe with Kanbanimplementations can be described as “Kanban veneer.”The workflow is visualized on a whiteboard, tickets aremoved across the board, and daily stand-up meetingsoften take place, too. In this manner, a high level oftransparency about the status quo of tasks and cur-rent problems can be obtained in very little time. YetKanban’s real potential will remain untapped untila real pull system is established and employees areempowered to make independent team-based decisionsabout how to distribute work, how to solve problems,and how to improve processes.

In many cases, company management is either unableor unwilling to give up established command-and-control micromanagement and trust employees to makedecisions. Managers are fearful that delegating decisionmaking obviates their position. They fail to switch intoa mode where they act as the system designer and focuson decisions about process policies rather than decisionsabout work in progress. At the same time, teams oftenfail to collaborate on kanban system design and policy

Kanban’s real potential will remain untappeduntil a real pull system is establishedand employees are empowered to makeindependent team-based decisions.


setting. Instead, they take the current state for grantedor leave all changes to the system designer.

Symptoms of a Kanban-in-name-only implementationinclude:

A fast lane that is always full (meaning we’re increas-ing lead time and losing predictability concerningthe non-expedite tickets)

A static system that does not improve (the boardlooks exactly the same today as it looked oneyear ago)

Exceeded or constantly raised WIP limits (becausethe actual system capacity does not meet the demandand, instead, new tasks are repeatedly pushed intothe system)

The term “veneer” is apt because only two core proper-ties — visualization and WIP limits — are observed,and though visible from the outside, they are beingundermined from within. Hence, a Kanban veneerexists, but a true pull system does not. Such a veneerprevents the formation of a reliable and predictablekanban system; it also suppresses discussion of changeopportunities and therefore the development of akaizen culture.

KANBAN ADOPTION AROUND THE WORLD

In the last two years, Kanban has been catching onaround the world. In South America, examples havebeen reported in Argentina, Brazil, Chile, and Peru. Thebest known of these include Phidelis, a software com-pany from Vitória, Brazil; CESAR, an outsourcing firmin Recife, Brazil, rated at CMMI Level 3; Huddle, anoutsourcing firm in Buenos Aires, Argentina, that spe-cializes in the media industry; and the IT department ofPetrobras, the Brazilian state-owned oil company andone of the largest firms in South America. David’s bookis now available in Spanish and will soon be publishedin Portuguese.

The reasons for Kanban adoption in South Americavary. Outsourcing firms appreciate the service-orientednature of Kanban and desire a culture of continualimprovement in order to achieve a competitive edge.Firms such as Phidelis like the flexibility to respondrapidly to changing customer demands as well as thecultural aspects of Kanban, which have enabled themto stay very small while capturing a very large marketshare. Larger firms seem to value the governanceaspects of Kanban, which allow a better connectionbetween shop-floor processes, market demands, andexecutive decisions. Firms such as Petrobras have been

able to merge together multiple smaller teams intolarger teams with greater labor flexibility and criticalmass to respond to customer demand. This trend hasbeen seen elsewhere at firms such as Constant Contactand Ultimate Software in the US.

Kanban is also increasingly adopted in the Benelux,with firms as diverse as several-hundred-year-old insur-ance companies in the Netherlands, government depart-ments in Belgium, and smaller consulting and trainingfirms using it for marketing and business development.

Kanban has perhaps its strongest market inScandinavia. Sweden was the earliest adopter, withfirms from large industrial groups, such as Volvo andScania, to small mobile games and online gamblingfirms taking an interest. One of the best-knownadopters is Spotify, the music streaming service.Examples of Kanban adoption also exist in Finland,Norway, Iceland, and Denmark, including one earlycase study reported at the Danish Ministry of Defense.

In South Africa, a large bank in Johannesburg report-edly adopted Kanban in 2010. And in the southernPacific, there are reports of Kanban usage at LonelyPlanet, the Australian travel guide publisher; at gamesdevelopment firms in Australia; and at the Ministryof Social Development in New Zealand.

During 2010 Kanban was also rapidly adopted in Israel.Reported case studies include Amdocs, Israel’s largestindigenous software firm, famous for its telecommuni-cations billing software; Internet firm answers.com; andsoftware tools startup Typemock. What is remarkableabout these examples is their breadth. From a small,less-than-20-person software tools vendor, to a 100-person Internet service, to a large software solutionsvendor with tens of thousands of employees, Kanbanis proving useful in diverse ways.

CULTURE AND KANBAN ADOPTION

Kanban has become firmly established on five conti-nents in the last two years. This adoption has largelyhappened faster than the adoption of agile methods 10years earlier. The early adopters of agile methods —the Swedes, the London-based banking industry, and

In the last two years, Kanban has beencatching on around the world.



software firms on the East and West Coasts of the US — were once again the earliest adopters of Kanban.Kanban offered them solutions to problem spaces whereagile methods had proven a challenging fit.

What is more remarkable is the adoption of Kanbanin other parts of the world and how rapid it has been.Kanban adoption in the Benelux is almost as prevalent asin Scandinavia. The same is true regarding demand forKanban classes and firms offering such classes. This isremarkable, because the adoption of agile methods in theBenelux trailed that of Scandinavia by about six years.

Likewise, agile methods were slow to be adopted in themore conservative parts of Europe, such as Germany,France, Italy, and Spain, but again we see significantadoption of Kanban in the last two years in thesecountries, including by an automotive firm in Italy.

It is worth asking why this might be. Why is Kanbanbeing adopted faster across a larger number of countriesall around the world? It may be true that agile methodshave blazed a trail and created a community and a mar-ket that have embraced the Kanban meme. However, itseems that Kanban appeals to a much broader market.

Firms with CMMI Level 3 and Level 5 appraisals havebeen adopting Kanban. Firms that had ignored the agilerevolution, such as answers.com, have adopted Kanban.Kanban is finding a niche in devops and IT operationsdepartments. It is also growing in popularity in indus-tries with large numbers of specialist functions, suchas games and investment banking, and with firms inrapidly changing domains such as media.

It appears that Kanban, which by its nature is designedto be adopted in a minimally invasive way thatembraces the status quo and provides a frameworkto prompt slow but steady evolutionary change, ismore appealing than agile to a broader spectrum ofpeople and businesses. Kanban is popular with liberal-thinking innovators who work in high-trust cultures,but it appears to appeal equally to conservative, slow-moving industries and to professionals who work inbureaucratic, lower-trust organizations.

Figure 1 shows a two-dimensional space divided ontwo axes. The x axis spreads from ultraconservative(meaning very reluctant to embrace change) through toultraliberal (meaning very enthusiastic to embrace newideas). The y axis spans from very low-trust, low–socialcapital cultures through to high-trust, high–social capi-tal cultures. The positions of various countries on they axis are extrapolated from Francis Fukuyama’s workin sociology.5 The positions along the x axis are basedmore on our empirical observations from traveling theworld and experiencing these cultures. So Sweden is arelatively high-trust country with a very liberal attitudetoward business, while the Netherlands and Japan arevery high-trust countries with a more conservativeattitude toward business.

Figure 1 maps agile method adoption until about 2003.It is worth observing that agile methods were adoptedin highly liberal cultures first. While agile methods needa high-trust culture in order to work, the existence of ahigh-trust culture did not correlate with early adoption.Agile adoption in Japan, the highest-trust country of all,is still extremely low after 10 years.

Using the same axes, Figure 2 maps the adoption ofKanban since 2007. Note that the adoption is wider andthat the more conservative cultures have adopted itfairly rapidly. We attribute this difference specificallyto the evolutionary, incremental nature of Kanban. It ismore appealing in conservative cultures than the revo-lutionary approach required by some agile methods.

We can see that Kanban is still relatively unknown inChina and India and that adoption of the method in thispart of the world is much slower than elsewhere. Agile

Hig

h T

rust

Low

Tru

st

Conservative Liberal

Japan

Holland

Germany

Belgium

France

Latin America

India

China

Scandinavia

UK

Coastal USRest of US

Figure 1 — Early agile adoption.

Firms that had ignored the agile revolutionhave adopted Kanban.


methods have also struggled in these countries. At thistime, we can offer no explanation for this phenomenon.However, David is planning a trip to this region in 2011to raise awareness of Kanban.

SUMMING UP

Kanban has spread rapidly in Germany during the pasttwo years. On the one hand, Kanban is attractive tobusinesses that have problems with the iteration con-cepts required by many agile methods. On the otherhand, Kanban is interesting, particularly for large com-panies, because changes are made in small incrementsand because of its affinity with lean approaches. On astrategic level, portfolio management with Kanban isbecoming more and more common. Finally, we haveobserved another recent development; namely, smalland medium-sized Web agencies beginning to adoptKanban to tackle the multitasking problems that areparticularly prevalent in this sector.

It appears that Kanban is catching on rapidly in partsof the world that have already embraced agile methods.Yet Kanban also appears to be offering an alternativeapproach to organizations that were struggling withagile adoption or had decided that agile methods werenot for them, even though they still desired the benefitsof agility and improved economic performance.

It is also noteworthy that Kanban adoption is occur-ring in a wide set of circumstances, from IT operations,devops, software development, and project manage-ment through to portfolio management. The natureof Kanban as an evolutionary, incremental approachto change management seems to be resonating withpeople and giving them hope that they can find away to improve their processes and their organization’sperformance. The Kanban community has encouragedexperimentation, and some of these experimentsappear to be bearing fruit. Reports such as thosefrom mobile.de can only encourage others to try.Consequently, in early 2011 we have considerable hopefor further, faster, and wider adoption of Kanban bothin Germany and throughout the world.

ENDNOTES1In this article, we use the term “Kanban” (with a capital K)to denote the evolutionary change method that uses a kanban(small “k”) pull system, visualization, and other tools to cat-alyze the introduction of lean ideas into technology develop-ment and IT operations.

2Anderson, David J. “The Principles of the Kanban Method.”David J. Anderson & Associates, 10 December 2010 (http://agilemanagement.net/index.php/site/the_principles_of_the_kanban_method).

3Anderson, David J. Kanban: Successful Evolutionary Change forYour Technology Business. Blue Hole Press, 2010.

4Andrezak, Markus. “Feeding the Kanban — Portfoliomanage-mentbei mobile.international GmbH” (in German). In David J.Anderson, Kanban: Evolutionäres Change Management für IT-Organisationen, translated by Arne Roock and Henning Wolf.dpunkt.verlag, 2010.

5Fukuyama, Francis. Trust: The Social Virtues and the Creationof Prosperity. Free Press, 1995.

David J. Anderson has been a manager and leader of great softwareteams delivering cutting-edge software products since 1991. He has asuccessful track record of building progressively bigger teams capableof hyperproductive performance and superior quality. Mr. Andersonis a founder of the Lean Software & Systems Consortium, a nonprofitorganization that seeks to bring a new level of professional conductand capability to the software and systems engineering professions.He also helped create the Limited WIP Society, a loosely affiliatedorganization that encourages the development of a community ofpeople using kanban (and other pull) systems in software engineer-ing and project management. Mr. Anderson can be reached at [email protected].

Arne Roock works as a coach and trainer for it-agile GmbH inGermany. As an expert on lean and Kanban, he’s been observingthe evolution of Kanban in Germany over the past few years. Mr.Roock has written several papers on lean/Kanban and translatedinto German David J. Anderson’s book Kanban: SuccessfulEvolutionary Change for Your Technology Business. Mostrecently, he cofounded the first Limited WIP Society in Germany.Mr. Roock can be reached at [email protected].

Hig

h T

rust

Low

Tru

st

Conservative Liberal

Japan

Holland

Germany

Belgium

France

Latin America

India

China

Scandinavia

UK

Coastal USRest of US

Figure 2 — Kanban adoption since 2007.



Ask the question “What is Kanban for software devel-opment?” and you are likely to get many differentanswers. It is a powerful new method that addresseschallenges previous methods have not. It is a transitionmanagement system. It is a more effective method forteams to deliver business value incrementally. It is away to create visibility for executives to improve prod-uct portfolio management. It is all of those things andmore. It is like that Saturday Night Live spoof in whichGilda Radner and Dan Aykroyd argue over whetherNew Shimmer is a floor wax or a dessert topping; theyfinally decide it’s both!

In this article, I describe Kanban as a systems approachto software development that affects many types ofbehaviors. I also mention a few of the common miscon-ceptions people have about Kanban in order to helpclarify what Kanban is and is not.

ITERATIVE AGILE

Agile software development has been embraced bymany in the software industry. First-generation agilemethods, such as Scrum and XP, took an incrementalapproach based on well-defined, timeboxed iterations(which Scrum calls “sprints”). The team commits tobuilding a certain number of product features they feelthey can reasonably accomplish within that increment.At the end, they see how they performed so that theycan refine their commitments for the next timebox.

The advantages of an incremental approach include:

Promoting an understanding of the need forprioritization

Requiring the team to finish the work theyhave started

Protecting the team from interruptions anddistractions

Defining regular intervals for the business to adjustpriorities in order to ensure the team is working onthe right things

Defining regular intervals both to demonstrate whathas been built and to gain user feedback while it isstill useful

These agile methods require cross-functional teamswhose members focus only on their team’s work. Across-functional team is one that contains most or all ofthe resources needed to perform the activities requiredto deliver product: analysis, design, coding, and testing.If you can afford it, cross-functional teams are indeedpowerful; in fact, you may gain as much value merelyfrom employing cross-functional teams as you wouldfrom using an agile method.1, 2 The reality, however,is that many organizations cannot afford wide-scaledeployment of exclusive cross-functional teams. Thisis an impediment to scaling these methods to theenterprise.

Another impediment is that team-based agile methodsdo not effectively address one of the most common prob-lems in development: more things being pushed ontoteams than they can handle. Team-based approachesstart at the wrong end, attempting to insulate or protectthe team from intrusions. This fails to address overallcapacity, has the side effect of isolating teams from man-agement, and actually works against scaling.3 The betterapproach is to provide visibility to those generatingwork — executives and management — so they cansee the impact of overloading teams. They need tosee this both at an individual team level and, moreimportant, for the entire value stream.4 Creating agilityat scale requires an approach that handles the entirevalue stream.

ABOUT KANBAN

Based on lean principles and the theory of constraints,Kanban is a second-generation agile approach thataddresses the entire value stream and overcomes thechallenges inherent in team-based agile approachessuch as Scrum and XP. The motivations behindKanban include:5

Demystifying Kanban by Alan Shalloway

DOWN BY THE OLD VALUE STREAM


Controlling the rate of transition. First-generationmethods often require traumatic change to the peopleand structures in the organization.

Allocating specialized skill sets, domain knowl-edge, or knowledge of legacy code effectivelyacross the organization. Dedicated and relativelystatic teams, while desirable, are usually not practicalin this regard.

Enabling participation of management andleadership. Scrum often marginalizes management.

Providing teams with guiding principles, especiallythe principles of lean and the theory of constraints.

Providing a better way to learn how to improve.End-of-iteration retrospectives are too narrow andtoo late to be valuable over the long haul.

Enabling teams to work on the right-sized chunks.With timeboxing, work gets squeezed into a pre-defined period and unrelated bits of work getgrouped into one sprint.

In this section, I will describe how Kanban acts as:

A lean-agile team method

A transition management system

A means of learning

An aid to product portfolio management

Kanban as a Lean-Agile Team Method

One of the premises of Kanban is that, to be efficient,teams must not become overloaded. Overloading teamscauses thrashing, creates waste, lowers quality, andharms capacity. Getting to a sustainable load requiresfocusing on how many things a person is working onat any one time: too few results in ineffective loadingof the team; too many results in additional work causedby delays.

Timeboxing does help with this because the team limitsthe amount of work they will allow into the iteration.The problem has been made small enough for the teamto handle — however, it is not helpful to anyone else.Everyone else must adjust work and priorities toaccommodate the team.

Kanban has a different focus. It is based on a commit-ment to optimizing the flow of work across the entirevalue stream: the work that is done from when an ideais initiated until it is consumed by the customer (inter-nal or external). This broader perspective enables abusiness-driven approach. Kanban’s methods providefor team management within the context of the broader

value stream. It requires participants across the valuestream to understand the lean tenet of avoiding toomuch work in progress (WIP) and the techniques fordoing that. Kanban assumes that improvements aredesired beyond just individual team performance.What is Kanban’s method for avoiding too much WIP?It takes the following approach:6

1. Make all work visible.

2. Have management and the team agree on a set ofgoals. This involves those upstream of the team, theteam itself, and those downstream.

3. Define where the Kanban method will be applied. Forexample, Kanban addresses the team’s work from thepoint at which they consider items on their backloguntil they deliver that work to the customer.

4. Create a board that reflects the team’s flow of work.

5. Educate the team on the principles of flow and pull.

6. Start managing the work with pull methods and setWIP limits that maximize flow through the system.

7. Define explicit policies that control the flow of workand continuously improve them.

Here is one more issue to consider under the topic ofteam management: managing the various points ofinterface with the business. There are at least four:

1. When the business gives work input to the team

2. When the state of development is evaluated

3. When features are demonstrated to stakeholders

4. When the team and the business commit to whatwill be done next

Kanban does not require timeboxing and thereforedecouples these event points by allowing them tohappen at different times. However, most Kanbanteams have found it useful to update and reviewKanban backlogs at regular intervals. This is calledthe “cadence” of the team. Be clear, however, that thisis not the same as a timebox.

MISCONCEPTION: KANBAN IS SCRUM WITHOUT ITERATIONS

Kanban can actually be done with iterations if there is abusiness or team reason to do so. Teams that have littlediscipline in finishing things may find the hard stop of theiteration to be useful. But most find them an unnecessaryinterruption and a cause of extra work.



Kanban as a Transition Management System

In the best of circumstances, change is hard. The mostsuccessful change efforts involve explicitly managingthe transition. This lowers resistance and increasesinnovation and results.

Scrum can present challenges in transition. Right fromthe start, it demands new organizational structures (e.g.,cross-functional teams) and requires people to assumenew roles and a new set of practices, while providingthem little guidance. This can be traumatic to the organi-zation and certainly causes resistance.

Kanban takes a different approach to transition. Youstart where you are and incrementally improve the

bottlenecks in the whole value stream, guided byexplicit policies and data. This is an important distinc-tion. Except in the case where cross-functional teamsare easy to form and people are happy with change, amore transition-friendly approach is required. In otherwords, if the proposed change is more than the peoplecan cope with, a way of improving throughput withouta dramatic team organizational shift will be needed.

In Kanban, the goal is to improve work by removing thebottlenecks in your workflow. Where there are issues,management and the team can do load balancing bychanging how they are doing the work or who is doingthe work. This makes transition a series of easier stepsalong the journey toward optimal flow across the valuestream. It is much easier on the organization.

Kanban as a Means of Learning

Kanban addresses the maxim “People know what todo; they don’t always do what they know.” By creatingclarity on the effects of their actions, Kanban encouragespeople to do what they know.

This approach to improvement requires high-qualityconversations between the various stakeholders,developers, and leaders. They need to remember whathas been agreed to (the current basis), know the factsabout what is happening (the current situation), andbe clear about what will change (the new basis). Kanbanrequires both the work itself and how the work is doneto be clear to everyone. This means using explicitprocess policies to define the basis of work. Improve-ment happens by:

Identifying problem areas by measuring queues onthe Kanban board

Developing a new or revised policy or changingthe current WIP limit

Seeing what the effect these steps have on smoothingout queues

Kanban focuses the team’s energies on improving thoseareas in the value stream that are truly constrainingother work (and thus, harming flow through the valuestream). It helps avoid wasting time on activities thatdo not really help flow. By having a before, during, andafter action method of making small changes, the teamlearns what works and what doesn’t.

Here is an example. Say there is a bottleneck in gettingthings tested. With Kanban, the queue of work in frontof the testing team reaches a limit so it cannot receiveany more work. Developers are restricted from doingmore coding. This is good, because coding more in this

MISCONCEPTION: KANBAN SUGGESTS LINEARWORK AND REQUIRES TOO MANY HANDOFFS

Actually, Kanban does nothing of the sort. It suggests thatyou start where you are. If you have too many handoffs, theKanban board will make this clear. Kanban believes changesmade by the team are best made when the team under-stands the cost of current practices, decides what to do,and then sees the results of their work.

MISCONCEPTION: EXPLICIT POLICIES ARE STATIC,DETERMINISTIC, AND HARD TO CHANGE

None of these is true. One can have a policy that states:“Our policy is that you do what you want, when you want todo it.” That’s explicit, not static, not deterministic, and nothard to change. It also isn’t very useful. Nevertheless, itproves the point that “explicit” does not mean any of thesethings. It simply means that everyone has talked thingsthrough and understands what the policies are.

MISCONCEPTION: KANBAN IS NOT“PEOPLE FRIENDLY”

Talking about people does not make a method peoplefriendly. Actually helping people makes a method peoplefriendly. Kanban is a systems thinking approach to solvingthe problems people have — which is very people friendly.


situation would be counterproductive — it would justincrease the time between coding and testing evenmore. Looking at the queues, it becomes obvious thatthe team needs to determine how to get testing morein step with coding. Perhaps the team will decide to docoding and testing together;7 perhaps they will get moretesters or offload other work from the testers so theycan concentrate on testing. Kanban does not specify thesolution, but it does identify the problem and the resultneeded to solve it (i.e., reducing the queues).

Kanban’s learning method is therefore integrated intoits management method. This is both its power andwhy it is sometimes not fully appreciated. In team-based agile methods, much of the learning occurs atthe end-of-iteration retrospectives. These retrospectivesproduce useful results early on but then grow stale aschanges produce less dramatic results. What to do? Youcould tell teams just to keep at it, to limit the number ofchanges in each sprint, or to learn how to run retrospec-tives more effectively. But these don’t attack the realproblem: focusing too much on the local team and notthe larger value stream.

The problem is that learning at set stages is not nearlyas valuable as learning continually. Developers are aninteresting lot. One of their bigger strengths is their pas-sion. Yet it is just this passion that often prevents themfrom stepping back and seeing if there are better waysto do things (hence, the prescribed Scrum retrospective).Through the use of the Kanban board, which makes vis-ible the consequences of the team’s decisions, Kanbanprovides a way to learn continually. Team members nolonger need to “step back” to learn.

The use of explicit policies in Kanban helps peoplevalidate their understanding about what to do. And itenables both teams and management to see cause andeffect whenever they make a change; thus small adjust-ments lead to quick results.8

Kanban as an Aid to Product Portfolio Management

One of the most chronic and severe problems facingsoftware development today is that teams are over-loaded with work. Working on multiple things obvi-ously delays the delivery of any one particular item,but what is not as obvious is that the delays betweenthe different work steps (e.g., writing a story and codingit, or coding a story and testing it) can actually increasethe amount of work to be done. This is because workoften has to be redone (as in the case of requirements)or what was in the short-term memory of the develop-ers has to be relearned in order to complete the task(as in the case of debugging).9

Managers become frustrated when jammed develop-ment teams fall behind and will actually demand thatthey do more — creating even bigger jams. To breakthis cycle, it is not sufficient to simply improve a team;you must help management understand the impact oftheir demands. Through the Kanban board, Kanbanoffers explicit tools that provide visibility and helpmanagement make appropriate decisions about tasksbased on business value. The result is that teams areless overworked and more focused on the right things.

In Kanban’s flow model, in which team members justpull things off the backlog whenever they are ready,new items coming in can be worked on very quickly.Unfortunately, timeboxed methods require teams towait until the beginning of the next iteration to takeon something new or unexpected, things that are alltoo common: Severity 1 errors, demands from an irateclient, an executive’s “good idea,” and so on. Scrumlacks an explicit way to handle these situations. While itwould like to protect the team from such interruptions,in reality the team gets pressured to add in the extrawork, but they have no way to demonstrate the impactsof this on management.

In his book Kanban: Successful Evolutionary Change forYour Technology Business, David J. Anderson offers agreat example of how visibility can help managers makegood decisions. In the example, a team agreed thatproduct managers could ask team members to work onan urgent item even if it caused them to exceed theirWIP limit. However, they would not be asked to workon more than one urgent item at any one time. Theirhistory of managing via WIP limits had demonstratedthat going beyond them would slow the team down,but they also recognized that at times an urgent situa-tion demands that.

Sure enough, the day arrived when a manager playedthe “expedite” card. Interestingly enough, David didnot challenge it. If it made business sense to get some-thing out the door at the expense of everything else, sobe it — that was what the team needed to do, and it wasa product manager’s decision. But someone else shouldchallenge the decision, and someone did. That “some-one” was the other product managers. They demandedthat the first product manager explain why expediting

One of the most chronic and severe problemsfacing software development today is thatteams are overloaded with work.



his work at the expense of others’ was a good decisionfor all involved. By creating visibility into the team’sprocess, Kanban clarified the impact of adding “justone more thing” to the team’s load. All the productmanagers could see the impact of what, and how much,the team was being asked to do. In this way, Kanbanhelps organizations avoid the local optimizations thatteam-focused methods tend to inadvertently encourage.

SOME COMMON MISCONCEPTIONS ABOUT KANBAN

Let me close with a few comments about some otherKanban misconceptions:

Kanban has been successful because it is beingdone by early adopters. Actually, Kanban is usedby several different camps. First, there are the earlyadopters, who have created and refined it. They cre-ated Kanban software development to benefit theother two camps, the first of which is organizationsthat found other agile methods difficult to apply. Thesecond camp consists of those who were late adoptersof Scrum because Scrum required too much changeto adopt. In addition, the success of Kanban has ledmany organizations new to agile to adopt it directly.

It is better to start with Scrum and then moveto Kanban. This idea originated with the Scrumcommunity, and I have always considered it a bitself-serving. While it is true that Kanban requires acertain understanding of lean principles, it doesn’trequire organizations to learn prescribed practicesand roles to get started. Many teams do start withScrum and then move to Kanban, but typicallyonly because they were not aware of Kanban atthe beginning.

Kanban is mostly good for support. Many practition-ers started using Kanban in support environmentswhere it didn’t make sense to batch up small piecesof work to create sprints. However, other teamsworking on new projects with more sizable featureshave found Kanban works equally well regardless offeature size. In the same way that Kanban provides achoice of using iterations or not, it provides a choiceof whether to break features down into smaller

pieces. Experienced teams have found it useful towork on smaller stories in order to get quicker feed-back on both design considerations and from the cus-tomer. Where breaking features down does not makesense, however, Kanban does not demand it. This isanother example of the way Kanban enables teamsto decide how fast they change their practices.

IS IT KANBAN? PUT IT TO THE TEST

Perhaps the best way to define Kanban is to define atest that indicates whether you are doing it or not. Ateam can be considered to be doing Kanban if do thefollowing:

Make all of their work visible.

Limit their work in progress to their capacity.

Manage their workflow in order to improve cycletime (the time it takes from starting work on thefeature until it is completed).

Make all process policies explicit.

Improve collaboratively and continuously basedon facts and explicit policies.

Notice that the proof you are doing Kanban does notlie in following certain prescribed practices, but ratherin attending to particular elements of your work.

TO RECAP

Kanban is designed to overcome the three largestimpediments to agile adoption beyond the team level.These are:

1. The trauma often caused by creating cross-functionalteams as required by other agile methods.

2. Too many feature requests hitting the teams, causingthem to thrash.

3. Lack of sustained learning after initial adoption.

It addresses these problems by applying solid leanprinciples, including:

Reduce delays by limiting work in progress to thecapacity of the team.

Create visibility in both the work being done andthe way the work is being done.

Include management in the transition.

Explicitly incorporate learning and knowledgestewardship.

While it is true that Kanban requires a certainunderstanding of lean principles, it doesn’trequire organizations to learn prescribedpractices and roles to get started.


Kanban is proving itself highly effective in many con-texts. Many XP- and Scrum-based teams have found itto be helpful in overcoming challenges they have had,challenges that they might not have had if they had juststarted with Kanban.

ENDNOTES1Shalloway, Alan. “Challenging Why (Not If) Scrum Works.”NetObjectives, 24 May 2007 (www.netobjectives.com/blogs/challenging-why-not-if-scrum-works).

2Shalloway, Alan. “How Successful Pilots Actually OftenHurt an Organization.” NetObjectives, 3 October 2010(www.netobjectives.com/blogs/how-successful-pilots-can-hurt-the-organization).

3Shalloway. See 2. 4A “value stream” is the set of actions required to develop thesoftware and includes how it is conceived, developed, anddeployed.

5For more about the differences between Kanban and Scrum, see:Shalloway, Alan. “The Real Differences between Kanban andScrum.” NetObjectives, 7 June 2010 (www.netobjectives.com/blogs/real-difference-between-kanban-scrum).

6This is a gross simplification of the starting Kanban process asoutlined in Anderson, David J. Kanban: Successful EvolutionaryChange for Your Technology Business. Blue Hole Press, 2010.

7XP has long advocated this approach, called Test-DrivenDevelopment (TDD). Several of TDD’s thought leadersconsider it a manifestation of Kanban thinking.

8While I do not believe the best place to learn lean is fromToyota, I highly recommend Rother, Mike. Toyota Kata:Managing People for Improvement, Adaptiveness, and SuperiorResults. McGraw-Hill, 2009.

9Readers who are interested in this well-known but rarelydiscussed phenomenon of software development — I callit “induced work” — should watch a short video titled“How Delays Cause Waste: A Main Tenet of Lean” atwww.youtube.com/watch?v=5S97z0taHB8.

Alan Shalloway is the founder and CEO of Net Objectives. With morethan 40 years’ experience, Mr. Shalloway is an industry thoughtleader in lean, Kanban, Scrum, and design patterns. He helps compa-nies transition to lean and agile methods enterprise-wide and teachescourses in these areas. Mr. Shalloway has developed training andcoaching methods for lean-agile that have helped his clients achievelong-term, sustainable productivity gains. He is the primary authorof Design Patterns Explained: A New Perspective on Object-Oriented Design, Lean-Agile Pocket Guide for Scrum Teams,and Lean-Agile Software Development: Achieving EnterpriseAgility and is currently writing Essential Skills for the AgileDeveloper. Mr. Shalloway is a popular speaker at prestigious con-ferences worldwide and a cofounder and board member of the LeanSoftware and Systems Consortium. Mr. Shalloway has a master’sdegree in computer science from MIT and a master’s degree inmathematics from Emory University. He can be reached [email protected].



ADOPTING KANBAN AT ASR INSURANCE: THE TIMELINE

ASR Insurance is one of the top three insurance com-panies in the Netherlands. A couple of years ago, ASRadopted an agile method, Scrum, as a way of workingfor IT projects, and it proved to be very effective indelivering project results. Based on this outcome, Scrumwas implemented widely across the company in ITprojects and maintenance and operations (M&O).

While effective as a chosen methodology for projects,Scrum didn’t work well as the default way of workingin an M&O environment. Maintenance and operationsoften have to work on items with a short time frameand be able to respond quickly. Not infrequently, thisturned out to be at odds with the planning of sprints.

In August 2009, ASR launched a pilot with a team ofaround 10 people. They were tasked with continuingtheir maintenance work while switching to Kanbanas their new way of working. The first results wereso encouraging that more teams started to work withKanban. In October 2009, ASR had seven teams run-ning with Kanban. Some of the teams were mixed M&Oteams, while some others were dedicated to only main-tenance or only operations. The experiences of theseteams gave ASR the necessary confidence to take thenext step in Kanban adoption.

At the same time, three other forces were activewithin ASR:

1. Dedicated maintenance and operations teams. Toservice the rest of the company better, the IT depart-ment wanted dedicated teams for maintenance andoperations, respectively. One team would be respon-sible for doing maintenance on an application (i.e.,changes to the functionality) and another team woulddo the daily operations for that application (i.e., mak-ing sure it runs to spec every day). Each team wouldbe dedicated to a set of applications, and the teammembers would be 100% allocated to their team.

2. Matrix organization. To enable the dedicated main-tenance and operations teams, the IT departmentwanted to transition from a more traditional hierar-chical structure toward a new matrix organization.

Based on previous results, Scrum would be thedefault method for projects and Kanban the defaultmethod for M&O.

3. Lean/operational excellence program. At the boardof directors level, a lean and operational excellence(OpEx) program was started to help improve theefficiency of the whole company. The OpEx programintroduced lean working within all the regions ofthe company, including internal certification.

In January 2010, nine new teams for operations wereformed and started working with Kanban. Threemonths later, nine other teams were formed to handlethe maintenance for applications. Introducing thischange was quite intrusive and was coached by boththe lean program and the agile adoption program toprovide maximum support. The lean program focusedmostly on the continuous improvement of the newway of working, and the agile adoption program withKanban focused on work management. Both programshelped in areas like cultural change, management,leadership, behavior, and personal responsibility.

As of February 2011, 18 teams are working with Kanbanwithin maintenance and operations, with 160 peopledivided equally between the two areas. Each multidisci-plinary team contains developers, architects, businessrepresentatives, information management experts, andwhatever other skills and roles are required to do thejob. Each team is facilitated (not managed) by a teamcoordinator to keep the process running smoothly.

REASONS FOR ADOPTING KANBAN

In today’s economic climate, efficiency and effective-ness are important. At ASR, the focus on cutting costsand improving efficiency resulted in a cultural changeand a real sense of urgency, which is needed for suc-cessfully implementing change in an organization.

The most important reason for implementing Kanbanat ASR is alignment with the business sectors. Because thebudget for operations is fixed (i.e., by having a dedi-cated team working on it all year), the internal IT clientsknow beforehand the cost of keeping applications

Kanban at an Insurance Company in the Netherlandsby Dan Verweij and Olav Maassen

DIFFERENT STROKES FOR DIFFERENT FOLKS


running. This increases their desire to be more closelyinvolved in decision making to make sure the team isworking on the most important things all the time. Thefixed budget serves to cut costs, while Kanban allowsthe clients the flexibility they desire within that budget.

The second reason for adopting Kanban is the tremen-dous transparency it creates. In the past, IT was seenas a pit into which one threw money and hoped forthe best results. Because the clients are now closelyinvolved, they gain more influence and have a biggersay in what happens. Transparency combined with thisadded influence greatly increases the trust between allparties involved.

When ASR started working with maintenance andoperations teams, they first used Scrum because ofthe company’s positive experiences with it in projects.However, the short cyclic nature of maintenance andoperations and the often isolated tasks made Scrumless than ideal. Although Scrum also has a short cyclicnature, it became impossible for the M&O teams tocommit to sprints, as they were unable to forecast whatthey would be working on for the next two weeks. Anyrequest coming in could be of a higher priority thananything the teams were working on at the time, andas a result there were many failed sprints.

We have seen teams in which the individuals were allso focused on their own work packages that a stand-upmeeting didn’t provide them any information. Therewas no cooperation, and people were staring out thewindow. The visual management aspect provided bythings like the Scrum board and the impediment list,however, proved very valuable. Kanban also has a verystrong visual management component that allows teams amuch better overview, and concepts such as flow andpull make it more suited to the short cyclic nature ofM&O work. By changing their way of working fromScrum to Kanban, team members started to cooperateand help each other, just as a team should. Kanban visu-ally demonstrated their dependence on each other. Forexample, when Kanban showed that testing was thebottleneck for the team’s throughput, the developersdecided they needed to focus on helping the testers dotheir work. Further investigation (and experimentation)later on showed that many of the issues found duringtesting could be prevented if the testers and developerscooperated more closely when the team started devel-oping each feature.

In software development and software engineering,the agile way of working is the best possible imple-mentation of lean principles in IT. Lean and agileinitiatives reinforce each other. Principles such as flow,

waste reduction, and continual improvement are nat-ural parts of agile. Lean helps in connecting the agilemindset to the business.

BENEFITS OF IMPLEMENTING KANBAN

Now we know why ASR chose to implement Kanban.What other benefits have we seen?

Improved Quality and Increased Production

Based on early results, we can see that the numberof change requests solved and implemented bythe teams has doubled regardless of the size of thechange requests. The number of incidents (problemsin production) has decreased, and the number ofresolved incidents has risen with the early teams.We see comparable progress with most teams whereKanban is implemented and running well.

Improved Business-IT Alignment

The business is heavily involved with the Kanbanteams. The transparency, fine-grained control, andconsistent delivery over time have restored the trustbetween business and IT. Real partnerships have devel-oped between teams and the business departments theywork for. The team that achieved the best results inimproved quality and production was the team that waslocated in the same hallway as the business departmentthey served. This physical proximity increased theirinvolvement with each other.

The business departments now feel so involved withthe teams that it is quite natural to see business peopleat the stand-up meetings in the morning. Even whennobody from IT is present, the business representativesstart up the electronic screen to display the Kanbanboard containing all the work in progress, and they holda stand-up meeting. This shows that they now feel partof the team.

Better Information Flow

Having the business units present at the team locationscreates more understanding of each other. Businesspeople are responsible as part of the team and can now

By changing their way of working from Scrumto Kanban, team members started to cooper-ate and help each other, just as a team should.



directly see what is keeping the team from reachingintended goals and can actively help resolve issues.When things turn out to be more difficult than initiallyestimated and take more time, it is more logical to thebusiness because they receive more information directlyfrom the source.

This also works the other way around. The informationmanager can explain why a particular change request isvery important and that there are many people waitingfor the change. The turnaround is much quicker, moreflexible, and easier to manage than going through theofficial issue-tracking systems that ASR had beenusing. Personal contact has replaced communicationthrough tooling. The issue-tracking systems are stillused, but now they are just for tracking issues insteadof for communication.

Simpler Organizational Structure

The way Kanban was implemented at ASR (i.e., withdedicated teams) allowed the company to create asimpler organizational structure. Many ApplicationServices Library (ASL) roles previously institutedbecame obsolete, and the responsibilities were trans-ferred to the teams. ASR no longer has people in thespecific roles of incident manager and incident coordi-nator, for instance. The team handles all incident man-agement because everybody can see the status. (TheASL roles that still remain separate are knowledgemanager and quality manager.)

Cost Savings

Although cost cutting is not the primary goal of imple-menting Kanban, costs for maintenance and operationsat ASR have been lowered. This is a consequence of theincreased transparency. There is a constant focus ondoing the right things with the people available in theM&O teams. This increased effectiveness reduces thenumber of people needed to do work on maintenanceand operations. The close relationship between the busi-ness departments and the teams reduces much of thepreviously needed overhead.

DIFFICULTIES OF IMPLEMENTING KANBAN

Although the benefits of implementing Kanban areclear, there were challenges in getting Kanban adoptedat ASR. This section highlights the most important diffi-culties encountered during the Kanban implementation.

Personal efficiency mindset. The biggest step peoplehave to take is to change their mindset. Society isvery focused on efficiency, and people want to con-tribute all the time. This focus on personal efficiency,however, tends to lead to a suboptimization of thewhole team. Sometimes it makes more sense for ateam member not to pick up a task that he or she isan expert at and first help a colleague so the team candeliver results. What Kanban asks of teams is to focuson the end result and make their decisions basedon effectiveness. This affects such decisions as whatwork the team picks up first and what tasks the teamputs the most effort into. The teams become responsi-ble for the results, and the individuals are responsibleto their team. It takes time for people to change theirbehavior from something they have been doing formany years (i.e., focusing on personal efficiency) toa more collaborative mindset.

Ch-ch-ch-ch-changes. Complicating matters at ASRwas the fact that many changes were implementedat the same time. Besides the adoption of Kanban,people were also facing a new location, a new boss/manager, a new matrix organization with two man-agers instead of one, and a new office setup —employees no longer had their own desks becauseof a Results Only Work Environment.1 The wholemix of changes at the same time hindered the speedof the Kanban adoption.

Monkey see, monkey do. Despite the many changesin the environment, teams eventually became suc-cessful with the use of Kanban. Teams that had beenworking with Kanban before these changes wereimplemented had a head start and were up and run-ning sooner than the other teams. The success of theearly Kanban teams was soon noticed, and teams thatweren’t part of the Kanban adoption at that timewanted to get similar results. So they copied whatthey could see — namely, the Kanban board and thestand-up meetings, which are the most visible ele-ments from the outside. Because these teams missedsome of the essential ideas behind Kanban — suchas flow, pull, and continuous improvement — theywere able to improve, but not to the level of theother Kanban teams. The danger is that the term

The danger is that the term “Kanban”becomes more widely used, but withoutan understanding of the fundamentalprinciples and concepts that back it up.


“Kanban” becomes more widely used, but withoutan understanding of the fundamental principles andconcepts that back it up.

You say “potato,” I say “po-tah-to.” Being in a non-English-speaking country, the team responsible forthe agile (and Kanban) adoption decided not to trans-late the agile and Kanban terminology but to keep theEnglish terminology. The benefit is that there is moreinformation available on the Internet in English, andit becomes easier to relate the theory to the practice.In some parts of the company, however, certain stan-dard terms such as “stand-up meeting” (“Dag start”)and “retrospective” (“Keek op de week”) were trans-lated. We observed that this led to confusion aboutwhat the terms exactly meant — especially in uncer-tain times, as during an implementation of a new wayof working, people are looking for certainty in def-initions. Having different words for the same thingdidn’t help.

Lack of business involvement. One important chal-lenge was getting the business actively involved inwhat the teams were doing. It didn’t help that ini-tially the teams and the business were located at twodifferent locations 15 miles apart. This separationreinforced the divide between the business and IT.At first, the business was represented at the teams’location one day a week. It took quite some effort toget the business really involved with the IT teams.

WHY NOT KANBAN EVERYWHERE?

Just as ASR considered using Scrum for all thingsrelated to IT, the company also debated whetherKanban could be used for their development projects.And although Kanban works well for maintenanceand operations, running a development project usingKanban at ASR doesn’t seem to be a good fit. We expectScrum to be used when delivery in batches is desired.This makes more sense than using Kanban.

In one case, ASR started a large-scale maintenanceproject for one of their applications. At least the orig-inal request was for maintenance, but it turned out theassignment was so big that it needed to be organized asa project instead. The project started with Kanban as away of working under the guidance of an experiencedagile coach who had successfully coached both Scrumand Kanban teams within ASR before. Although allthe conditions were positive, the team was not ableto produce the desired results while working with

Kanban. Management then decided that the teamshould switch to Scrum, and that method workedmuch better for the project.

Although experience with agile methods is not a prereq-uisite for a successful Kanban implementation, it doesappear that it helps to get Kanban working within proj-ects more quickly. Because the team lacked such experi-ence, they needed more structure to be able to perform.Using Scrum and having two-week iterations withoutscope changes helped the team get better results. Weexpect that as their experience in agile grows and theirsearch for continuous improvement intensifies, manyScrum teams will move toward Kanban.

If a project has clear requirements, interactions are clear,and the project organization is temporary, it makessense to stay with the currently chosen way of workinginstead of introducing a new methodology such asKanban. Introducing a new concept has a cost associatedwith it, and that might be more than the benefits Kanbanwould bring to that situation. Kanban is great in environ-ments where there is a high degree of interaction with theclients or in very innovative environments where requestsand feedback are constantly pouring into the team.

RECOMMENDATIONS FOR ADOPTING KANBAN

If you are considering adopting Kanban as a way ofworking, we offer the following recommendationsbased on our experience with a large-scale Kanbanadoption:

Involve people and prepare them well. Changingthe way people work together means organizationalchange. For this to be effective, it is essential toexplain why all this change is happening. Clarify theproblems you see and what you think should be doneabout them. Before going forward and implementingKanban, allow people to make the same mental jour-ney that you did. Create a platform for analysis anddiscussion in order to let people become convincedof what they need to do. Follow that with trainingon Kanban.

Allow for a transition period. People will not be con-vinced just because you tell them to be. Many peopleworking in IT are very analytical and need some formof proof that this method will work. Take the timeto create and foster support among those who aremost affected. After the majority has been convinced,execute the transition to convince the rest. Take away



any further doubts by enabling them to experiencethe benefits of Kanban for themselves. Have themstart with Kanban in a team and see the benefits ofvisual work management and better cooperationbetween team members and other stakeholders.These benefits are felt quickly after starting, andthey help people to accept Kanban as the new wayof working.

Think long term. There is a demand to realize ROIquickly. Managers tend to focus on quick wins, andthis makes it harder to convince people operatingwithin the change. Kanban adoption takes manysmall steps, and when considered in the short term, itmay not always look efficient. The power of Kanbanlies in its focus on increasing the effectiveness of thewhole system. Each of the steps might be small, butthe total effect is big. Looking back over the last twoyears at ASR, a lot has been realized by thinkinglong term.

Ensure close proximity. Have the teams and thepeople they work with sit close together. This helpsthe organization create and maintain the necessarytransparency. It removes many of the impedimentsthat keep teams from performing and fostersunderstanding.

CONCLUSION

A couple of years ago, ASR Insurance adopted agileas a way of working for IT projects. Recently ASR hasextended that choice to maintenance and operations.Scrum has proven to be a very effective way of delivering

results in projects, but for maintenance and operationsASR prefers Kanban. After working with Kanban, thecompany has found that quality and production haveimproved, and there is better alignment between IT andbusiness. Both now have a shared focus on doing theright things. Although ASR experienced some difficultiesin adopting Kanban, the benefits easily outweigh them.

ENDNOTE1See http://en.wikipedia.org/wiki/ROWE.

Dan Verweij is currently Program Manager Operational ExcellenceICT for ASR Nederland. He is responsible for implementing lean andagile work processes in the ICT environment. It is his belief that agilemethods are the most “lean” way of developing software. Previously,Mr. Verweij was manager of a large department of developers at ASR.It was during this period that many of the developers were first intro-duced to agile methods such as XP, Scrum, and Kanban. Mr. Verweijcan be reached at [email protected].

Olav Maassen is a Principal Consultant for Xebia in the Netherlandsand was Kanban coach during a large part of the Kanban adoptiondescribed in this article. Mr. Maassen’s central theme is to help othersperform at their best. He is interested in new developments and newideas that can help IT professionals improve themselves. He knowshow to inspire people to optimize their capacities/skills in order toget the best results for both themselves and the company.

Mr. Maassen is an active participant in the agile community. He wasone of the founders of AgileHolland, a foundation for promoting theuse of agile methods in the Netherlands, and he is actively involved inorganizing international conferences. Furthermore, Mr. Maassen isoften invited as a speaker and presenter at international conferences.The recurring theme of (most of) his presentations is how trans-parency and trust can influence an organization. Mr. Maassen canbe reached at [email protected].


Many organizations have a service desk or help deskthat is set up specifically to take all of the unplanned,ad hoc service requests that come about as a normalfunction of daily operations. These are often rathersmall matters, such as minor software defects,perplexing hardware issues, printer problems, phoneissues, and so on. The list is practically endless. Butsometimes these service requests can be major issuesthat have significant external customer-facing impactas well — networks that are down, major customer-facing applications that are down, serious hardwareoutages, and the like.

One of the more interesting aspects of this work is thatit is, by its nature, unplanned. We don’t know whatkinds of issues will arise, when they will come about,how severe they will be, or what skills will be requiredto address them. Add to this that the help desk functionmust deal with hundreds or thousands of customers, allirate, who see their “high-priority” issues go into someblack-box ticketing system, often with no real feedbackon when their issue will be resolved, and you have arecipe for 360-degree frustration. For a customer, theonly way to ensure good response time, then, is tomake your ticket a “critical” one. This, of course, leadsto the help desk being bombarded with lots of so-calledcritical issues. On top of all of this, remember that mosthelp desks are cost centers that must operate with mini-mal funding, which results in a chronic shortage of staffand other resources. These myriad challenges can makemanaging help desks a maddeningly complex endeavorand a seemingly intractable problem. How can youmanage the unplannable?

TRADITIONAL APPROACHES

Many help desks operate within the context of largerorganizations, where process is king. Mature organiza-tions have a detailed process for just about everything,so there is frequently an attempt to try to force the helpdesk function to fit one of the existing internal projectdevelopment processes — often with less than encour-aging results. Let’s consider two common approaches

— waterfall and Scrum — and some of the typicalproblems that result from their use.

Waterfall

In a waterfall process, there is a set of fixed develop-ment phases, and the object is to move a fairly largebatch of requests collectively through the phases as agroup. In this model, we would take a bunch of high-priority bugs and small enhancements and performsome level of requirements analysis, followed bydesign, development, and testing. In my experience,this model rarely works well even for planned softwaredevelopment projects. In the help desk world, the con-stantly changing priorities make it even more difficultto succeed with this model. Almost as soon as you tryto lock the scope for the next release, some new high-priority issue will arise, forcing you go back to thebeginning of the cycle.

The waterfall process is predicated on stable require-ments. It basically says, “If we can lock down the scopeand not let the requirements change, then (and onlythen) we can perform detailed analysis, design, devel-opment, and testing in a single pass. Any change inmidstream forces us to go back to the beginning.” Inshort, this process is not designed to deal with ever-changing priorities and requirements. Even if you couldhold the line on requirements changes, the inherentlylong delivery cycle that comes from large batches ofrequirements all going the through the process togetheris not a good fit for the fast-turnaround expectations ofa support environment. The waterfall approach is sim-ply not agile enough for the realities of the help desk.

Scrum

Forward-thinking organizations that have alreadyadopted an agile method such as Scrum will oftenattempt to use it to manage help desk development.Scrum’s smaller batch sizes, short delivery cycles,and requirements independence1 all tend to makethe method a much better fit for the high-variabilityworld of the help desk. However, many of the Scrum

Kanban for Help Desks: Managing the Unplannableby Roland Cuellar

MAN PLANS, THE CUSTOMER LAUGHS



implementations I have seen for managing help deskwork have been problematic. Scrum has high expecta-tions that are difficult to uphold in a highly reactiveenvironment. For example, Scrum expects the team tohave a very clear set of priorities going into an iterationand to lock the scope, accepting few if any changesduring a sprint.

So while Scrum is a much better fit than waterfall formanaging help desk development, it is still at odds withthe reality of the situation. If the team is in the middleof a sprint and a showstopping defect surfaces, then theteam is going to have to abandon much of their currentwork in order to deal with the crisis. And if you areoperating in an environment where there is a new crisisjust about every day, then even a highly agile Scrumteam may not be agile enough to handle this level ofcontinuous change.

Now, some teams can deal with this by holdingback some capacity during sprint planning for anyunplanned, high-priority work that may need to beaddressed during the sprint. This can work fine if thenumber of late changes is relatively small and manage-able. But when teams are holding back 40%, 50%, ormore of their capacity in order to deal with unplannedwork, it is clearly an indication that the process is nota good fit for the situation.

Pitfalls of Both Methods

The basic problem in both waterfall and Scrum is batchsize; in each approach, the batch size is simply too bigto deal with continual change. From queuing theoryand inventory management, Little’s Law2 tells us thatbatch size is proportional to cycle time. The larger thenumber of items in the processing batch, the longer itwill take to process them all, so the longer the deliverycycle will be. Any process that is going to work in thisenvironment will need to have a very small batch sizein order to respond to continual change and achievethe fast delivery/response time that is expected in amaintenance environment. In fact, for a process to besuccessful in this environment:

The process must be open to almost continuousrequirements reprioritization.

Items must be able to progress through the processindependently of one another.

Batch size must be small.

I have experimented with Kanban in several clientorganizations as a possible solution to this problem.One organization is a huge Fortune 500 firm and hasall of the complexity that one typically sees at that scaleof operations. Another is a small independent mediafirm that is at the complete other end of the spectrumin terms of scale and complexity. Experiments withKanban in both of these help desk organizations haveyielded very positive results.

KANBAN FOR SERVICE AND HELP DESKS

The Situation

I’ll use the smaller client (let’s call it “DynamicMedia”)as an example, but the basic challenges at both clientswere fairly similar. At DynamicMedia, there are twoservice teams, the help desk team and the network oper-ations team, each of which works primarily in a supportfunction. And each of the two teams has two kinds ofwork: some planned projects and a lot of unplannedsupport calls.

The help desk takes support calls for a huge varietyof internal issues, everything from software defectsto printers that need new toner cartridges and e-mailand PC problems. The networking team supports callsrelated to the LAN, back-office hardware infrastructure,storage, phone systems, and software infrastructure.Planning and managing in these environments isextremely challenging due to the constantly changingissues, help requests, fluctuating priorities, and lots ofsimultaneous efforts. No traditional plan would surviveeven a few hours in this environment.

In addition to the constant requests for support, thesetwo teams have some traditional project work todeliver. Project examples might be e-mail systemupgrades, network upgrades, or new hardware installs.The project work needs to be estimated, budgeted,planned, and delivered as with any project. But tryingto deliver on project plans for the planned project workis highly difficult in this environment due to the inter-ruptions coming from the constant support issues.

No traditional plan would survive even a fewhours in this environment.


My colleagues and I had already helped the softwaredevelopment teams at DynamicMedia move to agile/Scrum software development processes, and the man-agement team desired a similar approach for managingthe support teams.

Approaches

In a typical software development environment, thereis often a lot of planned development work combinedwith some unplanned support work. Here the situationwas reversed: a lot of unplannable support work withsome planned project work. Scrum with its timeboxediterations didn’t seem like a good fit. Help desk calls,network outages, and the like don’t lend themselvesnaturally to well-delineated, fixed-scope Scrum itera-tions, and a two-week delivery cycle on a networkoutage is nonsensical. So while we probably couldhave made Scrum work, we decided to take a Kanbanapproach instead.

WHAT IS KANBAN?

In a traditional waterfall process, we use large batchesand huge amounts of work in progress (WIP) as theplanning paradigm. We do all of the requirements elab-oration, then all of the design, then all of the coding,then all of the testing. These huge batches typicallytake months to deliver in even the best organizations.

Scrum uses much smaller-sized WIP buckets. In Scrum,we break the transfer batch size down to two-weekchunks. We do a little bit of requirements analysis, a little bit of design, a little bit of development, and a little bit of testing in order to deliver a handful offeatures every few weeks. By reducing WIP down tothese small, two-week-sized buckets, we can greatlyaccelerate the delivery of high-priority features. Thishas been a fantastic revelation for traditional softwaredevelopment and has resulted in enormous improve-ments in delivery time, quality, and customer satisfac-tion. But as I explained previously, it may not yet beagile enough for help desk operations. Enter Kanban.

Kanban is a further step toward even smaller batchsizes and a move toward a more continuous flowmodel. Kanban eliminates the whole idea of iterationsor sprints. In Kanban, like Scrum, we work on thehighest-priority items, but when an item is done, we candeliver it immediately, sometimes within a day or evenhours — very small buckets indeed (see Figure 1)! Thisseems like a perfect fit for help desk and support work.Requests come in, we actively prioritize them, we focus

on the highest-priority items, and we deliver fixes oftenwithin hours. Through continuous reprioritization andcontinuous delivery, we can create a highly responsiveorganization without the headaches and overhead oftrying to fit the work into Scrum’s tidy little timeboxes.

In Scrum, we achieve fast delivery through two-weekdeadlines of fixed scope. How do we ensure fast deliv-ery in Kanban? We use WIP limits instead. By reducingWIP, we reduce cycle time (remember Little’s Law).Admittedly, Scrum reduces WIP somewhat indirectlyby using very short timeboxes; after all, you can fit onlyso much work within a two-week iteration. In Kanban,though, we eliminate the timebox entirely and insteaduse a simple, explicit WIP limit. We might say, forexample, “The team will work on no more than fiveitems at once, and we won’t start another until wecomplete one of the five.”

Remember that the more WIP we have, the longer ittakes to deliver any particular piece of work. If we wantvery fast delivery, we could have a WIP limit of one andask that the whole team focus on only one help deskticket at a time. The result would probably be very fastdelivery for this one item, but a lot of help desk ticketswould go untouched, and overall throughput wouldprobably suffer. If we wanted to address more helpdesk tickets simultaneously, we could have a WIP limitof 20. This would mean that the team could focus onthe highest-priority 20 items at a time. In this scenario,20 items would get some attention, but overall deliverytime would suffer, since team members are juggling somany simultaneous tasks. The trick in Kanban is to dis-cover a WIP limit — sometimes through trial and error— that strikes a balance between these two extremes. Ifthe WIP limits are too high, then we have too much taskswitching, too much going on at once, large batch sizes,and slower delivery. If the WIP limits are too small, thenwe have very fast delivery but only for a very limitednumber of service items, and we probably have a lotof idle staff.

Figure 1 — Kanban transfers work in even smaller batches than Scrum.



What about planning, communications, processimprovement, and so forth? Unlike Scrum’s prescriptionof daily stand-ups, retrospectives, point estimates, andthe like, Kanban leaves a lot of these supporting struc-tures fairly open, so it is even less prescriptive thanScrum from a process standpoint. If you want someadditional structure and communications, you couldborrow from both Scrum and Kanban as we did, or useadditional tools, such as cumulative flow diagrams,kaizen workout sessions, and control charts.

OUR KANBAN IMPLEMENTATION

In the end, we decided upon a mixture of both Scrumand Kanban. We wanted the iterationless, continuousflow of Kanban, but we needed some additional sup-port mechanisms to facilitate communications andcontinuous improvement. Our resulting process used:

Kanban with a WIP limit of 14 (see below)

Daily stand-ups

Retrospectives

Point estimates and burndown charts for theplanned project work

Since DynamicMedia was already using Scrum fortraditional software development, the idea of continuing

to use daily stand-ups, retrospectives, and points wasnatural for the organization, and these practices wereeasily adopted by the Kanban help desk team. Our teamhad seven people on it, so we decided to try an initialWIP limit of 14. That way, each person would at mostbe working on two items at a time. This turned out towork pretty well; if one item was blocked for somereason, there was another item that each person couldwork on. The job of team leadership was to take allof the support requests each day and prioritize themclearly for the team.

Team members would meet each morning for a dailystand-up, review the priorities, and determine whowas going to work on what. Periodically, we hadretrospectives to see how the team was doing andwhere we could make improvements.

Realizations

To get started, we first set up a simple tracking boardthat had columns for Backlog, WIP, and Done (seeFigure 2). We then asked the team to put all of the cur-rent work up on the wall so that we could visualize it.What we noticed, of course, was that there was a hugeamount of work in WIP and only a few items in Done.Our goal was to turn that around. We instituted theWIP limit of 14, and within a few days we had ourWIP down to our target level and many more items inDone. By limiting our WIP and focusing on the highest-priority items, we were able to get much more workto an actual completed state. And since these were thehighest-priority support items, we knew that we weredelivering the work items that would have the mostimpact on the organization as a whole.

Working this way, we noticed that our team leadersneeded to be much more proactive and involved inreviewing the work and assigning clear priorities. Thisbecame one of their primary functions. Daily stand-upshave resulted in better visibility and cross-team com-munication, which the team has found valuable.

For actual planned projects, such as e-mail upgradesor hardware installs, we used typical Scrum point esti-mates and release burndown charts. Tasks related tothese projects were intermingled with the support tasksso that if there were no high-priority support tasks, theteam could focus on project work. After a few weeks,though, our visual system made it apparent that theproject work was getting short-changed. While wehad a lot of unplanned work in the Done column, andwe were delivering outstanding support to our usercommunity, our project burndowns showed that wewere behind schedule for our planned projects. Clearly,

By limiting our WIP and focusing on the highest-priority items, we were able to get much more work to an actual completed state.

Figure 2 — We enforced the WIP limit through our planningboard, which has several work states, such as analysis, develop-

ment, and testing. The total WIP limit across all work states is 14.


user support work was taking priority over more strate-gic projects. While we knew that this was probably thecase, the board combined with the burndowns high-lighted the problem clearly and showed quantitativelyhow far we were behind on project work.

Kanban is a very simple process to understand —deceptively simple, in fact. But as is often the case,actual implementation was not a trivial undertaking.Initially, there was some confusion regarding whatcounted toward WIP and what did not, if and how weshould deal with pair programming, how to handleitems that were blocked, and so on. Kanban is more aconcept or way of thinking than a “process.” When wethink of processes, we often think of highly detailedprocess steps, decision points, defined inputs, outputs,and the like. Kanban has none of these. It defines ahigh-level goal of moving toward single-piece flow andsuggests some tools for achieving continuous flow, suchas WIP limits. Beyond that, there is not a lot of imple-mentation detail. Each team will need to evolve solu-tions for the kinds of issues mentioned above. Mostimportantly, each team will need to be patient as theseissues are uncovered and addressed.

Next Steps

With the basic Kanban solution in place, and the real-ization that the strategic planned project work was notsufficiently addressed, the next step was to hold a teamretrospective and then a short kaizen session to identifypotential solutions and process improvements. Theteam came up with several ideas to help alleviate someof the problems. For example, one idea was to instituteswim lanes for the two kinds of work — planned projectwork and unplanned support work. We could keep theWIP limit of 14, since that is working well, but divide itup into two parts: 10 for unplanned support work and4 for the planned project work. This means that wewould always have several planned project tasks beingexecuted at any particular time, allowing us to start tomake headway on the planned project work. By exper-imenting with these two WIP limits, we could find abalance between delivering outstanding service anddelivering on the longer-term strategic projects.

Another idea was to develop a set of delivery metrics.Let’s say that a help desk team has four types of workthat they commonly deliver: large new features, smallnew features, large maintenance activities, and, finally,small maintenance activities. As new requests arriveon an almost daily basis, which is common in manyorganizations, the team would do a quick assessmentand sizing of each. With some simple metrics, we could

soon track the cycle times of the four kinds of work,so that the team would know that, on average:

It takes 15 days (± 3 days) to deliver a large newfeature.

It takes 5 days (± 2 days) to deliver a small newfeature.

It takes 10 days (± 2 days) to deliver a largermaintenance request.

It takes 3 days (±1 day) to deliver a smallmaintenance request.

Through these simple metrics and a continuous plan-ning system, the team could make pretty accurate com-mitments and never have to stop the production linefor iteration planning. With continuous flow, we donot have to figure out exactly how much work will fitwithin an iteration because there are no iterations —just a continuous flow of delivery to customers. But weneed to be mindful that these delivery metrics would bevalid under our current WIP limit only! If we change ourWIP limit, then that will change our batch size, whichin turn will affect the cycle time, and thus we will needto recalibrate our delivery times.

KANBAN CHALLENGES

Explaining the system to customers, particularly theidea of WIP limits, can be a challenge. Telling customersthat you cannot work on their item right now dueto your self-imposed WIP limit is not always an easyconversation to have. Of course, you can also tell themthat once you do start on their problem, the WIP limitswill protect them; you will be able to focus on theirproblem and get it done quickly! In my experience,customers like having some sort of well-workingand simple system in place rather than the somewhatad hoc approaches that seem to arise in the absence ofa working solution.

Constant and clear reprioritization is a second majorchallenge. This is the real work in a Kanban system.Kanban forces management to make the tough callsabout what truly is the highest-value work and what

Telling customers that you cannot work ontheir item right now due to your self-imposedWIP limit is not always an easy conversationto have.



can wait. In large batch systems, these decisions do notactually need to be made. We can call everything “highpriority” and work on it all at once in a long deliverycycle. Big batch systems allow us to say “yes” to every-one, but of course they all end up paying in longer-than-necessary delivery times. In Kanban, we need tobe very clear about priorities, and this forces some verydifficult discussions on an almost daily basis. However,the positive results of these hard decisions are clear —the truly highest-priority changes can be delivered tothe firm with amazing speed and efficiency.

ONGOING EVOLUTION

DynamicMedia’s Kanban system is in a continuous stateof evolution. Through retrospectives borrowed fromScrum, the team sees issues that need to be addressed,such as:

Changes to the prioritization scheme

Additional states that need to be tracked

Redefinition of what is in WIP versus what is insome sort of holding state (waiting, blocked, readyfor deployment, etc.)

Changes in WIP limits

Further division of work into additional classifications/swim lanes

Process improvement is never finished, and Kanban isno exception to this rule. Any team that embarks uponthis process transformation should plan on revisitingthe process often, especially during the initial months.

BENEFITS

Team members and management at DynamicMediawere very satisfied with the Kanban approach andcontinue to use the system. The help desk team reportsthat the system provides an improved way of managingsupport work, better visibility, and better clarity onpriorities and WIP. Kanban is a simple but powerfulsystem for visualizing and managing work and is espe-cially adept at managing unplanned work, a problemthat has evaded solution for quite some time! WIPlimits force prioritization and accelerate delivery withminimal process overhead and a high degree of respon-siveness. The team has also reported that the Kanbansystem just “feels right.” It is a very natural way for asupport team to work that offers sufficient structureand visibility for managing the ever-changing prioritiesthat are the essence of the help desk.

ENDNOTES1Requirements are treated more independently in agile methods,with each going through the lifecycle somewhat independentlyof the others.

2See http://en.wikipedia.org/wiki/Little%27s_law.

Roland Cuellar is a leader in helping enterprise-level clients adopt theuse of both agile and lean methods in their organizations. Mr. Cuellarhas led numerous agile product development teams in a variety ofareas, such as marketing applications, mortgages, financial compli-ance, media, and others. He has prior experience leading softwaredevelopment projects for Freddie Mac, IBM, Lockheed Martin, DHL,CC Pace, and LitheSpeed LLC. Mr. Cuellar is Director of ProgramManagement for Three Pillar Global in Fairfax, Virginia, USA.He can be reached at [email protected].


Over the last few years, agile processes have gone frombeing used primarily by single-location colocated teamsto being adopted by multilocation distributed teams.These processes have enabled businesses to respondfaster to rapidly changing market conditions. At thesame time, the market for IT and business processoffshoring — which had already been sizable — hasgrown exponentially. While combining agile withoffshoring can allow companies both flexibility and aglobal reach in terms of services work, it can also pre-sent many challenges. In this article, we explore howKanban can be used as an alternative to first-generationagile methods in offshore environments. We also dis-cuss Kanban anti-patterns that we have seen in suchenvironments.

CONFRONTING THE CHALLENGES OF OUTSOURCING

Management consulting firm A.T. Kearney studiedmore than 40 companies that had tried offshoring andconcluded that there were significant benefits to beachieved from it, though the overall success rates var-ied. The parameters studied were capacity, organiza-tional flexibility, revenue performance, service levels,process maturity, and organizational capability.1 Whilecompanies have had mixed results,2 it is clear thatoutsourcing is here to stay.

Some of the reasons cited for difficulties in outsourc-ing are:

Lack of visibility and transparency into the statusof the project, which leads to a mood of mistrustbetween the customer and the vendor

Differences in business culture between onsite andoffshore locations

Time zone differences between locations

Inflexibility in adapting to changing requirements

Agile processes provide solutions to some of these prob-lems. They advocate collaboration over contract nego-tiation to encourage increased trust. They recommendfrequent incremental delivery of working software,

which provides some visibility and keeps everyone upto date on where the project actually stands. This in turnenables stakeholders to make changes to requirementsmidway through the project.

However, offshoring combined with agile comes witha few challenges of its own:

The close-knit, cross-functional teams requiredby agile methods are difficult to implement in adistributed environment.

Timeboxed development is not suitable for manytypes of offshore engagements, such as maintenanceand support or projects where only some activities(e.g., testing) have been outsourced.

Large-scale organizational changes are requiredfor agile implementations to succeed. When thesechanges don’t happen, it leads to a dysfunctionalorganization.

Agile adoption can magnify existing issues with timezone gaps and business culture differences.

The question is, how can executives merge the feed-back and responsiveness of agile with the benefits ofoutsourcing? We suggest that Kanban can be used asa method for incremental improvement that can workwith, arguably, any underlying process. It can be effec-tively applied in a variety of contexts, including newdevelopment, maintenance and support, and environ-ments in which there are handoffs or blocking depen-dencies between teams. Perhaps more important,Kanban can be applied without the need for trans-formational change, which makes it possible to useKanban principles on any existing project.

APPLYING KANBAN TO OUTSOURCED PROJECTS

Kanban for software development was originally con-ceived as a solution to the difficulties in managing dis-tributed offshore teams.3, 4 In this section, we will lookat strategies for improving outsourced projects throughthe application of Kanban steps.

Use of Kanban in Distributed Offshore Environmentsby Siddharta Govindaraj and Sreekanth Tadipatri

SEEING IS RELIEVING



Visualize the Workflow

Just putting all the steps in the workflow onto aKanban board and visualizing the state of each workitem can lead to many positive changes. Transparencyis increased, which leads to greater trust between onsiteand offshore teams. Furthermore, this simple visualiza-tion can help you identify bottlenecks in the workflow.You might be surprised where bottlenecks turn up.

Experience Report 1

In one project that Siddharta worked on, the bottleneckwas actually outside the development team. Manystories were awaiting user acceptance testing fromthe customer.

We were initially unaware of this bottleneck, but oncewe started tracking the number of work items in eachstate across the whole value stream, the problembecame visible. We were then able to work with thecustomer to speed up the acceptance process.

Experience Report 2

Before visualizing work items on the Kanban board,team members were unaware of what others wereworking on. They would often start a new work iteminstead of completing one already in progress. Thismeant that a lot of new work items would get started.

After the offshore site set up a Kanban board for localteam members, they would scan the board to seewhether they could help complete an existing work itembefore pulling a new one. Visualizing the workflowenabled team members to self-organize in this way.

Later, the project sponsor instituted an electronicKanban board for the entire project so that teams acrosslocations could use this single board to reflect all theirwork. This enabled tacit communication between teammembers in all locations as well as with the businessand sponsor — everyone on the project had visibilityinto any work item (i.e., the item’s state of completionand the team that was working on it). Thus, communi-cation challenges and time spent coordinating workwere minimized.

Look at Queue Time

In any software development project, regardless of themethodology, items often spend a lot of time in queueswaiting to be worked on. This queue time can be a sub-stantial part of the overall lead time. (Lead time is theamount of time that elapses from the moment a taskenters the work system to the moment it is deliveredto the customer.) It is common for a work item tospend more time waiting in queues than actuallybeing worked on.

Points of handoff tend to be prime candidates for longqueues. A quick way to reduce the lead time is to seewhether there are queues that can be reduced or elimi-nated. If you can’t eliminate the handoff, then settinglimits on queue length can also help, even if it meansstopping upstream activity until capacity is availabledownstream.

Experience Report 3

In one project, every piece of code in certain key com-ponents had to be reviewed by someone else. Often,a feature would be implemented in a few days and thenwait for almost a week until someone else got aroundto reviewing it. As a result, the total time to implementa feature was almost two weeks, of which only two orthree days were spent in actual implementation. Therest of the time was spent waiting for review.

We implemented pair programming for code changesthat involved these components. This eliminated theneed for code review, and we were able to deliverfeatures almost a week earlier.

Experience Report 4

One highly successful distributed agile implementationthat Sreekanth experienced involved eight teams ofeight members each. The teams in the offshore locationwere working in silos even though they were on thesame project.

Just bringing two teams at the offshore location intoone room and putting up the work items in slots toreflect their current state of readiness helped the teamtremendously. It soon became clear that when thedevelopers finished coding the stories, the testers couldnot keep pace with testing — neither exploratory testingnor automation of functional and acceptance testing.Thus, a lot of items got queued up in the testing phase.When the developers and business analysts saw thattesting was a bottleneck, they pitched in by doing man-ual exploratory testing and automating functional andacceptance test cases. Team maturity improved in terms

A quick way to reduce the lead time is tosee if there are queues that can be reducedor eliminated.


of self-organization and collaboration, resulting in eachwork item completed at the earliest possible time.

Make Policies Explicit

Most organizations have implicit policies about howdifferent types of work are to be handled. Kanban teamsmake these policies explicit so that they are appliedconsistently.

Experience Report 5

In one maintenance project, due dates for tickets weredefined according to service-level agreement (SLA)terms. Originally, when deciding who should workon which ticket, management would assign similarwork items to particular individuals. This resulted inan uneven distribution of work, where certain teammembers would have to multitask on many ticketswhile others were relatively free.

After adopting Kanban, the team decided on a policythat whenever someone became free, he or she shouldpick the ticket that is closest to the SLA due date. Withthis policy in place, team members no longer neededsomeone to assign tickets to them. When they finisheda task, they simply picked the next ticket in the queue.This explicit policy allowed the team to self-organizeand manage the flow of tickets themselves.

Limit Work in Progress

In order to achieve optimal lead time, we must limitthe amount of work in progress (WIP).5 Limiting WIPreduces the amount of multitasking, resulting in shorterlead times.

Experience Report 6

After setting up the Kanban board in one organization,it became clear to the director of operations that teammembers were constantly overcommitted, often multi-tasking between many work items. This had the effectof increasing lead times on the work items, causingmissed due dates.

In response, the team, in consultation with the directorof operations, established WIP limits. Setting up WIPlimits eased the pressure on the team, since the stake-holders could not overload them when limits were full.WIP limits also encouraged team members to completestories in progress instead of picking up new stories,resulting in decreased lead times.

OFFSHORE KANBAN: PITFALLS TO AVOID

So far, we have talked about successful applicationsof Kanban. That’s not to say that there are no pitfalls.Here are some things to look out for:

Not adopting a WIP limit. Limiting the workin progress is a fundamental feature of Kanban.However, this is where the maximum resistanceis seen. Managers often have the perception thatlimiting WIP leads to reduced capacity utilization.Executives may also be tempted to compare WIPlimits across locations.

Maintaining static WIP limits. WIP limits are notsupposed to be fixed in stone. They can and shouldchange, taking into account factors like changes inteam composition.

Not managing the flow of work. If the flow of workis not managed, teams could revert back to the earlierbehavior of taking on new work instead of finishingwork in progress.

Not removing impediments. Simply visualizingthe work on a Kanban board does not yield reducedlead times. Teams must be ready to regularly takeaction and make improvements based on findingsfrom the board.

Not updating the Kanban board regularly. If theKanban board is not updated, it may not reflect thecurrent state of work items.

Having no available Kanban expertise. Kanban isrelatively new. It can be difficult to find people andteams that are proficient with it. At the same time,Kanban is less prescriptive than other agile processessuch as Scrum. This can make it more difficult to getbuy-in from management.

Not mapping the value stream completely.Sometimes the value stream is not mapped fromconcept to delivery. This leaves the risk that depen-dencies outside of the team will not be taken intoaccount.

Having overly specialized teams. Teams may findthemselves getting the same type of work based ontheir specialization. For example, one team developsthe system while another team does the testing. Thelead time to get the required functionality to the cus-tomer is increased, since there are multiple handoffsand queue times. While this might be the startingposition, less specialized teams can lead to reducedlead times.



Not having sufficient stakeholder involvement.This is perhaps one of the most critical factors indetermining the success or failure of Kanban adop-tion. Oftentimes when a team adopts Kanban, thestakeholders have no interest in knowing how itworks or benefits the organization. In this situation,change never occurs.

Creating silos of knowledge. Project managers inmatrixed organizations often route work to teamsthat deliver the projects they manage. The knowledgeof the system gets siloed among teams. No longercan any team work on any story. Instead, it is possi-ble that one team may be overloaded while another isidle. Also, team members could lose motivation whenrepeatedly working on similar stories.

CULTURAL CHALLENGES TO KANBAN

As with any new initiative, culture plays an importantpart in how successful a Kanban implementation willbe. Here we consider some cultural factors that pose achallenge to Kanban adoption.

Micromanagement

In some cultures, there is a reluctance to deliver the badnews early, but this information is important to all thestakeholders to mitigate business risks. Kanban makesthe status of work visible. Problem areas and bottle-necks are clearly apparent, and some team membersmay fear that they are being micromanaged throughthe transparency.

Inflexible Belief in Best Practices

At some workplaces, there is an inherent need to define“best practices” and a lack of willingness to identifyproblem areas and make needed improvements on acontinuous basis. Therefore, when a team either opts touse Kanban or is required to, it is likely that the initialworkflow mapped on the board will be taken as is andthat no changes to the workflow will be made basedon experience and the knowledge gained by the teammembers.

One of the principles of the Kanban method is to con-tinuously improve, and to do this, teams need to believethat there are always better ways of doing things.

Lack of Team Empowerment

Team members in some organizations are not empow-ered to alter the Kanban board or WIP limits, and theylook to their manager to suggest any improvement. Inone case, the team pitched in with the estimates butthen asked their manager, “Which task do you wantus to start working on?”

In matrixed organizations, project management oftencontrols the work done by the team and assigns workto team members. Consequently, team members are notmotivated to learn better ways of working, and Kanbanbecomes meaningless.

Fear of Perceived Incompetence

In the software industry, especially in the servicessector, there may be a tendency to “protect” the juniordevelopers from being “exposed” to the customer. Onejunior developer admitted that he was afraid of beingperceived as incompetent, since he took much longerto complete a task than a senior member of the team.Kanban makes these differences visible and thus maycause an individual to feel insecure.

The Politics of Change

As with any change effort, adopting Kanban can be apolitical minefield in an organization. Any change beingbrought about will be embraced with enthusiasm bysome and fought bitterly by others, depending on thepersonal equation of the people involved — both at theleadership level and at the middle management andteam levels. Success or failure depends a lot on who inthe organization supports the effort. Each geographicallocation in a company may try to establish an identityfor itself, and adoption of Kanban at each location maydepend on how it fits with the location’s identity.

CONCLUSIONS

When done properly, Kanban creates an environmentwith the following characteristics:6

There is visibility into the development process.

Team members are actively involved in controllingtheir tasks and participating in collaborative problemsolving.

One of the principles of the Kanban methodis to continuously improve, and to do this,teams need to believe that there are alwaysbetter ways of doing things.


There is a culture of continuous improvement.

There is increased trust between customers andvendors.

Through a few simple steps, Kanban provides teamswith a mechanism to continually improve their process,cut lead times, and improve responsiveness to rapidchanges in the market. The key ingredients for the suc-cess of offshore Kanban are stakeholder involvement; anempowered, cross-functional team; and involvement ofthe whole value chain.

ACKNOWLEDGMENTS

The authors would like to thank Hedwig Baars, HiteshRamnani, and Govindarajan Sundararajan for sharingtheir experiences with offshore Kanban for this article.

ENDNOTES1“What to Move Offshore: Selecting IT Activities for OffshoreLocations.” A.T. Kearney, 2004 (www.atkearney.com/images/global/pdf/What_to_Move_offshore_s.pdf).

2Love, Jim, and Darrel Berry. “Backsourcing vs. the HotelCalifornia Syndrome.” Cutter Consortium Sourcing & VendorRelationships E-Mail Advisor, 26 January 2011.

3Anderson, David J. Kanban: Successful Evolutionary Change forYour Technology Business. Blue Hole Press, 2010.

4Anderson, David J., and Dragos Dumitriu. “From Worst to Bestin 9 Months: Implementing a Drum-Buffer-Rope Solution inMicrosoft’s IT Department.” Paper presented to the TOC ICOWorld Conference, Barcelona, Spain, November 2005.

5Maeda, Masa K. “WIP: From Limiting Software Developmentto Balancing the Project.” Cutter Consortium Agile Product &Project Management Executive Update, Vol. 11, No. 4, 2010.

6Stevens, Dennis. “Kanban, Mental Models, and DoubleLoop Learning.” Dennis Stevens: Enabling the Agile Enterprise,14 July 2010 (www.dennisstevens.com/2010/07/14/Kanban-mental-models-and-double-loop-learning).

Siddharta Govindaraj is the founder of Silver Stripe Software Pvt.Ltd., a company that develops products for teams that follow agileand Kanban. Based in Chennai, India, Mr. Govindaraj has six yearsof experience with agile, of which the last three years have been inapplying Kanban. He was a speaker at the Lean Software & SystemsConference 2010 in Atlanta. Mr. Govindaraj can be reached [email protected].

Sreekanth Tadipatri has been a practitioner of software development,software quality assurance, and project management for more than 12years. Based in Bangalore, India, Mr. Tadipatri has helped more than50 projects and 100 distributed teams transform themselves by adopt-ing agile. During his coaching engagements, he has experimented withintroducing Kanban to agile teams. Mr. Tadipatri can be reached [email protected].


Cutter IT Journal

About Cutter ConsortiumCutter Consortium is a truly unique IT advisory firm, comprising a group of more than100 internationally recognized experts who have come together to offer content,consulting, and training to our clients. These experts are committed to delivering top-level, critical, and objective advice. They have done, and are doing, groundbreakingwork in organizations worldwide, helping companies deal with issues in the core areasof software development and agile project management, enterprise architecture, businesstechnology trends and strategies, enterprise risk management, metrics, and sourcing.

Cutter offers a different value proposition than other IT research firms: We give youAccess to the Experts. You get practitioners’ points of view, derived from hands-onexperience with the same critical issues you are facing, not the perspective of a desk-bound analyst who can only make predictions and observations on what’s happening inthe marketplace. With Cutter Consortium, you get the best practices and lessons learnedfrom the world’s leading experts, experts who are implementing these techniques atcompanies like yours right now.

Cutter’s clients are able to tap into its expertise in a variety of formats, including contentvia online advisory services and journals, mentoring, workshops, training, and consulting.And by customizing our information products and training/consulting services, you getthe solutions you need, while staying within your budget.

Cutter Consortium’s philosophy is that there is no single right solution for all enterprises,or all departments within one enterprise, or even all projects within a department. Cutterbelieves that the complexity of the business technology issues confronting corporationstoday demands multiple detailed perspectives from which a company can view itsopportunities and risks in order to make the right strategic and tactical decisions. Thesimplistic pronouncements other analyst firms make do not take into account the uniquesituation of each organization. This is another reason to present the several sides to eachissue: to enable clients to determine the course of action that best fits their uniquesituation.

For more information, contact Cutter Consortium at +1 781 648 8700 [email protected].

The Cutter BusinessTechnology CouncilThe Cutter Business Technology Councilwas established by Cutter Consortium tohelp spot emerging trends in IT, digitaltechnology, and the marketplace. Itsmembers are IT specialists whose ideashave become important building blocks oftoday’s wide-band, digitally connected,global economy. This brain trust includes:

• Rob Austin• Ron Blitstein• Christine Davis• Tom DeMarco• Lynne Ellyn• Israel Gat• Tim Lister• Lou Mazzucchelli• Ken Orr• Robert D. Scott

cutter on kanban from leankit kanban

Documents

blue hole

bad process

opening statementby

cutter edge

netherlandsby

limited wip

short cyclic

generation