Kanban Applied to Software Development: from Agile to Lean

Abstract

A Kanban¹ 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?

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 ² discussion list. Finally, I give a big picture of TPS, the original context for which Kanban's 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.

Kanban's 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.

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 doesn't "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 ³" - 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.
• 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. Let's 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.

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 ⁴ (process improvement) in the Gemba ⁵ (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. Physical: It is a physical card. It can be held in the hand, moved, and put into or onto something.
2. Limits WIP: It limits WIP (Work-In-Process), i.e. prevents overproduction.
3. Continuous Flow: It notifies needs of production before the store runs out of stock.
4. Pull: The downstream process pulls items from the upstream process.
5. Self-Directing: It has all information on what to do and makes production autonomous in a non-centralized manner and without micro-management.
6. Visual: It is stacked or posted to show the current status and progress, visually.
7. Signal: Its visual status signals the next withdrawal or production actions.
8. Kaizen: Visual process flow informs and stimulates Kaizen.
9. 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 you'll see here, there are roughly two different meanings of Kanban, one is "Limits WIP while sustaining Continuous Flow", and the other is "Kaizen".

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".

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 process's 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 graph's 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, let's 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 Task Kanban implemented by the JUDE ⁶ 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 person's 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 ⁷.

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 one-piece-flow of manufacturing. What's happening here is a stable "sustaining" phase in a product‘s 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 ⁸. I call this "Sustaining Kanban", and find it similar to David Anderson's "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].

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 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 doesn't 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 today's 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, let's 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 we've described.

"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 "Self-directing," 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 Shannon's 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 system's "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.

Figure 9 Properties and Effects of Kanban (2)

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 ², 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 doesn't 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

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 let's 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 Shook's version [Narusawa06]. In TPS, Kanban is just a device for a "pull system" to realize Just-In-Time ⁹. 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 ¹⁰. "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 rule but almost the culture of Toyota, which can be traced back to Sakichi Toyoda's 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.

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 Hartmann's 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 ¹¹, 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, Addison-Wesley. 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 Addison-Wesley. The first classic of drawing lines between TPS and software development.
• [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".