Kanban and Systems Thinking

Systems Thinking

The original Agile methods were created by teams independently in response to the challenge of improving software development and their documentation as a named process was a subsequent codification in order to help spread the learning and improvement wider throughout the industry. Either consciously or intuitively, these processes were applications of Systems Thinking, taking a holistic approach to solve the problem at hand. Taken in this context we can learn from Agile methods by treating them as system archetypes rather than repeatable solutions, and design our own systems to create the same results.

System Structure

Systems Thinking suggests that systems are made up of elements, which interact, to meet a purpose. In other words, they are more than the sum of the parts.

  • A system’s purpose is what ultimately determines its behaviour. In fact a system’s purpose can be often deduced from its behaviour which is observed over time rather than through individual events. A generic purpose for product development might be to deliver value through achieving flow and building capability.
  • A system’s elements are the things that it is made up of and these can be either tangible or intangible. Tangible elements of a product development system could include the people, physical resources (e.g. hardware and furniture) and artefacts (e.g. specifications and tests). Intangible elements could include the software itself (both product and tests), software tools (e.g. compilers and editors), skills and morale.
  • A system’s interactions are the relationships that hold its elements together. They can typically be a flow of energy, material or information. For product development systems, the most relevant interactions often take the form of information flows. This might be information about learning (e.g. success or failure), state changes (e.g. ready or done) or decisions (e.g. accepted or rejected).

System Archetypes

A system can also be described in terms of stocks and flows. A stock is a recognisable and measurable part of the system, and the flows are what cause the stock to rise and fall over time. Thus, the stock at any given time is the result of the all the preceding flows in and out of the system.  The stock acts as a buffer for the flows, which can create stability and allow for variability by decoupling the flows. However, it can also cause delays which may cause instability. In a product development system, if we think of the stock as the Work in Process (WIP), we can see that some WIP will create stability, but too much will create undesirable delays.

Describing systems in terms of stocks and flows leads to the understanding of feedback in systems. Feedback is created when changes in a stock affect the flows into or out of that same stock. Feedback can either balance and stabilise, or reinforce and amplify a system’s behaviour and combinations of feedback structures result in a system’s behaviour being constant over time. The patterns which cause similar and recognisable system behaviour are known as system archetypes.

Kanban Systems

These basic Systems Thinking concepts give us a clue to how we can help meet the challenges of improving our product development practices without codifying methods. Having clarity of purpose, and the way elements interact to achieve that purpose, can give us insight into intervention points for continuously improving.

System archetypes give us a further perspective with which to view our product development processes, and suggests the role Kanban plays. If Agile processes are examples of a system archetype, then Kanban provides an approach to creating further examples of those system archetypes. Workflow can be thought of as part of the system structure. Visualisation can highlight key elements and interactions. Limiting WIP can manage the stock. Cadence can co-ordinate of elements and interactions. Learning can focus on improving the system.  Further, where processes are exhibiting less desirable archetypes, then Kanban provides an approach to recognise, visualise and eventually break them.

It should be remembered though that systems area non-linear in that there not a simple cause and effect relationship. That is why behaviour should be measured over time rather than looking at individual events. As Donella H. Meadows so eloquently put it in her book ‘Thinking in Systems: A Primer’, “The future can’t be predicted, but it can be envisioned and brought lovingly into being” and “We can’t control systems or figure them out. But we can dance with them!”

8 Comments

  1. Hi Karl,

    I’ve been doing Kanban for a couple of years and started studying Systems Thinking this year. I’m looking for more sources about Systems Theory applied for software development and this is quite hard to find.

    I’m trying to fit System Thinking to a wider view on IT. Surely WIP is a Stock, but what about the market needs, support requests, technical debts, technology obsolescence and many others? One challenging issue applying Systems Thinking on IT are these highly abstract Stocks. Some of them unmeasurable. Something us to think about.

    Systems Thinking is all about holistic view. Kanban can explain a lot about the value chain it maps (an inside system), but I see more value on exploring “the market system”, including the impact off the software on it.

    (putting things this way can show us that many many projects we build are harmful to the market system itself)

    Anyway, I see that software development can benefit a lot from this theory. I see that Kanban follows Meadows’ “stop blaming” advice. The system behaviour sometimes is caused by the system itself.

    Rodrigo Yoshima
    ASPERCOM
    Brazil

    1. Hi Rodrigo,

      Systems are hierarchical, and are always parts of other systems. So yes, the development system is part of some larger business system, which is parts another larger market system. We shouldn’t forget this. Thanks for the reminder.

      Karl

  2. Hey Key, This is a great entry. Thanks! I am glad to see
    other folks are also looking at Kanban from different perspectives.
    I got more appreciation (and understanding) of Kanban once I read
    more about Systems Thinking, ToC and Replenishment. Cheers,
    Paulo

  3. Great post. For a fantastic discussion of systems thinking as applied to software development check out ‘Quality Software Management: Systems Thinking’ by Gerald Weinberg http://amzn.to/dIlF40. It was published was back in ’91, but still an excellent resource.

  4. Bill, thanks for sharing that link. Will look into that book.

  5. Hi Karl,

    Would you agree that there are pre-requisites to becoming a system designer and applying system thinking from first principles yourself?

    If so, what are they?

    Regards,

    Paul.

    1. Hi Paul,
      There probably are pre-requisites, but I’m not sure they are anything special. For example a knowledge of systems thinking concepts and a willingness to experiment and learn. Did you have anything particular in mind?
      Karl

  6. Thanks for sharing that Bill.

Comments are closed.