Kanban in a nutshell. Chapter Origins and Principles

Transcription

1 1 Chapter 1 Kanban in a nutshell Student: Tiberiu Marian Budău Coordinator: Pascal Bihler Contact: tiberiu.budau@rwth-aachen.de Agile methods and lean approaches have been receiving ever increasing attention within the scientific community and blogosphere alike. In the past three years Kanban, an agile toolkit, has been gaining momentum as a fresh and interesting approach to managing software development and many small- to mid-ranged companies are interested in experimenting with it. In this chapter we wish to present the origin and underlying concepts of Kanban, the Kanban board and metrics, a comparison to its most popular rival Scrum, and a successful way of mixing the two. 1.1 Origins and Principles Kanban was initially developed in the 1950s at Toyota, by Taiichi Ōhno, as a method for supporting JIT (just-in-time) production and reducing inefficiencies throught the whole supply chain [11]. Despite the fact that the name means billboard which is the essential tool used in kanban the two characters actually stand for to visualize/examine and card. Thus showing, that the role of kanban is indeed to offer a clear visualization of the workflow with the aim of examining Kanban is a visualization of the workflow modeled by cards traveling throught all phases of the development process.

2 2 1 Kanban in a nutshell potential problems i.e., bottlenecks. The cards are either signals of orders for production/supply or in the case of D. Anderson s Kanban [6], virtual signals to pull features/use cases that need to be implemented Kanban in supply chain management Figure 1.1: An example of a kanban card[11] From the production manager s point of view kanban is a pull-based methodology that reduces non-value-added waste. As mentioned in [15] the actual role of kanban as a JIT production tool was to ensure the transparency of the inventory levels. Meaning that when a product was consumed a kanban card would be returned to the producer, within the current producer/consumer node of the supply chain. Once a certain threshold of cards has been reached, the producer would start the production process and, if needed, pull any required resource from upstream [11]. This method was particularly efficient as it reduced non-value-added waste. In other words, there where no costs incurred by the producer without obtaining immediate profit [11]. A possible kanban card can be viewed in Figure 1.1. Nowadays, kanban is implemented as a fullyautomated software tool in the form of E-Kanban and has been ever increasing in popularity, according to some surveys [12].

3 1.1 Origins and Principles Principles of Kanban Kanban, which was adapted by D. Anderson [6] from the Toyota Production System kanban, in our opinion, is based upon a set of Agile and Lean Principles that focus on: Human capital, developers and clients are valuable assets; Reducing communication overhead and increasing human interaction; Eliminating unnecessary formalities, chains of command, and increasing reaction to change; Seeing the whole and exposing problems as soon as possible; Rapidly developing a working software solution; Just by scanning the aforementioned principles we can notice that most of the Agile Manifesto [5] and the properties of Lean Software [13] are contained therein. We also observe 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 to observe the development process as a whole. Identifying bottlenecks, idle areas, and in general increasing the overall productivity are the main objectives. The tools used are the Kanban board and tickets. Pull. Tickets are being pulled, not pushed, throughout the different phases of the development process. Pulling creates slack by definition, lack of tension in a wire which can be exploited, i.e., idle teams can help out colleagues that are struggling in other phases of development. Furthermore, the existence of slack offers the possiblity of improvement and learning. Limit your WIP. WIP stands for Work In Progress and is a threshold used to limit the number of tickets that exist

4 4 1 Kanban in a nutshell at any given moment in every phase. These thresholds need not be the same for every phase. Measure and Control. Measuring and controlling the flow, often through the use of elements from Queueing Theory and from the Theory of Constraints, in order to achieve maximum efficiency. Visualizing, Pulling, Measuring and Controlling, Continously improving, and Limiting your WIP is the Kanban way to do it. Improve Continously and Collaboratively. This principle refers to learning from mistakes and continuously improving the process. Well-known methodologies such as Plan-Do-Check-Act (PDCA), Kaizen, or the Deming cycle can be used. Figure 1.2 shows a few problems that Kanban highlights and 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 implement a Kanban process, what the tool structure is, how to use them, as well as ways of monitoring and controlling the workflow.

5 1.2 Kanban Tools, Structure, and Metrics Tools and Structure As previously mentioned the two essential tools for Kanban are the Kanban board and tickets. Kanban is usually phyisically implemented, e.g., with a normal white board and sticky notes. An alternative would be using software tools that emulate the Kanban process, such as LeanKit Kanban [1] or Agile Zen [2]. We will focus on physical implementation, however, the electronic versions do offer better overall management, access to more information, and are suitable for geographically distributed teams [6]. It is arguable whether the physical board offers more information, however, it does offer flexibility and the potential to expose problems faster, e.g., if several teams are arguing over a ticket and others observe this, then the user story needs to be considered and reanalyzed. Kanban board. The Kanban board, as the name suggests, can be a normal white board. It is divided into columns, each column representing one different phase of the development process. Black tape is usually used to facilitate on-the-fly restructuring, if needed. The transit of tickets throughout the columns offers a visual representation of the workflow. After establishing the workflow, each column may have associated input queues, buffers, and is annotated with a WIP limiter the maximum number of tickets that can exist in that column at any given time. Tickets transit by convention from left to right and are pulled in any arbitrary order, depending on the team s needs. Under some special circumstances it is envisionable that a ticket would be removed from the board, e.g., if the client decides the feature is no longer needed. Kanban tickets. The initial work is, usually, divided into many small, preferably independent, user stories. However, more coarse grained tickets can be utilized (e.g., breakdown into features). Ideally, all tickets should be equally course. Each user story is written on one ticket and initially placed in the first column, usually, referred to as the Backlog. A ticket transits all columns until reaching the last column,

6 6 1 Kanban in a nutshell usually, referred to as Done/Live. Each ticket has an associated team that takes care of that user story within that particular development phase. In the likely case of a bottleneck idle teams may help their struggling colleagues across different phases. The Kanban board should always be adapted with respect to 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 process based on the individual needs of each project. Figure 1.3 illustrates the Kanban board that was used in last year s laboratory. It is important to observe that almost all phases, except the Development phase, are controlled by the customer. Thus, showing that the client plays an active role in the development of the product. Figure 1.3: Last year s Agile Lab board Metrics In order to better visualize how a certain Kanban process behaves we construct a Cumulative Flow Diagram (CFD). As the name suggests it is a graphical representation of the transit of all tickets on the board (the Y-axis) during a given time period (the X-axis). We need metrics in order to ensure the measurement and control of the flow. For example, metrics to monitor the flow and see if certain policies have the

7 1.2 Kanban Tools, Structure, and Metrics 7 Figure 1.4: A Cumulative Flow Diagram and its associated metrics [7] desired effect usually successfully omitting bottlenecks. A relatively large number of metrics can be defined and deduced directly from the CFD. In Figure 1.4 we observe the following metrics: WIP. Work In Progress is the entire amount of work being done and can be defined for any moment in time. In other words, it is the number of tickets present in all columns (except the backlog/first column and live/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 time needed for a feature to be successfully implemented and realeased since the request was added to the Backlog. In terms of the workflow on the board, it is the time needed for a ticket to transit all columns. Cycle Time. The time needed for a certain ticket/story to be implemented. Unlike the Lead Time, this doesn t include the first and last column. It shows the actual effort, in time units (e.g., hours, days, weeks), needed to deliver the user story/feature.

8 8 1 Kanban in a nutshell Backlog Size. Backlog Size is the number of tickets that are currently submitted and have not been issued into the development phases. As this definition suggests the Backlog Size is, usually, variable over time. The actually size depends on certain factors such as: how many tickets are being pulled into the development phases, how many new features the client decides to add and with what priority, do old stories generate new ones (e.g., after analysis one ticket might generate several new ones in the backlog), etc. Use custom or self-defined metrics to monitor and control the workflow. Enforced policies need to be made explicit. Lead Time subsumes Cycle Time and in our opinion is not so important for the developer, however, crucial for the client. Additionally, we note that not all the metrics above need to be observed throughout the process. We will later see that it is sufficient to monitor just two of them. WIP, Cycle Time, and Lead Time can also be defined on average for a better global view of the flow. We believe that average cycle time is more useful as it can quickly be used to identify exceptional tickets, i.e., features that are being developed too slow or even too fast. In order to control the workflow certain policies need to be applied based on these metrics. However, these policies do need to be made explicit, i.e., written down on the board, to maintain transparency [6]. As examples of policies we have WIP limiters, pull order, or more complex ones such as ticket prioritization. Little s Law. A very useful law that comes from Queue Theory [3]. It states that the average number of clients in a queue (N) is equal to the product of the arrival rate (λ) and the average time in the queue (T ). N = λ T Applied to Kanban we obtain the average number of tickets in development (W IP ) is equal to the product of the rate at which tickets arrive (T hroughput) and the average time needed to finish a ticket (CycleT ime).

9 1.3 Kanban vs. Scrum 9 W IP = T hroughput CycleT ime CycleT ime = W IP T hroughput Little s Law is particularly useful as it shows how one can tweak the WIP in order to obtain a desired Cycle Time. Average Cycle Time is, essentially, the speed at which the product is being developed and, if needed, can be used in time/cost estimations. Bottlenecks. They are the main problem in any development process as some teams are idle, while others are overwhelmingly busy. One efficient way of tackling this issue is to reallocate, if possible, human resources and focus on the choke point. Reallocating can be a dangerous thing, however, it is worth considering. Additionally, in a pre-emptive manner one can add extra queues between forseeable bottlenecks, such as a Dev Ready queue between the Development 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 migrating from one toolkit to the other [10]. In the following section we will present their differences as well as a method for trying to get the best of both worlds Scrum An overview of Scrum can be seen in Figure 1.5. It is easy to observe that while maintaining its agility, it still is a wellstructured toolkit [16]. We have clear boundaries for iterations and meetings, i.e., everything is precisely timeboxed.

10 10 1 Kanban in a nutshell Figure 1.5: Scrum process overview [4] There are special roles assigned both during the daily meetings and during the sprint meeting (Product Owner, Development Team, Scrum Master) and all meetings are mediated (by the Scrum Master). Scrum is very prescriptive, i.e., there are many rules to follow [9]. For example, sprint meetings are organized, usually, once every month. The work to be done (set of items from the backlog to be implemented) as well as a strict timeline and plan is charted. Changing the plan after the sprint meeting goes against Scrum. Similarly, the daily meetings have a strict protocol, e.g., what questions everybody must answer and what needs to be done if a problem is signaled. One major difference between Kanban and Scrum is that in Scrum work items may have variable granularity. Not only between sprints but also within the same sprint. This introduces a new source of variability which makes identifying and tackling issues more difficult. The typical Scrum checklists, boards, and burn-up/burndown charts do offer an overview of the global development trend, however, they do not have the problemexposing capability of the Kanban board and CFDs [9]. Thus, Scrum is not particularly well suited for exposing development bottlenecks.

11 1.4 Conclusion Mixing the two Kanban has been criticized for being too chaotic, as it does not define any iterations or mediation among the teams. However, it has been continuously praised for its lightweight way of visualizing and controlling the workflow [9]. Kanban is well-suited for projects where the number of stories is reasonable (e.g., does not exceed 2 digits), however, the lack of structuredness becomes noticeable for large projects. The question arises how can we combine the visualization and flow control of Kanban with the structure, albeit lax, of Scrum? As seen in [9] one efficient way of doing it is to define sprints exactly as in Scrum, with all the associated meetings and roles. And, on the other hand, manage each individual sprint through Kanban. In this manner, an overall iterative sctructure may be observed and each individual sprint can be efficiently delivered through Kanban, as bottlenecks at sprint-level can be easily handled [9]. 1.4 Conclusion To conclude, Kanban is a very powerful toolkit that helps visualize and expose problems, gives methods for tackling issues, and strives for continous improvemnet of the development process. Additionally, we stress that only the core principles are set in stone and the structure of the board and metrics should be adapted to each different scenario. We would like to also present a comic that summarizes, in a somewhat informal way, a normal day in Kanbanland [8].

12 12 1 Kanban in a nutshell

13 1.4 Conclusion 13

14

15 15 Bibliography [1] Electronic Kanban tool. LeanKit Kanban. [2] Electronic Kanban tool. Agile Zen. [3] Queue Theory lecture. University of Columbia. misra/coms6180/notes/queueing.pdf. [4] Technical Blog. [5] The agile manifesto. [6] D. J. Anderson. Kanban: Successful Evolutionary Change for Your Technology Business. Blue Hole Press, [7] P. Klipp. Technical Blog. kanbanery.com. [8] H. Kniberg. Technical Blog. [9] H. Kniberg and M. Skarin. Kanban and Scrum - making the most of both. lulu.com, March [10] N. Nikitina and M. Kajko-Mattsson. Developer-driven big-bang process transition from scrum to kanban. In Proceedings of the 2011 International Conference on Software and Systems Process, pages , May [11] T. Ōhno. Toyota Production System: Beyond Large-Scale Production. Productivity Press, [12] J. Olhager and E. Selldin. Supply chain management survey of Swedish manufacturing firms. In International Journal of Production Economics, volume 89, pages , 2004.

16 16 Bibliography [13] M. Poppendieck and T. Poppendieck. Lean Software Development: An Agile Toolkit. Addison-Wesley Professional, [14] A. Roock and H. Wolf. Kanban in der Softwareentwicklung. In Business Technology Architektur und Management Magazin, January [15] J.-B. Waldner. Principles of Computer-Integrated Manufacturing. London: John Wiley & Sons, September [16] L. Williams. What agile teams think of agile principles. In Communications of the ACM, volume 55, April 2012.

17 Typeset August 3, 2012