Daycare As A Kanban System

I was discussing my two year old son’s daycare with my wife, yesterday, when it dawned on me that the daycare itself can be viewed as a Kanban system. A Kanban system is a system level process control system that limits the work in process (WIP), authorizes work to be done based on capacity, and pulls work through the system.

Variability In The System

A daycare system is a highly variable system. The rate of arrival and departure in this system is not constant and there is no guarantee of linear progress through the system. A child may be taken out of the system at any time, whether or not they have been processed through the entire system.

What I’m trying to show is how a highly variable system, such as daycare, ban be viewed and run as a Kanban system. We don’t need a perfectly repeatable set of steps with perfectly stable cycle times like the manufacturing world. We can deal with highly variable input and output using Kanban. It doesn’t matter if we are talking about children in daycare, about software being developed or about parts being manufactured. The Kanban process is applicable because it does not care what your system is or how value is added to the work. Kanban just wants to help coordinate the flow of work through the system through some simple techniques like limiting WIP, queues, and pull.

So how does daycare translate into a Kanban system?

The System and Process

The system that we are working in, in this case, is designed to educate children and help them grow into socially acceptable human beings while also providing a way for the parents to continue working. This is obviously an oversimplification of what a daycare is and what it does, but it provides a simple framework for us to use.

The Steps in the Process

Each classroom can be considered a step in the daycare process. There are multiple classrooms in my son’s daycare – different rooms for different age groups and growth of the children. Class A1 is for infants. Class A2 is for children that are crawling and eating real food. Class A3 is for children that are walking and starting to talk; etc. etc.

image image

The Work In Process

The children in the daycare are the work in process (WIP). When we first sent our son to daycare, he was in class A1. Now he’s in class A3 and he was previously in A2. Next, he’ll be moving on to A4.


The begin state and end state that determines when a child is ready to transfer from one class to the next is not based on a schedule. Rather, it is based on when the child has developed the skills needed to handle the activities of the next room. One child may learn to walk and talk by the age of 1; and another child may not learn to walk until they are 2, and talk at the age of 3. The child’s development the primary determining factor for when they are ready move into the next class.

There is another factor of variability in this system – the development state of the child when they enter the system. If a child is already walking and talking when they have entered the daycare for the first time, they will not be placed in the A1 infant room. Rather, they will be placed into the queue for the classroom that is appropriate for their developmental needs.

The Queues and WIP Limits

Backlog: The Waiting List

The first queue that our son had to wait in was the system’s backlog. This truly was a backlog – we were on this waiting list for nearly a year before our son got into this daycare. Fortunately, we had put him on the waiting list 6 months prior to his birth so it only took six months to get him in.


The interesting part about the waiting list is how it’s managed. This is primarily a first-in-first-out (FIFO) queue. That is, the order in which you register your child on the waiting list is generally the order in which you get pulled into the system. However, there are other prioritization factors that also come into play. For example, if you have a child already in this daycare, you get prioritized over the children who do not have siblings in the daycare. Therefore, this is a prioritized FIFO queue. Furthermore, the parents of the children have the option of taking their children out of the queue at any point in time. They can say “no thanks” to the daycare and be removed from the waiting list at any time. The parents may have found another daycare, a nanny, moved away, or decided to stay at home with the kids. There are a number of possible reasons for a child to be removed from this queue.

WIP Limit and Ready To Transfer Queue:

After a child has matured to a certain point, the classroom that they are in will promote them to the next room. The next room will have a different structure of activities based on the maturity of children in that room. However, just because a child is ready to transfer doesn’t mean that they get to transfer immediately. The child that is ready to transfer can only transfer when the next classroom has space available – when it has the capacity to process the child. When the next classroom does not have space available, the child will be placed into a virtual queue – a “ready to transfer” state – waiting for capacity to become available in the next room. The child does not physically move to this queue. They are still in the current classroom, but are marked as “ready to transfer” in the daycare’s records.


Pulling Value Through The System

Once the next room has space available, the child will be pulled from the transfer queue into the new room. The WIP limit of classroom capacity, combined with the Queues of waiting to transfer, is what sets the daycare system up as a Kanban process. 


The movement of children through the classrooms only happens when a downstream process (classroom) says that they have capacity. Let’s say A3 is the last class in the daycare before the children are ready for kindergarten. Once a child is promoted to kindergarten – which happens every August – A3 will have capacity. At that time, a child in the “Ready To Transfer” queue of class A2, will be pulled into class A3. One this occurs, capacity will be freed up in class A2, which allows them to pull a child from A1’s “Ready To Transfer” queue. When A1 has capacity, they can pull a child out of the Waiting List queue.

Once again, there are other methods of capacity becoming available for this system, though. A new class may be opened, with additional teachers. This would allow the children to transfer from the A-Series classrooms to the B-Series classrooms, for example. When this transfer occurs, based on who is ready to transfer, capacity becomes available. The parents also have the option of taking their child out of this daycare system at any time, too. If the parents move, find other arrangements for care, or for any other reason that they deem fit, they always have the option of taking their child out. This also frees up capacity for another child to be pulled into that classroom.

Reading Right To Left

Remember that a ‘kanban’ (lowercase k) is just a signal to do work and a Kanban system (capital K) is a WIP limited, pull-based flow of work through a system. We then look at authorizing work based on capacity, not scheduling. The work to be done is pulled from right to left, therefore we read the process from right to left.


  1. Finished work put into Step 2’s “done” queue
  2. Next set of available parts pulled into Step 2
  3. Step 2 signals Step 1 that work needs to be done
  4. Finished parts pulled from Step 1 into Step 1 “done” queue
  5. Repeat from #1

Viewing The Daycare System As A Kanban System

Keeping the right-to-left nature of a Kanban flow of work in mind, we can view the entire daycare system as the process to flow through, the individual classrooms as the steps in the process, and the children as the raw material that value is being added to. We can set WIP limits in the classrooms and queue for the classroom, and we can pull the children through the system, as capacity becomes available in the classrooms.


Variability and Kanban

A Kanban system is applicable to more than just standardized, constant time work that is found in the manufacturing world. Variability in the system, in the WIP itself, in the stages or steps that the WIP flows through, or any other part of the system have very little impact on whether or not a Kanban system is viable. Quite the opposite is true in my experience. It seems that the more variance a system has the more likely it will benefit from a Kanban or other pull-based system.  A daycare system almost has no pre-determined list of steps to follow, with varying points of entry and exit, and has varying cycle times and lead times at all levels based on the individual child’s needs. If such a highly variable system can be managed so well by Kanban, and if such a controlled and predictable system like manufacturing can be managed so well with Kanban, then what excuse do we have in software development to say that we are special or different and Kanban can’t apply to us? That doesn’t mean everyone should use Kanban for every situation. Rather, it means that Kanban is a viable system to use and we should at least be familiar with what it provides and what is solves, so that we can determine when and where it is appropriate to use.

About Derick Bailey

Derick Bailey is an entrepreneur, problem solver (and creator? :P ), software developer, screecaster, writer, blogger, speaker and technology leader in central Texas (north of Austin). He runs - the amazingly awesome podcast audio hosting service that everyone should be using, and where he throws down the JavaScript gauntlets to get you up to speed. He has been a professional software developer since the late 90's, and has been writing code since the late 80's. Find me on twitter: @derickbailey, @mutedsolutions, @backbonejsclass Find me on the web: SignalLeaf, WatchMeCode, Kendo UI blog, MarionetteJS, My Github profile, On Google+.
This entry was posted in Kanban, Management, Throughput, Workflow. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • This is an awesome post – thanks. I’m learning about Kanban (and kanban) and seeing it in this context, with your additional widsom injected, is really useful.

    It’s cool that Kanban is so well suited to variability, it definately feels like a fluid, self-optimising way of doing things. I’m work a tiny 2-8 man teams, I’d like to think it could add value there too.

    There’s a few things I struggle with (in general with Kanban) – can you suggest any articles to address these questions…?

    1. How do you handle different types of work item co-existing in you Kanban system (user stories, issues, bugs, todo items etc)?

    2. Can work items move _backwards_ (from A2 to A1)?

  • P.S – I love you’re Kanban diagrams – what do you do them in? I’m tempted to try creating a Kanban diagram type for :)

  • @Tobin,

    thanks! Glad to know my post was useful. :)

    the good news is, Kanban doesn’t care about your team size. I typically work in teams of the same size as you, and have had tremendous success with Kanban.

    the great news is, Kanban doesn’t care what your current process for handling stories vs. bugs vs. anything else is. Kanban is a process control system that will sit on top of the way you currently work those items. What Kanban asks you to do, is identify the process that you use in some explicit form (usually a visual task board) and limit the WIP. This will naturally lead you to pulling the work items through the system, based on the capacity of the steps in the system.

    Although it’s more difficult to visually model a non-linear workflow, it’s not terribly difficult. The process in our current team often involves sending a ticket from A2 back to A1 for rework (we missed a requirement, got it wrong, or had a bug in the system). There are many different ways of handling this, and it’s more a question of how does your team currently handle this, than anything else. My current team posts red sticky notes on the story/task card, to say that this ticket is blocked from moving forward. the red sticky note then has a short description of what is blocking the card. once the blocking issue is resolved, the sticky note comes off and the card is allowed to move forward. I’ve handled this in other ways, in the past, too. It really does come down to how your team works, and modeling that into an explicit form.

    i do all my diagrams in PowerPoint 2007, of all things. It’s fast and easy. draw a couple of boxes and apply a Format / Style to everything. :) … not sure how well this would fit into a diagram… but that could just be my own limited imagination. (by the way: love that site. i’ve played with it a few times… great stuff)

  • Thanks for the response Derick. That’s interesting about handling multiple items.

    My urge is to create different coloured “cards” on the board for different types of item (bugs, stories etc), and just drop them into the “Ready” swim lane and let them go with the flow from there.

    I just wondered that Kanban might prefer work items of similar size? I think I need to get closer to the basics of Kanban to get a real grip on this (I’ve read about 7 articles so far, with no real practice)

    Thanks for the advice on moving items back and forth – it’s nice that the rules are loose, and that Kanban is kind of a level above the actual process.

    PowerPoint 2007 – they look good! I hope you’ll be able to read through by smelly code and make yUML spit out something equally pretty!

  • JohnV

    I am still trying to learn kanban, both little k and Big K. But your example here seems different then most. Your WIP limits include the ready to transfer state. I wonder if you need another header across the top of a classroom, including class name and ready to transfer state, that shows the wip.

    In product development and software once a item is worked on and done/done it is ready for the next stage. And allows more input from the waiting queue.

    In writing this out I relized that the queue needs some type of wip limit or you will create a log jam. You will have inventory ready for the next stage just sitting there. So I guess sharing a wip limit shared like this is one way of handeling it.

    I guess maybe I am wrong but still would appreciate your thoughts on this.

  • @JohnV,

    the WIP limit for any given step is a combination of two things: the work being processed, and the work in the “done” queue for that step.

    the combination of these two numbers – the WIP limit for any given step – is also represented as the number of kanban (signals) for that step. If i had modeled this example using explicit kanban cards to say that a child was being moved from one class to another, then each of the classrooms (class + queue) would have three kanban cards.

    “In product development and software once a item is worked on and done/done it is ready for the next stage. And allows more input from the waiting queue.”

    I ran my previous project like this, actually. You can see the step and queue design in my previous “Kanban In Software Development” series (which has a lot of errors in it… i’ve learned a lot since then). What I’ve realized since then, is that this can lead to tasks being in an invalid state and over running our WIP limits.

    For example: let’s say Step1 has a WIP limit of 2 and Step1Done queue has a queue size of 3. if we have 3 tasks sitting in the Done column, then that Queue is full. what happens if one of the WIP items from Step1 completes before anything is moved from the queue? We end up with a task card that is “done” but stuck in the WIP column of Step1, because we have already maxed out our queue for Step1. If this card is “done” but unable to move into the “done” queue, then Step1′s WIP column has effectively become a queue. we’re now waiting for Step1Done queue to have an item moved so that we can move an item from Step1 WIP to Done queue.

    In this scenario, if Step1′s WIP becomes a queue, you effectively have a WIP limit in Step1 of 5, not 2 and 3 independently. Therefore, we should model the Step+Queue as a total WIP limit between them. A Header across the step + queue, like you suggested, would make this easier to see. that detail may not be terribly important, though. if the team understands that the WIP limit applies to the total of the Step + Queue, then placing the WIP limit in an location within those two is sufficient, as long as it’s in the same place for all of the steps.

    I hope that helps.

  • @Tobin,

    your colored cards idea is one that my team and i discussed, recently. we debated back and forth on what to do about the different types of tasks, and settled on the one i described above. i’ve heard of other teams doing what you are suggesting, with great success. once again it really does come down to the ability of your team to model the way you want to work.

    as for similar sized items – one of the points I was trying to make in this article, is that variance in the size of work item doesn’t really matter that much. Model your process the way it is, right now, and don’t worry about keeping things within a certain size range. As you start to see work flowing through your system, the variance in the size of work will have some natural effects, which should become visible on the task board. how you handle these effects (including the option to ignore them) is entirely up to you and your team. there are some standard ways of handling the effects, but i wouldn’t worry about these details when first starting out with kanban.

    in an emergent system like software development (and other product design/development), it’s far more important to be responsive to the situations and circumstances and be flexible enough to change your process when it needs to be changed, than to plan for every situation ahead of time.

  • Gabriel Schenker

    I really like your analogy! Whenever I have to explain something difficult or new or unusual(?) to somebody I like to show up analogies. This helps to see the pattern(s) or principle(s). Otherwise people most often get too focused on a specific case and think this is a solution just for THAT case. Congratulations.