Kaboom or Bust
How we applied Kanban and Obeya Principles to increase Transparency in our Military Unit
When you think about Kanban, Flow, and Obeya, a group of people wearing camouflage uniforms might not be the first thing that pops into your head. Following up on a learning from a past exercise, we ran an experiment using those tools & principles recently within the military unit I’m serving.
In this post, I’ll explain how this came to be, how well it worked, and what we learned from it.
But first, let’s explain shortly how I ended up serving in the military in the first place…
The post uses some military terms that I often hear only in German and that don’t translate well (because they are somewhat military-specific and not used anywhere else I’m aware of). I do my best to describe it, but occasionally I’ll also mention the German word (or abbreviation). Sadly there is no easy translator from “Military German” to “Military English”…
Military Service in Switzerland
In Switzerland, there is a militia system that spans from politics to the army and other areas. While some of it is voluntary, there is a mandatory obligation to join the Swiss Armed Forces or alternative services like civil service for every male Swiss citizen. This means, most units are made up of people that have regular occupations and are called up for military service at regular intervals. After basic training that lasts roughly 6 months and is done at around 20 years of age, you serve in a unit and spend roughly three weeks each year until you’ve served all the time you owe to the state. The number of days you owe depends on the rank - I’m a sergeant and have to serve a total of 400 days (25 days pending at the time of writing).
The National Emergency Operations Centre (NEOC)
The unit I serve in supports the National Emergency Operations Centre (short called “NEOC” or, in German, “NAZ”). The NEOC is a civil organization that is part of the Federal Office for Civil Protection (FOCP).
The main task of the NEOC consists in maintaining an overview of the situation which is relevant for protecting the population.
In the event of incidents involving radioactivity, major chemical accidents, dam ruptures and natural hazards, the NEOC takes on additional tasks. As far as radioactivity is concerned, the centre is authorised to implement immediate measures to protect the population.
Being a civil organization means that there are non-military people who have regular jobs at the NEOC. In case of a large-scale event (issues in nuclear power plants, earthquakes, etc.), they are supported by military staff:
NEOC has a personnel pool at its disposal consisting of well-trained, qualified specialists who are ready for deployment within four to six hours of an incident.
The military staff trains with the civil organization three times a year, to make sure that the processes and tools are well understood, as in case of an emergency, we have to be operational within hours.
Operations Unit / FGG3
The NEOC is split into various “departments” that have different responsibilities. For simplicity, I will refer to them as units.
In German, they are called “Führungsgrundgebiet” or “FGG” (and you might see the term in some pictures below).
I am part of the “Operations” unit (FGG3), which is responsible for the various processes we have, preparing warnings and alarms, and triaging incoming messages to the NEOC.
If this sounds interesting, you can apply to do your service at NEOC, you can find more information about the process to apply online (only available in German).
In case of an emergency, all units will have representatives (civil and military) in a main operations room, while the bulk of the military personnel will work from a “back office” (BO).
In operations, we have various “stations” as we have to create different “products” (documents for supporting the decision-making), send out alarms to warn the general public, and make sure we distribute information on all relevant channels so other units and affected authorities (like police, local government representatives, etc.) are informed.
In the back office, we get tasks from the unit leader after they talk through them with the other units. While we know what kind of warnings eventually have to be sent out (it’s a pretty well-defined process in most cases), various factors influence the content (magnitude of an event, weather, etc.). In the back office, the work is done by a subset of the unit, as an event might take several days to weeks, and the work is done in shifts.
Learnings from our Service
In September 2024, we had a week of service where we did a two-day training exercise. While in general, it went well, there were a few points that were raised during our review and feedback session.
There was some confusion about the progress respectively the state of some of the tasks. If we send out warnings or alarms to the public, they must go through a more rigid verification process, where two other people have to check and confirm that everything is correct (you don’t want to set off alarms or evacuate towns for no reason…). If this takes time, it’s very easy to forget about those tasks:
Is it being reviewed right now? Or was it already?
Has it come back for some adjustments?
Have we sent it out yet?
When certain decisions are taken, the inflow of tasks can be high, and often many things are needed (it goes without saying that all of it should be done as fast as possible). It has happened that some tasks simply were “lost”. Sometimes tasks come in via phone, via digital systems, or via someone just walking from the main operations room to the back office. Combine that with shift changes and you can easily “lose” a task.
Some processes require a confirmation from another party before they are “done”. It’s easy to think that the work is completed with the first part, and we might never get the confirmation. And while everything is documented in a wiki, in stressful situations you probably will forget that you need a confirmation and simply move on.
Transparency
While in my professional life, I mainly deal with teams that work in software development, I’ve come across such issues before: We were missing transparency. Transparency about what is ongoing, what is waiting to be picked up, and what is already done. I assumed that with more transparency, we’d be able to inspect and make sure:
We know each task we’re currently working on (and who is working on it)
We know where in the process each task is
We know the dedicated steps for each task
And with this, we could also take better action on what to focus on. Instead of “just executing”, it should allow us to self-organize the work in the back office. Instead of micromanaging, we collect what needs to be done, and let people work on it how it best fits them.
Transparency enables inspection. Inspection without transparency is misleading and wasteful. - Scrum Guide
Kanban Board
The proposal was made to create a Kanban Board where we could track our tasks through a defined workflow. Each card on the board would represent a task and could have details for this specific task written on it. That should help guide the people who take up the task and make sure we know what to do and where we are in the process.
Kanban Definition
Before I go on and share how this was put into practice, let me quickly share what I mean when I talk about Kanban. I’m using the definition as described in the Kanban Guide:
Kanban is a strategy for optimizing the flow of value through a process that uses a visual, pull-based system.
So we want to optimize the flow of value, where flow means “the speed and smoothness of the delivery”.
Good flow feels like a well-oiled machine. The Kanban system members enjoy a sense of calm and get more work done with minimal stress. - Definitions for Kanban Guide
To do this, we planned on introducing a “Kanban Board”. This is a visual representation of a workflow. As the goal is transparency, it should be accessible to the Kanban system members at all times.
Preparation…or lack thereof
Our next service was planned for November 2024, two months after we concluded we wanted to give the Kanban board a try. This specific service was special, as we were part of a big exercise (Gesamtnotfallübung 2024) that happens only every two years and where national and international partners take part (for example the national grid operator Swissgrid, the nuclear power plant in Gösgen, the Swiss federal railways, the Swiss Federal Nuclear Safety Inspectorate, and more).
In light of this, we could not afford to take time and train everyone for one or two days on the new approach. When most of the staff would arrive, the exercise would be in full swing already (it’s part of the exercise that the military staff is called upon during the exercise, as it would happen in a real event). At the same time, there is no better way to try this out, it won’t get any closer to a real event than this.
Two of us were invited a day before the start of the exercise to prepare the basics, but we had to keep it simple. We decided to go with a minimal approach and did the following:
Design a board that has all the relevant information needed for people to see who is around and what’s going on
Design a workflow that should fit our purpose but is not overly complex (we had no time to elaborate on explicit policies or complicated WIP control strategies)
Prepare a template for the Kanban Cards and some pre-filled Cards that we knew we’d need (as the scenario is quite standardized this was possible) so we have a starting point but also have the flexibility to capture things we could not yet think about
On the top right, you can see our shift plan and below the names of the individual people, split by who is currently “active” and who is “inactive”. We created transparency about two specific roles as the “Chief Back Office” is the point of contact and it has to be known whom to talk to, as well as another role (“ASNAZ”) that happens to be in a dedicated room (so it’s good to know who is there as you can’t see them).
We also highlighted important dates (when is the next “situation report” and when do our products have to be updated) which should inform everyone working in the back office.
In the middle part, you can see the workflow, which looks like this “To Do” → “Waiting for Information” → “Processing” → “Product Update & Storage” → “Done”
At the bottom, you can see the Kanban Cards ordered by categories that made sense for the event, as well as some “blank” cards for anything we did not foresee.
We assumed that this was “clear enough” that we could get started without much introduction, while still providing enough value. We were also very much aware that this was far from perfect, but it was not worth putting more effort into - instead, we should inspect and adapt in the coming days.
Obeya
You might have noticed that the above is not showing “just” a Kanban board, but has more information visualized. We implicitly applied ideas from “Obeya”:
An Obeya is a physical or digital workspace where strategy meets execution. Typical about Obeya is that it guides both behavior as well as a work environment design. It creates a so called “single source of truth”. - Obeya Association
In short, the idea is to visualize everything that is needed for the people that work with Obeya so they can make decisions as independently as possible. You can find more information about Obey on the homepage of the Obey Association.
For the rest of the post, whenever I refer to Kanban, be aware that implicitly I also mean the Obeya concept.
Experience During The Exercise
When I arrived at our back office, a few people were already there, but we were not yet operational. Here the board helped a first time - we could tag who is already around (independent of which shift they are in) as well as look at the predefined cards. By going through them, we could in a more structured way try to understand what has already happened and what we should start to take over (the civil employees might have done some of the work already, and the cards helped us to “transfer” the knowledge).
During the first day, the acting “Chief Back Office” (CBO) started to familiarize themselves more with what works (and what doesn’t work). For example, it was not clear:
Whether everyone should update the board or it’s just the CBO that does this.
For what we needed a card and what we can simply do.
When/if a card should move backward.
But overall, the feedback from the group was positive, the board and process seemed to help. And often you could find someone studying the board.
We also had some early learnings and made some adjustments:
We very quickly ran out of space in the “Done” column, but also wanted to keep the cards (as they are a great artifact for reflection later on). Also, we wanted to see the done items we recently closed (that is valuable information as well), so we simply added an envelope and stored the done items once we ran out of space.
Some people might not be available (due to a leave of absence, having lunch, etc.). We indicated this by turning their names upside down.
We also have three specific products, which have to be updated for the situation reports. Indicating who is taking care of them on the board helped to make things more clear.
During day two of the exercise, the board looked like this:
As you can see, a lot more stuff started to happen, and the board proved to be a great radiator of information. It helped the CBO keep an overview, and also make sure we’re following up on our tasks. One example was that we were tasked to organize a briefing for an external group. However, right after that, the situation escalated and lots of more important things came up. It took us till the next day to finally follow up on this task. Without having it on the board, we most likely would not have remembered to eventually follow up on this.
Learnings after the Exercise
After two days of exercise (which went rather well), the feedback on the approach with the Kanban board was rather positive. It helped “track things to closure” organize the work, and in general keep a good overview.
Having the board also uncovered some dysfunctions - mainly outsiders “walking in and walking up” to people in our back office and giving them tasks. This became visible because it was not clear whether cards should be added, whether should we work on this now, etc. This has triggered a discussion about who is making tasks available, who should be “accepting” them etc. which is something we will have to clarify going forward.
While this is not “Kanban by the Guide”, it was very useful. Going for a simplistic approach made sense, given the constraints we had: No real preparation time, no time to train anyone, and also it has to be clear that this way of working might be new to some.
Our unit is diverse, not everyone works in Software Development where “Kanban” might be a common term and easily understood. Someone even referred to it as “Kaboom” instead of “Kanban”. This sparked the inspiration to name the whole process (and the title of this blog post): The “Kanban Back Office Operating Model”, or “KABOOM” in short.
Having predefined cards ready for events that have a defined process is extremely helpful, as when we are there for an emergency, they are a great guide. However, we noticed that we can put more guidance on the card itself (think of them like “predefined subtasks” that we know we have to do for specific actions). Also, we decided to simplify the workflow, as it turned out that two of the stages were not providing value, and instead capturing some of the steps needed (if they are needed for a given task) on the card itself, reducing the workflow to “To Do” → “Processing” → “Done”.
On the cards, we also introduced a step in which we capture “lessons learned” before we set anything to done. Having this happening “in the moment” is a great practice, as often we will forget as time goes on, even if we reflect just a day or two later. But having the cards and some space to write things down as we just worked on it will make sure we’re capturing as much as we can.
The adjusted cards are now stored in our KABOOM envelope. And while we hope we never need it, if it ever comes to it, we simply can grab it and are set up in a matter of minutes.
Another interesting aspect was the “Chief Back Office” and the active shift might use it in different ways. Some might prefer to have more “fixed stations”, while others might use a more flexible approach. This could also depend on the current situation. The great thing is, that the KABOOM will give you flexibility so people can focus on the work and decide how they want to work. Some might call that agility, but I’d say just give people the information they need and let them focus on the work to be done.
What’s Next
Our next service is in March 2025 (and hopefully we don’t have to meet earlier…). The plan is to further refine the KABOOM and also take some time to elaborate on the different elements as there is no big exercise planned.
There is also the question of whether the board should be physical or if a digital version could be more useful. I’m a fan of a physical board, but there are some advantages of a digital one (for example the team in the main operation room could see it) and we might investigate the possibility of it.
Last but not least, being a nerd for numbers, I’m curious if there would be any value in capturing the flow metrics. I’m undecided on this, both because I would not know how to best capture it and in general if it would provide value, but it might be worth an experiment.