• Kanban and Agile Software Development — Part 2

    Where we left off

    In the introductory Kanban post, I provided some background on Kanban in order to give you some context for how Kanban might be used in an agile software development environment. Now I want to provide some insight on how Kanban is currently being used with agile and why I think the idea of doing so holds some merit.

    In Part 1, I mentioned that Kanban and Agile share some basic tenets: improve efficiencies in a non-prescriptive environment where rules are kept to a minimum. I also said that at the very least, incorporating Kanban into an agile environment by combining rules 5 and 6 of Toyota’s Production System (TPS) seemed to make the most sense. In other words, using Kanban as a means for fine tuning in order to stabilize and rationalize the process could bring a lot to the table in an agile software environment.

    Let’s take a look at some of the ways it’s been done so far.

    How has Kanban been implemented in an agile software environment?

    In his article, Kanban Applied to Software Development: from Agile to Lean, Kenji Hiranabe discusses several ways Agile and Kanban have been put into practice, including:

    • Agile Kanban
    • Sustaining Kanban
    • Lean + Agile Kanban
    • Portable Agile Kanban
    Agile Kanban

    Hiranbe equates Agile Kanban to ‘Task Kanban’ in that, like Agile, it doesn’t show processes, such as Development, Testing and Deployment, but instead relies only on visual cues that show the status of a story, such as To Do, Doing and Done. He uses this photo of a Task Kanban implemented by the JUDE development team at Change Vision, Inc. to illustrate:

    Agile Kanban Board

    Agile Kanban Board

    Sustaining Kanban

    Unlike Agile or Task Kanban, Sustaining Kanban has separate and serial processes (Development, Testing, etc.) and the Kanban cards move between those processes from left to right, as shown in this example, a pieced-together image of Yahoo’s Kanban system from Jeff Patton in his article, Kanban Development Oversimplified.

    Sustaining Kanban Board

    Sustaining Kanban Board

    How Yahoo’s Kanban board works:

    • The circled numbers along the bottom are the number of stories allowed in the corresponding column.
    • The boxed numbers in the left column represent an approximate wait time in days, so items at the bottom will have a slightly longer wait time than those higher up on the board.
    • Stories start on the left side and move to the right across the board as they progress through various phases of development. Those in the top row are in progress. As they complete a phase and move to the right, stories below them are moved up.

    Although at first glance you might think otherwise, Hiranbe explains, “Sustaining Kanban 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.”

    Using the Yahoo example, you can clearly see the “flow of work” concept used in Sustaining Kanban is different from the “iteration” concept of agile. And, in order to be a true ‘pull’ system, rules would need to require that only the next group to the right is allowed to move the cards on the board.

    Lean+Agile Kanban

    Hiranbe describes Lean+Agile Kanban like using Agile Kanban synchronously within each process and using Sustaining Kanban asynchronously across the whole value stream of processes


    Patton also found a smaller “portable” Kanban system he in a project being developed by Central Computer Services, Co. At Central, a team works in several smaller sub teams (usually pairs). When a sub-team pulls a user story, they break it down into their tasks and post them onto their own portable Kanban board (in this case, a bulletin board they can carry with them).

    Kanban Nano

    Kanban Nano

    In Central’s case, the Kanban system consists of two levels:

    • A project level in which a card represents a user story.
    • A team (or a pair) level where a card represents a task.

    Central uses the term ‘Kanban-nano’ to refer to its agile-Kanban system.

    It’s just another way to be agile!

    The idea of using a simple task board with index cards or sticky notes is as old as Agile itself.

    Even after seeing only a few styles of Kanban in place for agile software development, it’s certainly not a stretch to imagine other variations that could be used in order to create hybrid agile-Kanban systems. One example is Scrumban, fully discussed by Corey Ladas in his 2008 paper, in which he describes Scrumban as “Incrementally enhancing Scrum with more and more pull-like features.” In doing so, Ladas says, flow becomes smoother as process capability improves, providing opportunities for kaizen.

    The beauty of the Kanban system: it’s very visual. If logjams occur they’re obvious and action can be taken to address them.

    Over time, the process of improving the system is considered ‘smoothing’ or production leveling, and is sometimes referred to in production as “heijunka”. It’s a technique for reducing waste and is an important part of the production efficiency in the TPS and in lean manufacturing in general.

    So, at least to this point, you might agree as I said in part 1:

    “At the very least, incorporating Kanban into an Agile environment by combining rules 5 and 6 of the TPS seems to make a lot of sense, i.e., using Kanban is a means to fine tuning in order to stabilize and rationalize the process.”

    But what are the tradeoffs?

    Phew, that’s enough to read for now. In Part 3, I’ll discuss some of the tradeoffs that might occur and if bringing Kanban into an agile environment necessarily means we lose the collaboration between teams with different perspectives, a very important part of product development in my mind.

    I’ll also provide some additional resources you can use to find more information on using Kanban in an agile environment.

  • Kanban and Agile Software Development — Part 1

    I’ve never made it a secret that I am a fan of agile management practices, both inside and outside of software development.  Historically, however, two things within the agile space have always been a little bit frustrating to me:

    1. First, folks too often view different flavors of agile as competitive instead of complementary.  I hear questions like, “What’s better?  Scrum or XP?”
    2. Secondly, there aren’t that many great resources for learning about the practical reality of implementing agile within an organization.

    I have heard about Kanban systems applied to software development for a while now, but mostly through conversations with other agile practitioners. After doing some research, I’ve found that there were not many resources on the internet about Kanban and how it is used in agile development.  So I decided to pull something together here and use it as a basis for further discussion.

    Kanban’s origins and use as a JIT manufacturing tool

    First, what exactly is Kanban?

    The word kanban is Japanese. Roughly translated, it means ‘signboard’, ‘billboard’ or ‘card you can see.’ In its original usage in 17th century Japan, Kanban was a wooden or metal sign often used to represent a trademark or seal.

    In more modern times, however, Kanban became a term used in Just-in-time (JIT) manufacturing systems that seek to reduce in-process inventory and its associated carrying costs, most notably by Toyota. Thus the concept of Just-in-time manufacturing has also become known as the Toyota Production System (TPS).

    JIT or TPS is a lean, pull system of production. American manufacturing has traditionally been based on a push system where the manufacturer estimates the quantity of product it must produce in order to meet forecast demand. A push system can result in either a shortage or surplus of materials needed for production depending on the accuracy of that forecast.

    Conversely, pull systems like those used in the TPS rely on observed and not forecast demand. Signals at different points in the process are used to determine when more parts are needed. To illustrate the concept simply, imagine a parts bin on the factory floor with a Kanban card (signal) inside that carries part identification. When the bin is empty, the bin and the card are taken to the factory’s store for replacement. The factory store replaces the empty bin with a full one containing its own Kanban card. The factory store then presents the empty bin and its Kanban card to the appropriate step in the supply chain for replenishment.

    In such a system, as long as there is one spare in the factory store, the process will never run out of needed parts and supply costs are only incurred when they’re actually necessary.  While it may not seem revolutionary at first blush, it turns out that it is.  This subtle shift in thinking can have a dramatic impact on efficiency and waste.

    The general flow of Kanban would look something like this:

    Kanban Process Simplified

    Courtesy of leanandkanban.wordpress.com

    OK, so software development isn’t manufacturing

    By now, you’re probably thinking:

    “This is all well and good in a factory production line, which is a very linear process where the product moves from one assembly stage to another in orderly fashion and once the product moves form point A to point B, it doesn’t come back (provided quality is satisfactory when it arrives at point B). But software development doesn’t always operate in a linear process.”

    It’s true that flow is often non-linear with software development. It’s not always a clean handoff from elaboration to development to testing.  Sometimes design and development are happening in parallel, for example. Plus, we’re talking about labor and not physical, raw materials.

    However, Kanban is in use in lean non-manufacturing environments and, in fact, Kanban has already been adopted in some agile software development environments. That’s likely because Kanban is relatively easy to adapt to specific environments because there aren’t a lot of rules.

    The 6 rules of Kanban and the TPS implementation of Kanban

    Kenji Hiranabe1 succinctly lists the rules of Kanban as:

    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.

    And, in fact, Toyota’s TPS itself has only six very simple rules:1.

    1. Do not send defective products to the subsequent process.
    2. The subsequent process comes to withdraw only what is needed.
    3. Produce only the exact quantity withdrawn by the subsequent process.
    4. Equalize production.
    5. Kanban is a means to fine tuning.
    6. Stabilize and rationalize the process.

    In non-manufacturing environments, the primary purpose of Kanban is to facilitate efficient workflow. In manufacturing it’s about having the right part in the right quantity at the right time. This is as opposed to producing based on guesswork and estimation.  It’s about being lean. Very lean.

    Can agile and Kanban coexist happily?

    The real question then, is “Does Kanban conflict with Agile concepts/principles?”
    The best answer might be, “In some ways, maybe. In some ways, maybe not.”

    Over the last several years a large number of Agile practitioners have begun to include thinking from lean manufacturing in their Agile approaches, thanks to trailblazers like Tom & Mary Poppendiek in their book Lean Software Development. But Kanban, at least as discussed thus far, seems to break the primary rule of today’s common agile practice: the fixed development time-box. Kanban systems are continuous, not iterative, yet both exist to promote workflow efficiency.

    In his article, Kanban Development Oversimplified, Jeff Patton illustrates some of the conflicts between Agile and Kanban. With Kanban development:

    • Time-boxed development is out
    • Stories are larger and fewer
    • Estimation is optional or out completely
    • Velocity is replaced by cycle time

    Implementing Kanban in an Agile environment might require a bit of ‘shoehorning’ to make it work. But Kanban and Agile share some basic tenets: improve efficiencies in a non-prescriptive environment where rules are kept to a minimum.  In this way, they certainly seem complementary.

    At the very least, incorporating Kanban into an Agile environment by combining rules 5 and 6 of the TPS seems to make a lot of sense, i.e., using Kanban is a means to fine tuning in order to stabilize and rationalize the process. And, just as Agile has evolved into several different flavors over time, like XP and Scrum, it’s not a stretch to imagine Agile-Kanban hybrids like Scrum-ban just might create a synergy for software development that neither could achieve on its own.

    Where do we go from here?

    I’ve laid the groundwork by providing some context on the possibility of using Kanban in an Agile software development environment. Just as I think different forms of Agile shouldn’t be seen as conflicting but as complementary, I also think it’s important to keep an open mind and consider that Kanban and Agile have the potential to be complementary and not contradictory.  The subtle shift in lean thinking turned out to be revolutionary in classical production, and it may just have a significant impact in the world of agile as well.

    In Part 2 I’ll take a look at how Kanban is currently being adopted in Agile environments and the key tradeoffs that might result.

  • How to know what is worth fighting for

    Effectively managing conflict in the workplace has been a topic on my mind for some time now.   Having a new topic on your mind is kind of like buying a new car; you start to notice it everywhere.  Now that I am thinking about effectively managing conflict, I am starting to see conflict or opportunities for healthy conflict everywhere.  One of the most challenging things for one to think through as they try to create a healthy conflict culture is figuring out exactly what is worth ‘fighting over’ and what isn’t.

    One has to be careful not to let the pendulum swing too far in the other direction, and turn everything into a ‘fighting moment.’  It’s very easy to get ‘caught up’ in disagreements about all sorts of details that aren’t worth the time.  That’s not the kind of culture anyone wants to create.  Healthy conflict has to be effectively separated from petty conflict.

    Three tests to figure out what topics are worth fighting for

    So far, based on my reading and studying of the subject, there are three tests that a topic can pass to be worth engaging in healthy debate and conflict over:

    • Does a successful outcome create value for the organization?
    • Is the nature of the problem multi-dimensional, and not simply a matter of expertise/lack-of-information?
    • Will driving to a decision with multiple perspectives at the table create lasting change?

    Three types of thinking

    The second bullet is perhaps the hardest one to figure out.  I think that Dr. Saj-nicole Joni describes the concept pretty well in her book titled “The Third Opinion.”  She describes three types of thinking:

    • Application thinking: This is basic thinking that involves known problems and solutions.  Imagine reading a how-to manual to solve a printer problem.
    • Expert thinking: This is more complex specialized thinking that requires expert help.  Perhaps the printer has a broken part that needs repaired.
    • Exponential thinking: This is for complex problems that don’t necessarily have simple right answers.  Typically, multiple perspectives will help create a better answer.  Perhaps our goal is now to design a better printer.

    The key to finding the right problems lays in exponential thinking.  The first two types of problems are typically too simple to try and bring multiple perspectives to the table on.  Also, there is likely to be one right answer that is simply a matter of knowledge or expertise.

    It all takes energy

    The key takeaway for me here is that conflict takes energy and time.  For most of us (especially me) it has a sapping effect.  I don’t necessarily love conflict, and I suspect that I am not alone.  So it’s important to find the right balance of it, and it’s even more important to do it for the right reasons.  While no acid test is perfect, the one above has been pretty effective for me so far!