One of the central elements of Kanban is the ability that you acquire in redesigning continuously your process as you understand how things work in your scenario. In fact, understanding what we do was the first benefit that we got after starting to work with this approach about a year ago. Insofar as we have got this comprehension, we realize that there was something special about how we have been signalizing the elements of our process. As these signals become more meaningful, more stable and predictable becomes our process.
Figure 1 shows what we call "The System View". That is the main view of the process and it is the most frequently used view by all team members.
Figure 1: View of the System as a Whole (Click to Expand)
As you can see in Figure 1, there is a lot of signalization on our Kanban board. The signs help us to quickly answer some specific questions that we have to deal with on a daily basis, like "What am I supposed to do now?","What and How much has been delivered week after week?" or "What are in the system right now?". Besides, it helps us to make work go downstream more smoothly, sometimes by point us to flow decisions based on our politics and preferences, sometimes by showing up bottlenecks that happen from time to time.
The System itself is the first Signalization
Our Kanban board is organized in three main areas that suggest a systemic view of the process: Input, In Progress, Output. Our system was intentionally drawn using a systemic perspective. Like every other work system, we have a lot to do (Input), we are doing some work now (In Progress) and we had already delivered some work to our customers (Output). When you are looking to the Demand Area (Input), actually you are trying to look at the future. The WIP area represents the present and the delivered area the past. Look at this picture as a whole help us to make decisions when we see ourselves in front of hard situations involving priorization, capacity, overloading, flow, value and waste reduction. It is a key point of this approach the ability to evaluate specific situations having the whole picture in mind.
Every decision results in the movement of a physical token that moves around the board following physical constraints and rules (like in a chessboard). The tokens are moved from the left to the right. I just can move a token to an empty space, for example. If there's no empty space, I have to create this space by moving other tokens to other areas. Then a trigger is fired to re-analyze the system in concern to priorization, schedule negotiation and resource availability. In other words, when you (as a Team Member) are operating the system, you are using the signals to guide yourself. Just like in a chess game.
Figure 2: Signalization guides the Flow and Team Decisions
Our board today can be seen with different eyes, or different views. We look at our system like we look at a map, and there are areas in this map that can be zoomed in to increase the details about what is happening in there. Figure 3 shows the three main areas in zoom. We need to look with more details to manage different areas of the system. Demand management, for example, is done by increasing the details of the Input Area. So when we have to organize the demand, some tools and visualization fit better with the nature of operations inherent to this area of the system: bigger cards, priorization filters, drag and drop of the cards between areas and slots, grouping by customer importance, and a basket thrash to put away old demands that expire as the time goes on.
Figure 3: Expanding the Input Area with the Front View
Another area where it is very important to take a closer look frequently is the WIP area (Figure 4). When we look at this area, we want to know how the things are going on now, in the present. Here we are monitoring other aspects of the process, for example:
Figure 4: WIP View
- how the demand is distributed in terms of classification (see "Value and Demand" later on this article). To do that, we have a graphic signalization that shows the percentage of every class of service that we are working on in a moment. It allows us to influence the system in a way that more work of certain type can be injected to balance the output results. For example, we can prioritize more "value" work, when we see that the percentage of "non-value" work is too high.
- how the demand is distributed for each team member. Sometimes the flow in the system is threatened by work accumulated in the buffers of team members. We can see that simply analyzing the amount of cards by work-state (See Figure 5). It also shows important information about team overloading and multi-tasking levels.
Figure 5: Amount of cards by work-state in WIP
- don't loose the focus in cards that are "Waiting for Customer". This queue holds cards that are waiting for information or for deliberations from the customers. As more time they stay in this queue, worst will be for the flow of the system in a general way.
- Parking Lots keep our eyes on the progress of deliverables that need several other minor deliveries to getting done. It could be a MMF (Minimum Marketable Feature) for example, when you need to group Value as a set of features or user stories to deliver at a once. They can also represent any other Business Activity that has to be done by the synchronized execution of several other cards, whatever class of service they are.
The Delivery Area is what we see when the Output part of the system is zoomed in (Figure 6). This area represents the past, and is the source of our "Yesterday Weather" analysis for planning. Cycle time and other information are used to give us the necessary understanding about what we are capable of (in terms of delivering per class of service).
Figure 6: Delivery View
Value and Demand
Another important topic that worth mentioning is how the work can be classified, sized and organized in the system. And the signalization comes again to help. We represent each unit of work in our system as a "Kanban Card" and we use different types of signalization to draw and organize them on the board (Figure 7):
Figure 7: Signalization of our unit of work (Kanban cards)
- Each card is labelled with a unique number which help us to track it and to get a better communication when the team needs to talk about it. Bigger cards are used to represent the work before they enter in WIP (Work In Process), smaller ones after. The reason is because we can show the description of the work when they are bigger. It help us to analyze several of them at the same time when doing priorization.
- Colors are used to classify the work by classes of service:
- [Green] for Value demand: features that generates new business opportunities for customers;
- [Yellow] for Improvements to Sustaining: features that customers are missing when trying to use the product to sustain their business;
- [Orange] for Support Operations: Activities to support the use of the product by customers;
- [Red] for Problem Solving: When a customer can not use the product appropriately for any reason;
In Lean terms the Green cards are value, and all the others are pure waste.
- Two types of borders indicate if the card is a unit of work for a customer (solid border) or for the own team tooling and process improvement (dashed border).
- A sign in the top right area of the card indicates the estimated size of the work. We work with just three types of size: Small (it is our reference and it takes between 1 or 2 days of work to be done), Medium (3 times more complex than the reference) and Large (5 times more complex than the reference).
- The same colors are used to signalize how much of each class of service is in the three areas of the system. It can be a good measurement for tracking waste levels, or to help in controlling how much work of each type could enter in it.
The interesting thing about this kind of signalization is to create opportunities to see the whole using the Lean perspective of Value. We can monitor how much effort of our system is consumed to generate value in a certain period of time for each class of service, and that is the main metric that we use to evaluate our process: how much money we are spending generating new value or dealing with waste?
Stages, Queues and Limits
Once we have our value and demand classified appropriately, it is important to see how this demand flows when it enters in the system. Our visual board contains areas representing each stage of the process. Most of this stages has limits to prevent new cards from entering in it. The limits cause some interesting systemic behaviours: they avoid the perpetual accumulation of work in stages where the rate of incoming is higher than the outgoing rate; they highlight the need for sequentialization inside the stage and constant priorization of the work; and they help in making a downstream operation to be the one that establishes the rhythm of the flow. Our stages and their signalization are shortly explained on Table 1.
| The Front Queue | All the collected demand that are not qualified yet to get in the system regarding business criterias. The items of this queue are not important for who is looking at the System View. Just for those who are managing demand. But it is important to monitor the number of items in this situation for each project. |  |
| Waiting For LRM Queue | With a limit of 14. Items on this queue require more constant observation. They are just waiting a moviment in LRM Queue. This will create an empty space triggering another priorization action. So the work item is pulled from this Queue to the LRM Queue. When this happens, an empty space shows up in this one, which forces another priorization action. This time pulling another card from the Front Queue. That is the point in a Pull System. The next stage on the pipeline pulls the work as needed. |  |
| LRM Queue | LRM is an acronym "Last Responsible Moment" and indicates that the best time to work on an item has coming. The first item of this queue is the one that will be pulled from the Team to start working on it. We have two LRM queues, one for each work cell (development and support operations). Look at the empty space on the first slot in the queue beside. That is the sign from the system that more work can be pulled from the front area. |  |
| Team Members WIP Queues | Each Team Member (including the Leaders) organizes his demand using the work state of the item. Ideally, a team member would be holding just one card, and that one should stay on "In Progress" Area. But, in the real world we have to be able to deal with other cards in different state contexts. The Feedback area holds cards that come back from downstream, for quality reasons, for improvements or even for failing in following standard compliance policies. The Inspection area is filled by automatic distribution. The numbers in this area represent the order that which each team member will receive the next item for doing inspection. It means when someone moves a card indicating that it is "Done", this card is automatically associated to an another Team Member that has the number #1 in his slot. Then everyone else gets a new number (for example, the number #2 becomes the new number #1 and so on). This mechanism was created to randomize the allocation process for inspections and allows all team members to inspect the work of all the others members. This is an interesting way to influence the flow of the system using signalization. |  |
| Release Ready Queue | When the work is done and inspected, the next stage indicates that the item is just ready for release. It means that the customer can already be notified about that job. Here we have different actions depending on the type of work or deploy issues. The notification can be just a link to download a new release of the product, or some instructions to configure the product or even just an information that some situation has been addressed and the product is ready to use. |  |
| Waiting For Customer | Eventually, the work can't be done because some information or consideration from the customer. So this is a kind of "hospital" area, where the work stays stationary until we get the information and can proceed in WIP. |  |
| Released Queue | That is the real output of the system. After we send the notification, we move the card to the release area, and the stop button of the cycle time clock is pressed. |  |
Table 1: Stages of our Kanban System
"Stop the Line" Signalization
One of the problems in visualizing a process as just a sequence of linear steps is underestimate those 20% of the situations that causes 80% of the problems. The linearity occurs just when you are observing in a high level view. On a daily basis, a lot of situations are happening and we have to be conscious about the complexity in handling multiple demands with different people and with different customer expectations at the same time. Implementing Autonomation can be powerful to avoid work without quality to move on through the process. A big source of quality problems generated by complex trade-offs when the work is in progress can be avoided. Just put your tools to send you some signs when possible anomalies are in place.
As an example, we have a sign that appears on our board when we get suspicious about the quality of a build generated by some modification in the product. This is quite different than the Continuous Integration sign (that we also use to check several aspects of the code base). A new release of the product will be only inspected after a successful CI build. If some quality issue is found during the inspection process, the kanban card will be moved to the feedback area of the team member who first implemented the modification. Meanwhile, if we have any new build (even from a different team member) that has just been moved to the release ready area, sharing the same code branch of the suspicious one, the board will signalize the problem as you can see in figures that show the release ready queue.
The lesson here is that any process is rich in opportunities to fail. The idea is just get these signs and just "stop the line" until the team becomes confident again to continue the flow.
Signalizing Kanban Movements
When you have a system where the kanban movements are quite frequent, with a lot of movements on the board daily, the ability to follow this movements becomes very important. It is also common that two or three team members are somehow collaborating to deliver the same unit of work. So a mechanism to let the Team know about the life cycle of the card as it is flowing through the system is necessary.
The mechanism that we have been using to keep the team up-to-date is a system task bar notification tool (see Figure 8). Clicking on the notification window will send you directly to the details of the kanban card (Figure 9).
Figure 8: Signalization of a Kanban card movement
Signs of Collaboration
One of the ways to see if your team is collaborating to get the things done is observing how they communicate with each other. Is the communication rich? Is it happens all the time or just when they meet each other on the stand-up meetings? Is there a way to look for signs of collaboration as the time goes on?
We get these signs from our kanban system as well. We did that transforming our kanban cards in free spaces for open conversation. Everyone is stimulated to write short notes of anything related to that work on the card (see Figure 9).
Figure 9: Kanban card detail
Every time someone attaches a note to a kanban card, the team receives the signalization with another task bar notification:
Figure 10: Signalization of a new note added to a kanban card
So we use the kanban as a key element to connect the process of management to the process of communication. That became a huge element of leverage in our collaboration model.
Signs can point you to Technical Artifacts
In software development, management and technical activities are closely related. It is not simple to get traceability from management to code. But when you got it, your process become more reliable and a lot of facilities comes to help. In the output area of the System View you can notice that some kanban cards have a build number near it. It means that we had to generate a new build for the application to deliver the associated demand. This kind of sign combined with the type of demand show us how many changes we are doing in the software to solve bugs or to create features for sustaining without creating new value. It is just another sign that brings the waste to the surface, making the team conscious about the pain of technical debt.
To do that, our build server was configured to update the kanban card with the build number when a new build pass by the Continuous Integration process. That kind of automation is just possible because we enforce a commit policy on our subversion repository where the developer has to inform what kanban card is associated with the changes in the code base. With this kind of policy we can go from the demand to any other important technical artifact, including how the code base was changed to attend it (see Figure 11).
Figure 11: Traceability from the customer demand to technical artifacts
Final Words about Signs
Signs are good mechanism of compensation when you are trying to influence a system. To correct something that is not working appropriately, you first have to see a sign of it. Usually signs of deviations from the expected behaviour come very late. The kanban management technique is great to make these signs visible all the time. We are still looking for good ways to find these signs and improve our process.