kanban in a nutshell - software engineering · 2 1 kanban in a nutshell potential problems –...

1

Chapter 1

Kanban in a nutshell

Student: Tiberiu Marian BudauCoordinator: Pascal BihlerContact: [email protected]

Agile methods and lean approaches have been receivingever increasing attention within the scientific communityand blogosphere alike. In the past three years Kanban, anagile toolkit, has been gaining momentum as a fresh andinteresting approach to managing software developmentand many small- to mid-ranged companies are interestedin experimenting with it. In this chapter we wish to presentthe origin and underlying concepts of Kanban, the Kanbanboard and metrics, a comparison to its most popular rival –Scrum –, and a successful way of mixing the two.

1.1 Origins and PrinciplesKanban is avisualization of theworkflow modeled bycards travelingthrought all phasesof the developmentprocess.

Kanban was initially developed in the 1950s at Toyota, byTaiichi Ohno, as a method for supporting JIT (just-in-time)production and reducing inefficiencies throught thewhole supply chain [11]. Despite the fact that thename means ”billboard” – which is the essential toolused in kanban – the two characters actually standfor ”to visualize/examine” and ”card”. Thus show-ing, that the role of kanban is indeed to offer a clearvisualization of the workflow with the aim of examining

2 1 Kanban in a nutshell

potential problems – i.e., bottlenecks. The cards are eithersignals of orders for production/supply or in the case of D.Anderson’s Kanban [6], virtual signals to pull features/usecases that need to be implemented.

1.1.1 Kanban in supply chain management

Figure 1.1: An example of a kanban card[11]

From the productionmanager’s point ofview kanban is apull-basedmethodology thatreducesnon-value-addedwaste.

As mentioned in [15] the actual role of kanban – as a JITproduction tool – was to ensure the transparency of theinventory levels. Meaning that when a product was con-sumed a kanban card would be returned to the producer,within the current producer/consumer node of the sup-ply chain. Once a certain threshold of cards has beenreached, the producer would start the production processand, if needed, pull any required resource from upstream[11]. This method was particularly efficient as it reducednon-value-added waste. In other words, there where nocosts incurred by the producer without obtaining immedi-ate profit [11]. A possible kanban card can be viewed inFigure 1.1. Nowadays, kanban is implemented as a fully-automated software tool in the form of E-Kanban and hasbeen ever increasing in popularity, according to some sur-veys [12].

1.1 Origins and Principles 3

1.1.2 Principles of Kanban

Kanban, which was adapted by D. Anderson [6] from theToyota Production System kanban, in our opinion, is basedupon a set of Agile and Lean Principles that focus on:

• Human capital, developers and clients are valuableassets;

• Reducing communication overhead and increasinghuman interaction;

• Eliminating unnecessary formalities, chains of com-mand, and increasing reaction to change;

• Seeing the ”whole” and exposing problems as soon aspossible;

• Rapidly developing a working software solution;

Just by scanning the aforementioned principles we can no-tice that most of the Agile Manifesto [5] and the propertiesof Lean Software [13] are contained therein. We also ob-serve that the Agile Manifesto is followed to the letter.

The core pillars of Kanban according to some authors are[14, 6]:

Visualization. Visualizing the entire workflow in order toobserve the development process as a whole. Identi-fying bottlenecks, idle areas, and in general increas-ing the overall productivity are the main objectives.The tools used are the Kanban board and tickets.

Pull. Tickets are being pulled, not pushed, throughout thedifferent phases of the development process. Pullingcreates slack – by definition, lack of tension in a wire– which can be exploited, i.e., idle teams can help outcolleagues that are struggling in other phases of de-velopment. Furthermore, the existence of slack offersthe possiblity of improvement and learning.

Limit your WIP. WIP stands for Work In Progress and is athreshold used to limit the number of tickets that exist


at any given moment in every phase. These thresh-olds need not be the same for every phase.

Measure and Control. Measuring and controlling the flow,often through the use of elements from QueueingTheory and from the Theory of Constraints, in orderto achieve maximum efficiency.

Improve Continously and Collaboratively. This princi-ple refers to learning from mistakes and continuouslyimproving the process. Well-known methodologiessuch as Plan-Do-Check-Act (PDCA), Kaizen, or theDeming cycle can be used.

Visualizing, Pulling,Measuring andControlling,Continouslyimproving, andLimiting your WIP isthe Kanban way todo it.

Figure 1.2 shows a few problems that Kanban highlightsand effectively tackles.

Figure 1.2: Typical problems of a development process[6]

1.2 Kanban Tools, Structure, and Metrics

In this section we will describe how one could implementa Kanban process, what the tool structure is, how to usethem, as well as ways of monitoring and controlling theworkflow.

1.2 Kanban Tools, Structure, and Metrics 5

1.2.1 Tools and Structure

As previously mentioned the two essential tools for Kan-ban are the Kanban board and tickets. Kanban is usuallyphyisically implemented, e.g., with a normal white boardand sticky notes. An alternative would be using softwaretools that emulate the Kanban process, such as LeanKit Kan-ban [1] or Agile Zen [2]. We will focus on physical imple-mentation, however, the electronic versions do offer bet-ter overall management, access to more information, andare suitable for geographically distributed teams [6]. It isarguable whether the physical board offers more informa-tion, however, it does offer flexibility and the potential toexpose problems faster, e.g., if several teams are arguingover a ticket and others observe this, then the user storyneeds to be considered and reanalyzed.

Kanban board. The Kanban board, as the name sug-gests, can be a normal white board. It is dividedinto columns, each column representing one differ-ent phase of the development process. Black tape isusually used to facilitate on-the-fly restructuring, ifneeded. The transit of tickets throughout the columnsoffers a visual representation of the workflow. Af-ter establishing the workflow, each column may haveassociated input queues, buffers, and is annotatedwith a WIP limiter – the maximum number of tick-ets that can exist in that column at any given time.Tickets transit by convention from left to right andare pulled in any arbitrary order, depending on theteam’s needs. Under some special circumstances itis envisionable that a ticket would be removed fromthe board, e.g., if the client decides the feature is nolonger needed.

Kanban tickets. The initial work is, usually, dividedinto many small, preferably independent, user sto-ries. However, more coarse grained tickets can beutilized (e.g., breakdown into features). Ideally, alltickets should be equally course. Each user story iswritten on one ticket and initially placed in the firstcolumn, usually, referred to as the Backlog. A tickettransits all columns until reaching the last column,


usually, referred to as Done/Live. Each ticket has an as-sociated team that takes care of that user story withinthat particular development phase. In the likely caseof a bottleneck idle teams may help their strugglingcolleagues across different phases.

The Kanban board should always be adapted with respectto the project, people/teams, technologies used, and so on.What follows is a possible visualization as in [6], however,we strongly recommend to adapt the entire Kanban processbased on the individual needs of each project. Figure 1.3 il-lustrates the Kanban board that was used in last year’s lab-oratory. It is important to observe that almost all phases,except the Development phase, are controlled by the cus-tomer. Thus, showing that the client plays an active role inthe development of the product.

Figure 1.3: Last year’s Agile Lab board

1.2.2 Metrics

In order to better visualize how a certain Kanban processbehaves we construct a Cumulative Flow Diagram (CFD).As the name suggests it is a graphical representation of thetransit of all tickets on the board (the Y-axis) during a giventime period (the X-axis). We need metrics in order to ensurethe measurement and control of the flow. For example, met-rics to monitor the flow and see if certain policies have the

1.2 Kanban Tools, Structure, and Metrics 7

Figure 1.4: A Cumulative Flow Diagram and its associatedmetrics [7]

desired effect – usually successfully omitting bottlenecks.A relatively large number of metrics can be defined and de-duced directly from the CFD. In Figure 1.4 we observe thefollowing metrics:

WIP. Work In Progress is the entire amount of work be-ing done and can be defined for any moment in time.In other words, it is the number of tickets presentin all columns (except the backlog/first column andlive/last column) at a given moment in time.

Lead Time. Lead time is the time viewed through the”eyes of the customer”, i.e., it is the physical timeneeded for a feature to be successfully implementedand realeased since the request was added to theBacklog. In terms of the workflow on the board, itis the time needed for a ticket to transit all columns.

Cycle Time. The time needed for a certain ticket/story tobe implemented. Unlike the Lead Time, this doesn’tinclude the first and last column. It shows the actualeffort, in time units (e.g., hours, days, weeks), neededto deliver the user story/feature.


Backlog Size. Backlog Size is the number of tickets that arecurrently submitted and have not been ”issued” intothe development phases. As this definition suggeststhe Backlog Size is, usually, variable over time. Theactually size depends on certain factors such as: howmany tickets are being pulled into the developmentphases, how many new features the client decides toadd and with what priority, do old stories generatenew ones (e.g., after analysis one ticket might gener-ate several new ones in the backlog), etc.

Use custom orself-defined metricsto monitor andcontrol the workflow.Enforced policiesneed to be madeexplicit.

Lead Time subsumes Cycle Time and in our opinion is notso important for the developer, however, crucial for theclient. Additionally, we note that not all the metrics aboveneed to be observed throughout the process. We will latersee that it is sufficient to monitor just two of them.WIP, Cycle Time, and Lead Time can also be defined on av-erage for a better global view of the flow. We believe thataverage cycle time is more useful as it can quickly be usedto identify exceptional tickets, i.e., features that are beingdeveloped too slow or even too fast. In order to controlthe workflow certain policies need to be applied based onthese metrics. However, these policies do need to be madeexplicit, i.e., written down on the board, to maintain trans-parency [6]. As examples of policies we have WIP limiters,pull order, or more complex ones such as ticket prioritiza-tion.

Little’s Law. A very useful law that comes from QueueTheory [3]. It states that the average number of clients in aqueue (N ) is equal to the product of the arrival rate (λ) andthe average time in the queue (T ).

N = λ ∗ T

Applied to Kanban we obtain the average number of ticketsin development (WIP ) is equal to the product of the rateat which tickets arrive (Throughput) and the average timeneeded to finish a ticket (CycleT ime).

1.3 Kanban vs. Scrum 9

WIP = Throughput ∗ CycleT ime ⇐⇒

CycleT ime =WIP

Throughput

Little’s Law is particularly useful as it shows how one cantweak the WIP in order to obtain a desired Cycle Time.Average Cycle Time is, essentially, the speed at which theproduct is being developed and, if needed, can be used intime/cost estimations.

Bottlenecks. They are the main problem in any develop-ment process as some teams are idle, while others are over-whelmingly busy. One efficient way of tackling this issue isto reallocate, if possible, human resources and focus on thechoke point. Reallocating can be a dangerous thing, how-ever, it is worth considering. Additionally, in a pre-emptivemanner one can add extra queues between forseeable bot-tlenecks, such as a Dev Ready queue between the Develop-ment and Test phases [6].

1.3 Kanban vs. Scrum

Kanban and Scrum are the two very popular agile toolkits.Some authors have even proposed methodologies from mi-grating from one toolkit to the other [10]. In the followingsection we will present their differences as well as a methodfor trying to get the best of both worlds.

1.3.1 Scrum

An overview of Scrum can be seen in Figure 1.5. It is easyto observe that while maintaining its agility, it still is a well-structured toolkit [16]. We have clear boundaries for itera-tions and meetings, i.e., everything is precisely timeboxed.


Figure 1.5: Scrum process overview [4]

There are special roles assigned both during the daily meet-ings and during the sprint meeting (Product Owner, De-velopment Team, Scrum Master) and all meetings are me-diated (by the Scrum Master). Scrum is very prescriptive,i.e., there are many rules to follow [9]. For example, sprintmeetings are organized, usually, once every month. Thework to be done (set of items from the backlog to be im-plemented) as well as a strict timeline and plan is charted.Changing the plan after the sprint meeting goes againstScrum. Similarly, the daily meetings have a strict proto-col, e.g., what questions everybody must answer and whatneeds to be done if a problem is signaled.

One major difference between Kanban and Scrum is that inScrum work items may have variable granularity. Not onlybetween sprints but also within the same sprint. This intro-duces a new source of variability which makes identifyingand tackling issues more difficult.

The typical Scrum checklists, boards, and burn-up/burn-down charts do offer an overview of the global devel-opment trend, however, they do not have the problem-exposing capability of the Kanban board and CFDs [9].Thus, Scrum is not particularly well suited for exposing de-velopment bottlenecks.

1.4 Conclusion 11

1.3.2 Mixing the two

Kanban has been criticized for being too chaotic, as itdoes not define any iterations or mediation among theteams. However, it has been continuously praised for itslightweight way of visualizing and controlling the work-flow [9]. Kanban is well-suited for projects where the num-ber of stories is reasonable (e.g., does not exceed 2 digits),however, the lack of structuredness becomes noticeable forlarge projects. The question arises how can we combine thevisualization and flow control of Kanban with the structure,albeit lax, of Scrum? As seen in [9] one efficient way of do-ing it is to define sprints exactly as in Scrum, with all the as-sociated meetings and roles. And, on the other hand, man-age each individual sprint through Kanban. In this manner,an overall iterative sctructure may be observed and eachindividual sprint can be efficiently delivered through Kan-ban, as bottlenecks at sprint-level can be easily handled [9].

1.4 Conclusion

To conclude, Kanban is a very powerful toolkit that helpsvisualize and expose problems, gives methods for tacklingissues, and strives for continous improvemnet of the devel-opment process. Additionally, we stress that only the coreprinciples are set in stone and the structure of the boardand metrics should be adapted to each different scenario.We would like to also present a comic that summarizes, ina somewhat informal way, a normal day in Kanbanland [8].


Figure 1.6

1.4 Conclusion 13

Figure 1.7

15

Bibliography

[1] Electronic Kanban tool. LeanKit Kanban.https://leankitkanban.com/.

[2] Electronic Kanban tool. Agile Zen.http://www.agilezen.com/.

[3] Queue Theory lecture. University of Columbia.http://www.cs.columbia.edu/ misra/COMS6180/notes/queueing.pdf.

[4] Technical Blog. http://www.mountaingoatsoftware.com/scrum/overview.

[5] The agile manifesto. http://agilemanifesto.org/.

[6] D. J. Anderson. Kanban: Successful Evolutionary Changefor Your Technology Business. Blue Hole Press, 2010.

[7] P. Klipp. Technical Blog. kanbanery.com.

[8] H. Kniberg. Technical Blog.http://blog.crisp.se/2009/06/26/henrikkniberg/1246053060000.

[9] H. Kniberg and M. Skarin. Kanban and Scrum - makingthe most of both. lulu.com, March 2010.

[10] N. Nikitina and M. Kajko-Mattsson. Developer-drivenbig-bang process transition from scrum to kanban. InProceedings of the 2011 International Conference on Soft-ware and Systems Process, pages 159–168, May 2011.

[11] T. Ohno. Toyota Production System: Beyond Large-ScaleProduction. Productivity Press, 1988.

[12] J. Olhager and E. Selldin. Supply chain managementsurvey of Swedish manufacturing firms. In Interna-tional Journal of Production Economics, volume 89, pages353–361, 2004.

16 Bibliography

[13] M. Poppendieck and T. Poppendieck. Lean SoftwareDevelopment: An Agile Toolkit. Addison-Wesley Profes-sional, 2003.

[14] A. Roock and H. Wolf. Kanban in der Softwareen-twicklung. In Business Technology Architektur und Man-agement Magazin, January 2010. www.bt-magazin.de.

[15] J.-B. Waldner. Principles of Computer-Integrated Man-ufacturing. London: John Wiley & Sons, September1992.

[16] L. Williams. What agile teams think of agile principles.In Communications of the ACM, volume 55, April 2012.

Typeset August 3, 2012

kanban in a nutshell - software engineering · 2 1 kanban in a nutshell potential problems –...

Documents