Other high-performance IT delivery "models"

Lean, Agile, Kanban and Spotify are not always seen as models (rather as framework, mindset, etc.). However, because we aim to keep it simple, we call them all models.

In a nutshell, the description of Lean, Agile, Kanban and Spotify are as follows:

  • Lean is an organization-wide management philosophy that is focused on, among other things, the continual improvement of processes, where the elimination of waste contributes to the improvement.
  • Agile is a "mindset" for software development, based on the Agile Manifesto, in which the focus lies primarily on the generation of value for the business.
  • Kanban is a scheduling system for lean manufacturing and just-in-time manufacturing. In IT delivery it is an agile framework that makes the team focus on the throughput of the team, by making sure that nothing gets stuck and the team works together to resolve any activities that do get stuck.
  • Spotify engineering culture is the implementation and interpretation of the Scrum framework by media (music) services provider Spotify. They extended it with a.o. Squads, Tribes, Chapters and Guilds.


Lean manufacturing or lean production (or sometimes the Toyota Production System – TPS – although this represents more of a specific deployment of lean) is a management philosophy that is mainly directed towards the elimination of waste (in Japanese: Muda), objects and endeavors that do not produce added value [PLT, 2004]. The method is mainly known through its use by the Japanese car manufacturing firm Toyota. As a result of the "lean production", the quality of the product is enhanced while the costs decline, which leads to improvement in operational yields.

Lean has five basic principles:

  1. Value
    Let your client take center stage. What is the client willing to pay for? In other words, which activities are valuable to the client? The lean approach means that only that which is valuable to the client is produced.
  2. Value stream
    To distinguish between value to the client and waste, it is advisable to formulate a value stream. A value stream charts all the activities within a company, from client request to delivery, and for every activity it is specified whether this activity adds a certain value for the client. Improvements, in terms of your client, should be clear: minimize the steps that do not add value.
  3. Flow
    How do we do that? Flow is mainly about the way work moves through the value stream to create value, without coming to a standstill.
  4. Pull
    Setting business processes in motion has little significance if no one wants the products of these processes. It will only make sense to put the process chain in motion ("pull") when there is a client demand.
  5. Perfection
    Keep on trying to improve, strive for perfection. In this context, much use is made of the Kaizen (Japanese for "continual improvement") productivity-improvement approach. The central element here is the Plan-Do-Check-Act circle (refer to, "Continuous improvement").

Muri, Mura and Muda

In lean, three main categories have been named in which control may be lacking. All three begin with Mu: Muri (overburden), Mura (unevenness in the process) and Muda (waste). In lean, a distinction is made between eight different kinds of waste: faults, overproduction, transport, waiting, inventory, motion, over-processing, unused creativity and capacity.

Other principles that support Lean are the process of continuous improvement (Kaizen), the use of the "Just in Time" (JIT) principle, the Heijunka system to achieve production leveling in order to realize a more consistent flow in production, and a simple visual steering (5S) system. The 5S system seeks to create a tidy, well-organized and transparent "workplace":

Seiri Sorting
Seiton Straightening or Setting in order
Seisō Sweeping or Shining
Seiketsu Standardizing
Shitsuke Sustaining the practice



The Manifesto for Agile Software Development, in short, Agile Manifesto [Agile Manifesto, 2001], was compiled by seventeen software developers during a meeting in Utah in February 2001.

The aim of the meeting was to combine the trends toward lighter, more efficient software development methods that had been coming to the fore for quite some time, into a single approach that incorporates the best practices of the different methods. This approach was called "agile" because it advocated and adopted the flexibility that is needed in a changing world.

Agile Manifesto

The Agile Manifesto consists of four values and twelve principles.

The adherents of the Agile Manifesto hold the opinion that better ways of developing software can be uncovered by simply doing it and helping other people do it. Accordingly, they prefer:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiations
Responding to change over following a plan


Although they appreciate everything that has been stated on the right, they attach more value to the items listed on the left. In addition, they apply twelve Agile principles:

  • Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  • Welcome changing requirements, even when they arrive late in the development phase. Agile processes harness change for the customer's competitive advantage.
  • Deliver working software frequently, from a couple of weeks to a couple of months, with a preference for the shorter timescale.
  • Businesspeople and developers have to work together daily throughout the project.
  • Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done.
  • The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  • Working software is the primary measure of progress.
  • Agile processes promote sustainable development. The sponsors, developers and users should be able to maintain a constant pace indefinitely.
  • Continuous attention to technical excellence and good design enhances agility.
  • Simplicity, the art of maximizing the amount of work not done, is essential.
  • The best architectures, requirements and designs emerge from self-organizing teams.
  • The team regularly reflects on how to become more effective and attunes and adjusts its behavior accordingly.

Agile software development is a "mindset". The values in the manifesto are generic and do not state, in concrete terms, how things ought to be done. Based on the values, various aspects can be formulated upon which to found specific methods. These aspects are necessary in order to meet the values stated in the manifesto. For instance, if the focus lies on people and interaction, people will simply have to communicate intensively, to compensate for formal processes and procedures. In this way, team responsibility and trust can be traced back to the values declared in the manifesto. This is not a list with rules that can be ticked off one by one; instead, it demands more from the behavior and attitude – the mindset – of the people.


Kanban (signboard or billboard in Japanese) is an approach to incremental, evolutionary process and system changes for organizations. It uses visualization via a Kanban board of a list of work items. Kanban cards help create a demand-driven ("pull") system. It is based on the importance of limiting work in progress, which – as well as reducing waste due to multitasking and context switching – exposes system operation problems and stimulates collaboration to continuously improve the system.

Example Kanban board.


Spotify model

The Spotify model is based on the Scrum framework and consists of Squads, Tribes, Chapters and Guilds.

Spotify model.


  • Squad
    The basic unit of development at Spotify is the squad. A squad is like a Scrum team. The squad possesses all the skills and tools needed to design, develop, test, and release to production. It is a self-organizing team that decides on their own way of working – some use Scrum sprints, some use Kanban, some use a mix of these approaches.
  • Tribe
    A tribe is a collection of squads that work in related areas. The tribe has a certain degree of freedom and autonomy. Each tribe has a tribe lead who is responsible for providing the best possible environment for each squad within that tribe. Tribes should not contain much more than 100 people.
  • Chapter
    The chapter is a small group of people having similar skills within the same tribe. A chapter meets regularly to discuss their area of expertise and their specific challenges; a testing chapter, for example. The chapter lead is often not only the line manager for the chapter members, with all the traditional responsibilities; they are also part of the squad and involved in the daily work.
  • Guild
    A guild is a more organic "community of interest", a group of people that want to share knowledge, tools, code, and practices led by a "guild coordinator". Where chapters are always local to a tribe, guilds are not. For example, the tester guild includes all the testers in all testing chapters, but anybody who is interested can join.