S Menon's Blog: Enter Keywords..

Kanban Applied to Software Development: from Agile to Lean | S Menon's Blog
Page 1 of 21
Home About
Enter keywords...
S Menon's Blog
Personal notes Address Cooking Development Engineering Music News photography Uncategorized
Kanban Applied to Software Development: from Agile to Lean

May 20th, 2011 smenon Uncategorized No comments Copyright
Posted by Kenji Hiranabe on http://www.infoq.com/articles/hiranabe-lean-agile-kanban dated Jan 14, 2008
Abstract
A Kanban1 is a physical card used in Toyota Production System (TPS) to support non-centralized pull production control. It has spread to the manufacturing industry all over the world as a tool of Lean Manufacturing. Now in Agile software development the visualization of projects, such as posting task cards on a wall, is a commonly seen practice, which is sometimes called Software Kanban, or Task Kanban. Now we even see some product maintenance teams utilizing Kanban systems in a waterfall-like process model. So what is Kanban? Why is it used in the context of software development?
RelatedVendorContent
The Agile Tester Agile Development: A Managers Roadmap for Success Kanban for Agile Teams
http://www.menon.bz/sblog/?p=813
9/28/2011
Page 2 of 21
Best Practices of Agile Tool Users CI, SCM Seven Deadly Sins of Slow Software Builds & How to Parallelize your Builds
Related Sponsor
In todays hyper-competitive world, later may be too late to adopt Agile development and this Roadmap for Success will help you get started. Download Agile Development: A Managers Roadmap for Success now! In this article, I first explain what a Kanban system is in the context of Lean manufacturing, especially in TPS, and gather insights from the practices and principles in that mature industry, identifying concepts that can be applied to software development. Secondly I look around our software development projects and point out examples of Kanban applications. Then, I analyze commonality and differences between Kanban systems in production and in software development, and try to give ideas on how to effectively apply Kanban system to software development, including an introduction to the recent movement of KSSE Kanban System for Sustaining Engineering emerging on the kanbandev 2 discussion list. Finally, I give a big picture of TPS, the original context for which Kanbans use as a tool, and from which software development can still learn more.
What is Kanban in TPS?

A Kanban is a signaling device (usually a physical card in a clear plastic envelope) that instructs the moving or creating of parts in a pull production system, invented and developed as part of the Toyota Production System (TPS). Before getting into Kanban in software development, here I take a close look at its original usage i.e. Kanban in TPS. Kanbans aim is to minimize WIP (Work-In-Process), or inventory, between processes by making sure that the upstream process produces parts only if its downstream process needs it. Pull means that the downstream workers withdraw or pull the parts they need from their upstream processes.
9/28/2011
Page 3 of 21
Figure 1 Kanban and Pull Production Figure 1 is an abstract model of a Kanban system. Illustrated in it are two processes, an upstream and a downstream process, where the upstream process supplies parts (items) to the downstream. In order to supply products to the final customer, the process needs to produce parts and make them flow to the downstream, but not too much, as overproduction is considered the worst waste. So to prevent overproduction, the upstream doesnt push finished parts to the downstream, but instead it is the downstream that actively pulls (fetches) the parts from the upstream. The space where parts are placed is called the store (or supermarket 3 Taiichi Ohno got the first idea of Kanban when he visited an American supermarket, where it is not the store clerk but the customer himself who goes to get what he needs in the store). The store is in the upstream location and works as a buffer or a queue of WIP. When a worker from the downstream process, called material handler, comes to the store and picks up newly finished parts, it also returns a signal of production i.e. the downstream pulls things from the upstream and at the same time pushes information to the upstream via Kanban cards. This is needed, because the upstream process never produces parts without instruction from the downstream process. So here are two types of Kanban working together in Figure 1: Withdraw Kanban is one item on a shopping list which the material handler takes to the store.
9/28/2011
Page 4 of 21
Production Kanban instructs upstream processes to produce parts for its downstream processes. As shown in Figure 1, withdraw Kanbans circulate between the processes, while production Kanbans circulate within the process, and they are exchanged at the store. Lets get a little bit more into the mechanics of this. Figure 2 illustrates how the Kanban exchange works at the store.
Figure 2 Kanban Exchange in the Store 1. A material handler in the downstream location is signaled to withdraw parts. The signal is defined by the downstream process and either one of the two below: (a) signaled by the amount of collected withdraw Kanbans (b) signaled by periodic time interval He visits the store in the upstream location with empty pallets and his collected withdraw Kanbans as a shopping list, which indicates what is needed and in what amount for the downstream process. 2. Parts finished by the upstream process are packed in pallets and placed in the store with production Kanbans attached. (This occurs independently of (1), in a separate thread.) 3. The material handler picks the parts specified by the withdraw Kanban (the shopping list), checks if it matches the production Kanban attached to the parts, and exchanges the two Kanbans. 4. He puts the production Kanban to the Production Board, which will later visually trigger the upstream production when Kanbans stacks to a threshold. 5. He conveys the needed parts, with the withdraw Kanban attached, from the store to the downstream location.
9/28/2011
Page 5 of 21
You see that the store is a queue between two processes, working in a separate thread of control, exchanging things and information via Kanban. On the surface of the Kanban cards, such information as the part number/name, quantity, pallet type, store address, are written so that the material handler who takes this card can know what to do. There is a strict discipline of running Kanban, called six rules of Kanban: 1. Customer(Downstream) processes withdraw items in the precise amounts specified on the Kanban. 2. Supplier(Upstream) produces items in the precise amounts and sequences specified by the Kanban 3. No items are made or moved without a Kanban. 4. A Kanban should accompany each item, every time. 5. Defects and incorrect amounts are never sent to the next downstream process. 6. The number of Kanbans is reduced carefully to lower inventories and to reveal problems. As we have explored, the store works as a queue of parts, the pallets work as a carrier of parts, and the Kanban cards work as a carrier of customer-need information. They make it a pull system, creating a balance between sustaining continuous flow (eliminating the waste of waiting) and minizing WIP (eliminating the waste of overproduction). This mechanism of managing the right amount of WIP in the flow between buying-in and selling-out is exactly what happens in a supermarket, and doing it well is the key to the profitability of the store. So far, I have described how Kanban works in manufacturing. Note that this description is a simplified model of a real Kanban system. One other thing which is not explicitly mentioned here is that Kanban visually shows the flow of information and things to every worker and stimulates Kaizen 4 (process improvement) in the Gemba 5 (the workplace). Kaizen starts with watching what is happening in the Gemba. Via Kanban, every worker (not manager) can see the flow and has a chance to notice waste in the flow and suggest improvement to the process in which they are working.
Properties of Kanban
From the detailed observations in the previous section, here is a list of extracted properties and effects of the original Kanban concept in TPS. 1. 2. 3. 4. 5. 6. 7. 8. 9. Physical: It is a physical card. It can be held in the hand, moved, and put into or onto something. Limits WIP: It limits WIP (Work-In-Process), i.e. prevents overproduction. Continuous Flow: It notifies needs of production before the store runs out of stock. Pull: The downstream process pulls items from the upstream process. Self-Directing: It has all information on what to do and makes production autonomous in a noncentralized manner and without micro-management. Visual: It is stacked or posted to show the current status and progress, visually. Signal: Its visual status signals the next withdrawal or production actions. Kaizen: Visual process flow informs and stimulates Kaizen. Attached: It is attached to and moves with physical parts supplied.
Figure 3 is a diagram of effects of the nine properties above, showing how these form a cause-and-effect network. As youll see here, there are roughly two different meanings of Kanban, one is Limits WIP while sustaining Continuous Flow, and the other is Kaizen.
9/28/2011
Page 6 of 21
Figure 3 Properties and Effects of Kanban The right-hand side of this graph explains how it minimizes WIP while sustaining continuous flow. If WIP in the store is too few, the downstream process has to wait for items not ready when needed, but at the same time WIP should be minimized to prevent overproduction. So the two goals are conflicting, and Kanban can be seen as a strategy to resolve the dilemma. Kanban is physically attached to parts and it is collected and reused, so the number of Kanbans is fixed. And it also visually signals the downstream process to pull parts only when it is needed. These two mechanisms limit WIP. The first mechanism Physically attached Kanban works like the law of the conservation of energy. Once the number of Kanbans is defined based on the rate of product sales in the market and variability intrinsic to the current process, WIP is limited in proportion to the number of Kanbans, regardless of incoming and outgoing flow of parts. The maximum number of Kanbans (the energy in the system) is fixed and physically conserves the upper limit of WIP at any given time. In Figure 4, you will see that System is the inventory between the upstream process and downstream process, i.e. the WIP in the store.
9/28/2011
Page 7 of 21
Figure 4 Kanban Mechanism of Limiting WIP The second mechanism, Pull, also limits WIP by making the production velocity of the upstream process dependent on the downstream consumption velocity. The first mechanism only refers to the amount of WIP, but this second refers to the flow, its direction and speed. Direction The motivation of production is given only by the downstream process. Speed Kanban communicates the timing and the amount of next production. Pull limits WIP by making the upstream processs production dependent on the downstream process consumption in the 1st derivation order. This dependency is achieved by the Kanban exchange occurring in the store, pushing the production control information from the downstream process to the upstream. Back to Figure 3: the left-hand side of the graph explains how it makes work self-directing and promotes Kaizen. Everyone can understand what is happening and how well the process is flowing by seeing the Kanban cards posted to boards. Watching the workflow in the Gemba is the start of Kaizen. And physical Kanban cards put on the boards visually makes work self-directing without central control of management. This autonomous process provides data on its performance to support Kaizen, and shifts management attention from assigning or dispatching detailed work to Kaizen activities. As shown by the graphs arrows, terminating in the three effects, the ultimate goals of Kanban can be represented by Limits WIP, Continuous Flow and Kaizen. A Kanban system Limits WIP while sustaining Continuous Flow. It buffers variability due to common cause variation, and exposes special cause variability, providing candidates for Kaizen.
Kanban in Software Development

Now, lets look at our own field of work software development. In Agile software development, it has become a common practice to visualize and share project status by posting cards on a wall of the project room. I have described many of examples in my last InfoQ article Visualizing Agile Projects using Kanban Boards [Hiranabe07]. In particular, task cards posted on a wall showing the current status are sometimes called Task Kanban or Software Kanban [Poppendieck03]. Figure 5 is an example of
9/28/2011
Page 8 of 21
Task Kanban implemented by the JUDE 6 development team at Change Vision, Inc.
Figure 5 Agile Kanban On the board, engineering tasks are represented by cards (Post-It Notes), and the statuses are indicated by posting them to separate areas on the board labeled ToDo, Doing, and Done (Label names often differ from site to site, examples are In Progress, Tested, Accepted, Blocking etc.). This Kanban Board helps visually signal tasks and limit WIP (tasks actively being worked on). But no processes (upstream or downstream) are found here, and a new concept of iteration appears. For each iteration, tasks are newly identified by breaking down user stories into tasks and it is these tasks that are posted onto the ToDo area. Is this a pull system? In manufacturing, parts are handed off from an upstream process to its downstream process. In the Agile development visualization shown in Figure 5, no handoffs can be seen. One Kanban card is a counterpart of one task, and written on it are information such as: task id, task name, estimate of time, and persons name who signed up to the task. The task has a status, either ToDo, Doing or Done, and is shared by the team. The Agile development approach values working together, and tends to reduce handoffs within the team. I call this an Agile Kanban. Figure 6 is another example of Kanban Board implemented at Yamaha Motor Solution Co, Ltd 7.
9/28/2011
Page 9 of 21
Figure 6 Sustaining Kanban Here, a Kanban system is used in a traditional waterfall development model but with a flow. This project has separate and serial processes which they call design, development, validation etc., and the Kanban cards move between processes. Each card represents a requirement for change or addition to the system and is a handoff to the downstream process. Note that this is not a classic waterfall process, where all the requirements are designed at one time, developed, and validated at another time, which would cause all the cards to move in a group. Instead, the cards move one by one, like the onepiece-flow of manufacturing. Whats happening here is a stable sustaining phase in a products lifecycle, managed in a waterfall state transition model with a flow. Here, you can clearly see the flow of work concept instead, different from the iteration concept of Agile. It looks more like Kanban in factories than Agile Kanban does and it can be a pull system by making a rule to allow only the downstream process to move the cards 8. I call this Sustaining Kanban, and find it similar to David Andersons Kanban System for Sustaining Engineering, which I discuss in the later section. And another example, Figure 7, is a thought experiment showing usage of Kanban in a value stream of a whole product development process [Poppendieck 07].
9/28/2011
Page 10 of 21
Figure 7 Lean + Agile Kanban Suppose there are a customer team, a product owner, a development team and a QA team in one product development stream, and they are working together passing handoffs using queues so that the teams can work asynchronously, maintaining a working speed dependent on one another. Each DONE space is, effectively, the queue working like the store in a manufacturing factory, and it looks pretty much like a TPS Kanban system. Coincidentally, it looks rather like using Agile Kanban synchronously within each process and using Sustaining Kanban asynchronously across the whole value stream of processes. I think a Kanban system can scale to cover the full value stream, in which case it works as a live visualization of the value stream. In this example, WIP can be limited by defining the size of each area. To make this a pull system, it needs a mechanism allowing the downstream process to somehow signal the upstream process to start working. Making a rule that only the downstream can move the DONE cards to signal the upstream is one option. Having Iteration Meetings periodically is another option which synchronizes the teams and the transportation (communication) of the information among the teams. These two options of communication might correspond to the two signals of withdrawal of parts discussed in section 1, namely visual signal of the amount of withdrawal Kanban (a) and periodic time interval (b). Here, a set of user stories for one iteration corresponds to parts withdrawn in pallets for the iteration, and the number of parts (Kanban) corresponds to project Velocity(yesterdays weather [Beck00]) of the iteration. I call this Lean + Agile Kanban, and it can be combined with Agile Kanban, as shown the next example. Figure 8 is a smaller portable Kanban system I found in a project in CENTRAL COMPUTER SERVICES Co. Ltd. In this project, a team is working in several smaller sub teams (usually a pair). The whole team has a workflow conceptually similar to Figure 7, as well as smaller Agile Kanban boards shown in Figure 8 (ToDo/Doing/DONE type), too. When a sub-team picks one user story, they break it down into their tasks and post them onto this portable Kanban board. In this case, a Kanban system is
9/28/2011
Page 11 of 21
composed of two levels, a project level in which a card represents a user story and a team (or a pair) level where a card represents a task. They liked this portable small Kanban system very much and named it Kanban-nano.
Figure 8 Portable Agile Kanban (Kanban-nano) As you see, there are several ways to apply the Kanban concept to software development. Agile Kanban works within a team to share information and to make work self-directing, but it doesnt support flow. Sustaining Kanban is another type, enabling small-batch maintenance work to flow between several states. And the combination is Lean + Agile Kanban which uses Sustaining Kanban across the value stream, and use Agile Kanban within a sub-stream. It is important to notice that the first Agile Kanban in Figure 5, which is commonly seen in todays Agile projects, sees only a sub-team in a value stream. When you think about the full value stream from customer to customer, there is usually a team within the same stream that hands you requirements or another team that delivers your results to the customer.One of the aims of this paper is to give an idea to extend the application of Kanban beyond the Agile Kanban, to more of the value stream.
Production and Development

Software development is not a production or a manufacturing activity [Reves92]. Software engineers create different things every time, whereas manufacturing produces same things over and over again. So a direct mapping between production and development is dangerous. However, lets examine how the properties of TPS Kanban are found in different types of software development Kanban. Table 1 shows whether the Kanban properties found in section 1 are still true in the two types of software Kanban weve described.
9/28/2011
Page 12 of 21
Limits WIP, Continuous Flow and Pull properties are not attained by the Agile Kanban example by itself, shown in Figure 5. Agile Kanban focuses more on enabling tasks, Visual and Selfdirecting, so as to help the team become autonomous and improve their own process. In order to make the process continuously flow as well as to limit WIP, iteration meetings are needed to communicate the information. The Sustaining Kanban in Figure 6 can limit WIP and also control the flow in a one-piece and pull manner, without iteration meetings. In this approach, the focus is on Limits WIP, Continuous Flow and Pull, at the same time, allowing the team (or manager) to use it for process improvement purposes. Coming back to Figure 3, I categorized the properties and effects of Kanban into two focus areas in Figure 9, so the above two software Kanban concepts can fit their purpose. And Figure 10 illustrates the spectrum of Production and Development. Production is a process with a very high chance of success (more than 99%), whereas development is one with a much lower chance of success. Agile is an optimal development approach when the chance of success is 50% of the time, while waterfall is optimal when chance of success is over 90% (applying Shannons theory, a project with a 50% chance of success is the most valuable project). Typically as development moves into a sustaining maintenance mode, chance of success for bug-fixing or adding new features goes up. Kanban systems Process Control Focus suits work with over 90% success rate and Process Improvement Focus suits work in the area of 50% as well as 90%. Note that an Agile approach still works well in a sustaining mode of a product, and the Process Improvement Focused features of Kanban work well in sustaining mode, too.
9/28/2011
Page 13 of 21
Figure 9 Properties and Effects of Kanban (2)
9/28/2011
Page 14 of 21
Figure 10 Spectrums of Approach using Kanban
KSSE Kanban System for Sustaining Engineering

Here I introduce the recent emergence of a Lean application to software development. While I was at the Agile2007 conference, I attended a CWAC (Conference-Within-A-Conference) session about software Kanban, led by David Anderson. He managed a maintenance mode type of Kanban system at Corbis.com and published a related paper, Kanban System for Sustaining Engineering [Anderson 07]. His approach first focuses on the Limits WIP property of Kanban, as in the abstraction diagram of Figure 4, as well as the Self-Directing property that makes the team self-organizing, requiring less top-down management. Then, by visualizing the flow via Kanbans he found stagnation points in the whole process stream, and adjusted human resources, i.e. shifted members between the processes. That means that his approach covers from Limits WIP property and Self-Directing to Kaizen property of Kanban, as in Figure 3. After the conference, Anderson started a kanbandev mailing list 2, where there has been an emerging, knowledge-creating discussion on applying Kanban to software development, called KSSE Kanban System for Sustaining Engineering, pronounced Kiss-ee . Aaron Sanders is also involved in building knowledge about Kanban, and has started to build a vocabulary of KSSE. KSSE works well if there are serially connected multiple processes passing handoffs in queues between the processes. Note that KSSE doesnt necessarily have an iteration concept. I see possibility of scaling Agile in a different way than scrum of scrums, using the KSSE approach. [Ladas07]
Make value flow
9/28/2011
Page 15 of 21
When scaling Agile to Lean using Kanban, what should one Kanban card represent? In an Agile Kanban system, one card is a task broken down from a user story. In a development team, it works as a unit of work because everyone in the team can understand what it means. But in Kanban systems that work through multiple processes (teams) across a value stream, what is flowing should have customer-recognized value. In this case, one Kanban cards corresponds not to work but to a feature, and it is not a fragment of WBS (work breakdown structure) but of FBS (feature breakdown structure) so that everyone in the stream, even the customer, can understand the meaning and the value of what is flowing. Jim Highsmith also positioned FBS over WBS in his principles outlined in the book Agile Project Management. [Highsmith04] User Stories, Backlog Items or Use Cases are abstractly called MMF (minimum marketable features) so to explicitly state that what is flowing has a customer value. And lean development can be translated as make MMFs flow fast through the full value stream. The example Agile Kanban in Figure 5 is a work breakdown, and it works well within the team. The example Sustaining Kanban in Figure 6 is a feature breakdown and one card represents an MMF. And the example of Lean + Agile Kanban in Figure 7 used with Figure 8 shows a combination of a feature breakdown in the upper level and a work breakdown in the lower level. Once the flow of work is established, the five core concepts of Lean Thinking [Womack1996] can be applied directly to the whole process. Management of the Lean process simply follows the principles below. Specify value in the eyes of the customer Specify and sort MMFs Identify the value stream and eliminate waste Find stagnation (blocking task) Make value flow at the pull of the customer Make a pull rule of Kanban Involve and empower employees Empower the team in the Gemba Continuously improve in the pursuit of perfection Reflection and Kaizen
TPS, the Big Picture

What follows is a kind of appendix, sharing what I have learned from the Toyota Production System (TPS) and found applicable to software development. Mary and Tom Poppendieck have been finding that effective software development has much in common with Lean or TPS not at the practical level, but at the level of principles [Poppendieck03, 07]. So lets take a step back and look at Kanban in TPS from a higher viewpoint. It is easy to assume that Kanban is the center of TPS, but it is not. Figure 11 shows the conceptual structure of TPS, sometimes called TPS House. There exist several versions of it, and Figure 11 is based on Toshiko Narusawa and John Shooks version [Narusawa06]. In TPS, Kanban is just a device for a pull system to realize Just-In-Time 9. Just-In-Time can be paraphrased as making and delivering what is needed, just when needed, and just in the amount needed. It aims at meeting a customers need: the best quality product at the lowest price as soon as possible. Note that Just-In-Time is one of the two pillars of TPS, to the other being Jidoka 10. Jidoka or Autonomation is a manufacturing parallel to Test-Driven Development in software development. Mary and Tom Poppendieck interpreted Jidoka as Stop the Line Culture. Workers in Toyota factories really stop the line rather than send defects to the next downstream it is not only the
9/28/2011
Page 16 of 21
rule but almost the culture of Toyota, which can be traced back to Sakichi Toyodas loom.
Figure 11 TPS Concept Structure Just-In-Time is composed of three elements, Takt time, Continuous flow, and Pull system. 1. Takt time defines, based on the rate of sales, the rate of making products. 2. Continuous flow produces items within a process without stagnation matching takt time. 3. Pull system moves parts and instructs production between processes limiting the amount of inventory. Also note that the two pillars rely on Kaizen and People. Toyota produces almost 10 million automobiles a year, and at the same time, they improve their process by nearly 1 million Kaizen proposals in the Gemba (i.e., in the workplace). Visualizing what the team is doing is always the starting point of Kaizen.
Conclusion
I have analysed Kaban operations in manufacturing and outlined its properties. Kanban systems are used in order to achieve: 1. better process control they keep continuous flow while limiting WIP 2. better process improvement they make the flow visible and stimulate Kaizen.
9/28/2011
Page 17 of 21
What I call Agile Kanban focuses on #2, while Sustaining Kanban focuses on #1. I proposed a combination of the two to extend visualization and pull system to the full value stream to make the whole lean.
Acknowledgements
Tom Poppendieck reviewed this paper thoroughly with Mary and provided lots of insights and suggestions, for which I am most thankful. Yasuharu Terai, the president of Yamaha Motor Solution Co., Ltd., and Ryuichi Sato gave me permission to use the photograph of their Kanban system. David Anderson also reviewed this paper and suggested a better abstraction level of Kanban to move KSSE forward. Kanbandev Yahoo group discussion is a source of emerging ideas of KSSE. And I appreciate Deborah Hartmanns final edit that made my intent much clearer.
About the Author

Kenji HIRANABE is CEO of Change Vision, Inc., based in Japan. He is the creator of JUDE, a UML editor integrated with ERD, DFD and Mind Map, and TRICHORD 11, a Kanban system integrated with Burndown Charts and Parking Lots for Agile project management. He has also translated the books Lean Software Development, XP Installed, Agile Project Management, and other XP/Agile books into Japanese. Kenji thinks of software development as a form of communication game, and has been trying better ways that makes it more productive, collaborative, and fun.
References
TPS [Ohno78] Taiichi Ohno, Toyota Seisan Houshiki, 1978 (English: Toyota Production System, 1988). The bible of TPS. This is a MUST book for lean practicioners. [Narusawa06] Toshiko Narusawa, John Shook, Eigo de Kaizen, Toyota seisan houshiki, 2007 (Japanese and English). Recently published English/Japanese parallel translation of TPS. [Ishii05] Masamitsu Ishii, Toyota no moto-koujousekininnsha ga oshieru nyuumon Toyota seisan houshiki, 2005. Includes a version of TSP concept structure. [Monden06] Yasuhiro Kadota, Toyota Production System, 2006(English: Toyota Production System 3rd, 1998). The bible of implementation of TPS. I studied Kanban discussion in section 1 from this book. Agile and Lean Mainstream [Reeves92] Jack W. Reeves, What is Software Design? C++ Journal, 1992. My favorite article about Software Design. [Kent00] Kent Beck and Martin Fowler, Planning Extreme Programming, 2000, AddisonWesley. About planning of release and iteration. Yesterdays weather and project velocity idea first explained in detail in the book. [Poppendieck03] Mary and Tom Poppendieck, Lean Software Development, 2003 AddisonWesley. The first classic of drawing lines between TPS and software development.
9/28/2011
Page 18 of 21
[Highsmith04] Jim Highsmith, Agile Project Management, 2004, Addison-Wesley. Feature breakdown structure is introduced as a practice of APM. [Poppendieck07] Mary and Tom Poppendieck, Implementing Lean Software Development, 2006 Addison-Wesley. Explains Kanban in lean and how it works as a pull process mechanism. [Cockburn06] Alistair Cockburn, What engineering has in common with manufacturing and why it matters 2006. Alistair has another discussion of viewing unvalidated decision as WIP in software engineering process. Recently Emerging Kanban Concept [Hiranabe07] Kenji Hiranabe, Visualizing Agile Projects using Kanban. A Colletion of visualization methods and Kanban in Agile development workplace [Anderson07] David Anderson, A Kanban System for Sustaining Engineering on Software Systems. His experience in Corbis.com with a Kanban system [Sanders07] Aaron Sanders, Kanban Ground Rules Example for a Specific Team Kanban System for Software Engineering KSSE. Also creating a body of knowledge of KSSE. [Ladas07] Corey Ladas, Lean scales differently than Agile. Kanban can be another possible way of scaling agile in a lean and flat way, unlike scrum of scrum.
1Read 2Read
about Kanban http://en.wikipedia.org/wiki/Kanban about kanbandev http://finance.groups.yahoo.com/group/kanbandev 3Read about Taiichi Ohno http://en.wikipedia.org/wiki/Taiichi_Ohno 4Read about Kaizen http://en.wikipedia.org/wiki/Kaizen 5Read about Gemba http://en.wikipedia.org/wiki/Gemba 6JUDE is a visual software design tool which integrates UML, ERD, DFD, and mind mapping. See http://jude.change-vision.com/ for more information. 7Yamaha Motors have a hardware production line, and their software teams are in a good environment to learn lean thinking from their factories. During my visit to their company, I saw a lot of XFDs (extreme feedback devices) for project visualization in their facilities, paralleling the Andon or visual management systems of their factories. 8It is not essential but interesting to know that the red boxes (processes) are off-shored to China. 9Read about Just-In-Time http://www.toyota.co.jp/en/vision/production_system/just.html 10Read about Jidoka http://www.toyota.co.jp/en/vision/production_system/jidoka.html 11Read about TRICHORD http://trichord.change-vision.com/
5 comments
Watch Thread Reply Great article, minor typo by Jason Yip Posted Jan 15, 2008 2:53 PM Kanbans work great for agile teams by Nicholas Cancelliere Posted Jan 15, 2008 3:39 PM
9/28/2011
Page 19 of 21
Re: Kanbans work great for agile teams by Joshua Ewer Posted Aug 11, 2009 3:02 PM Re: Kanbans work great for agile teams by David David Posted Mar 2, 2011 1:41 PM Online Kanban Tools by Sergei Podbereschi Posted Mar 11, 2011 7:47 AM Sort by date descending 1. Back to top Great article, minor typo Jan 15, 2008 2:53 PM by Jason Yip In the conclusion paragraph, I assume that should be analysed (or analyzed). Also, I think in the latest version of The Machine That Changed the World, it claims that Taiichi Ohno learning kanban from an American supermarket is an urban myth. Apparently, he observed this from an American style supermarket in Japan. Im also thinking that the difference in kanban styles can be more attributed to the levels of specialisation/hand-offs in the system rather than the type of development (50 vs 90%). Reply 2. Back to top Kanbans work great for agile teams Jan 15, 2008 3:39 PM by Nicholas Cancelliere I have had a problem with teams relying too much on web-based tools and email. Team members would interact with these tools more than one another. At some point you hear comments like Didnt you see my note on the web site, or I didnt see your email on that. Information in web-based tools or email is easily lost or ignored. They can provide excuses for not communicating responsibly. Kanbans keep a simple view of what needs to get done in front of the whole team. They are very visible and their tactile nature helps clue you in to changes as the board physically appears different. You can also see where work is piling up in a way you cannot appreciate through most web-based tools or by email. Teams are less apt to have too many in-progress tasks open, it becomes quickly apparent when this happens. The team that has switched off the web-based tools and adopted a kanban has seen improvements in collaboration and has demonstrated better self-control in taking on too many tasks at once. It has worked wonderfully. Not every team can utilize them, especially those with members in different physical locations, but if a team is all in one location I highly recommend them.
9/28/2011
Page 20 of 21
Reply 3. Back to top Re: Kanbans work great for agile teams Aug 11, 2009 3:02 PM by Joshua Ewer Completely agree. I had issues introducing Scrum to a team that had done agile (i.e. they had standup meetings). We have MS Team Foundation Server holding all of our work items and scenarios, which is nice, but that tooling completely abstracted how items should flow through a process and ended up being a detriment. A physical board, while seeming really low-tech, is the perfect way to illustrate the health of a project and keep people on task. I dont know how Id do it w/ a team that wasnt co-located, but once we saw it done once physically, then we re-introduced tooling which much more success. Reply 4. Back to top Re: Kanbans work great for agile teams Mar 2, 2011 1:41 PM by David David Good article, thanks. I started using kanbantool.com after I first heard about Kanban for personal use. Then my manager decided to test it within our company. People were delighted at first, productivity increased but after 2 weeks started problems with task limits. Some people were overloaded. Our managed decided to the same limit for everyone-and now everything works smoothly. Reply 5. Back to top Online Kanban Tools Mar 11, 2011 7:47 AM by Sergei Podbereschi For an online Kanban app, I would recommend checking smartQ www.getsmartQ.com. Kanban has a potential to be applied not only to software development, but to many other industries from marketing and HR to service shops. Leave Your Response Name (required) Mail (will not be published) (required)
9/28/2011
Page 21 of 21
Website
Submit Comment
Recent Posts
ASP.NET HyperLink in GridView using HyperLinkField, SqlDataSource, BoundField, TemplateField, and HyperLink IT Solutions : Network Monitoring ASP.NET Server Content Caching Unhandled exceptions cause ASP.NET-based applications to unexpectedly quit in the .NET Framework 2.0 PowerShell : Notes God Mode in Windows 7 Is it really doing godly things? Exposing Web Services to Client Script Auto save Asp.net form values Asynchronously Detecting Session Timeout and Redirect to Login Page in ASP.NET Removing empty spaces and HTML tags from TextBox text on client side
Meta
Log in Switch to our mobile site
9/28/2011

S Menon's Blog: Enter Keywords..

Transféré par

Informations du document

Description originale:

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

S Menon's Blog: Enter Keywords..

Transféré par

Droits d'auteur :

Formats disponibles

Kanban Applied to Software Development: from Agile to Lean | S Menon's Blog

Kanban Applied to Software Development: from Agile to Lean

Posted by Kenji Hiranabe on http://www.infoq.com/articles/hiranabe-lean-agile-kanban dated Jan 14, 2008

Kanban Applied to Software Development: from Agile to Lean | S Menon's Blog

What is Kanban in TPS?

Kanban Applied to Software Development: from Agile to Lean | S Menon's Blog

Kanban Applied to Software Development: from Agile to Lean | S Menon's Blog

Kanban Applied to Software Development: from Agile to Lean | S Menon's Blog

Kanban Applied to Software Development: from Agile to Lean | S Menon's Blog

Kanban Applied to Software Development: from Agile to Lean | S Menon's Blog

Kanban in Software Development

Kanban Applied to Software Development: from Agile to Lean | S Menon's Blog

Kanban Applied to Software Development: from Agile to Lean | S Menon's Blog

Kanban Applied to Software Development: from Agile to Lean | S Menon's Blog

Kanban Applied to Software Development: from Agile to Lean | S Menon's Blog

Production and Development

Kanban Applied to Software Development: from Agile to Lean | S Menon's Blog

Kanban Applied to Software Development: from Agile to Lean | S Menon's Blog

Figure 9 Properties and Effects of Kanban (2)

Kanban Applied to Software Development: from Agile to Lean | S Menon's Blog

Figure 10 Spectrums of Approach using Kanban

KSSE Kanban System for Sustaining Engineering

Make value flow

Kanban Applied to Software Development: from Agile to Lean | S Menon's Blog

TPS, the Big Picture

Kanban Applied to Software Development: from Agile to Lean | S Menon's Blog

Kanban Applied to Software Development: from Agile to Lean | S Menon's Blog

About the Author

Kanban Applied to Software Development: from Agile to Lean | S Menon's Blog

Kanban Applied to Software Development: from Agile to Lean | S Menon's Blog

Kanban Applied to Software Development: from Agile to Lean | S Menon's Blog

Kanban Applied to Software Development: from Agile to Lean | S Menon's Blog

Vous aimerez peut-être aussi