Module 4 - Smoothing the Workflow with the Kanban Best Practices - PDF document

Module 4 - Smoothing the Workflow with the Kanban Best Practices Establishing an Even Workflow Welcome back to this module, 'Smoothing the Workflow with the Kanban Best Practices.' In this course, we are exploring how to apply Kanban in the context of an existing implementation of Scrum. In the last module, you learned how to visualize the flow, making a distinction between work item types, limiting your work in progress, and dealing with bugs, blocking items, and bottlenecks. This can help you noninvasively optimize the existing process. In this module, you'll learn how to calibrate your workflow even more. We'll start by explaining workflow input and output boundaries to understand clearly how work is initiated and completed. Next, you'll see how to use demand analysis to adjust the Kanban system better and allocate your capacity best. You will also learn how to handle a resource bottleneck effectively. To do so, you'll have to understand how to use the 'ready queue' to optimize workflow. As we progress, you will learn how to utilize split columns to handle concurrent and unordered workflow activities. Finally, we will round up this module by mentioning some Kanban tools that can additionally help you smoothen your process. As we have highlighted by now, Kanban focuses on creating a continuous workflow. The ultimate goal is the ongoing added value for the customer. Kanban strives to visualize and improve any process, not just software development. But in this course, we are focused on Scrum development teams aiming to achieve a predictable development pipeline that will produce high-value work. We are following an experienced Scrum team from an imaginary company Globomantics, who has decided to switch from Scrum to Kanban. All the steps the team has performed up until now didn't upset them and their current flow. Slowly and patiently, they ensured they embed the third Kanban core practice, Manage flow. The Kanban board represents a flow system where cards or tickets, i.e., work items flow through various stages of a process, starting from the first left column to the rightmost column. As we have already seen in the previous modules, Globomantics Kanban team follows several conditions for this flow system. First, they introduced visual signals to limit work in progress (WIP). These signals are located in the title of the columns and represented in brackets. The columns represent the activities or so to say status in the process. The Kanban cards, i.e., the work items have to freely flow following input and output boundaries to initiate and complete work. The team adopted the flexibility of changing priorities as they got acquainted with the practice not to waste the time to plan, estimate, and refine the features that got dropped off. Slowly they managed to establish the system where they can work on a few things only, complete them first, and then start new ones.

Juliana and her team begin to feel benefits very soon as the workload starts to flow evenly. They have all agreed that the best thing lately is the simplicity they have introduced to only picking the top story from the backlog and finishing it. The team have also highlighted they like staying focused on just a few stories at a time. Let us pause for a moment to reflect on the benefits achieved by introducing the explained practice. I would highlight the following first. Managing flow allows the development of a quantitative understanding of the entire process and how to use it better to handle the capacity of the workflow and enhance customer satisfaction. Next, it helps us to identify impediments in the workflow, and it helps us to define ways to eliminate them. Besides, it improves delivery predictability and workflow efficiency. Later, we will cover more in-depth how it helps us understand the types of demand and how they are processed to deliver customer value. For more mature organizations, managing flow allows them to establish different service classes and improve forecasting and risk management. For teams that practice Kanban on a more advanced level, there is another challenge to pay attention to. Namely, the practice that brings even more benefits in the process is adopting both upstream and downstream Agile activities in tandem. Now, let us take a moment to distinguish the two briefly. Upstream activities are focused on smoothening the process between business and development teams, while downstream activities remove barriers between development, testing, and operations. What we have focused on up until now in this course are downstream activities. And we followed the Globomantics team in the creation of their so-called delivery Kanban board. We can conclude that in this part of the workflow the teams visualize the steps through which a committed work item advances into a value-adding deliverable. But, how do we get to the work items the teams can commit to? The answer lies in the upstream activities, i.e., in the discovery part of the workflow. This part focuses more on an idea that is growing and converting into a committed request or being rejected. So, each design goes through several steps of clarification before finally being selected for development or discarded. A good practice is to separate these two boards. More experienced Kanban teams should have a discovery Kanban board with, for example, only three columns: Opportunity, Integration, and Analysis. The flow starts from the first left column, Opportunity, where the team places still unclarified, rough ideas. The next stage is integration, where the design becomes more unified and more precise. During the last phase, analysis, detailed work items emerge. Please note that from each of these columns, at any moment, the ideas can be rejected. If you decide to introduce both boards, another good practice is to use a commitment point. This is literally a border between discovery and delivery boards. The rule to be followed is that only the work items that the customer truly wants to be delivered should be placed in this column and get the chance to come into the delivery workflow. The work items that are not rejected are ready to be pulled into the second team's board, i.e., the delivery kanban system.

Using Demand Analysis for Fine-Tuning The concept of balancing demand against capacity should not be related only to the teams practicing Kanban. It is the responsibility of every project manager or service delivery manager to ensure the system is safeguarded from overburdening. However, this is easier said than done. In systems with less experience, there is a tendency to say Yes to every request. Often, there is an expectation that everything requested will be done. In systems like these, the work is pushed into the process, and individuals are overburdened. If we look through Kanban's prism, we can conclude that these systems lack strong policies. For service delivery managers working in these environments, it is challenging, if not impossible, to balance the demand against capability. However, as the systems and the teams evolve, it becomes much easier for them to allocate capacity to ensure timely and proper demand processing. It becomes possible to classify the work items into three categories: discard immediately, do it now, leave it for later. To accomplish this in a Kanban system, the fourth practice, "Make policies explicit," has to be implemented. The goal of making policies explicit is to set up rules to manage flow in a way that will provide a better understanding of the entire process and allow the team to improve the process further. Some examples of policies are: setting the WIP limit, capacity allocation and balancing, and determining the Definition of Done for different stages and work items. Next, we have so-called Replenishment policies for selecting new work when capacity is available. Another example of policies are classes of services. When we talk about capacity allocation and balancing, an example of a policy might be that the team agrees they can handle 15 bugs every month. In the case of our Globomantics team, they could, for example, put in place the following policies: 15 Agri-line robot bugs per month can enter the system. There can be only one purple card in an active state of the workflow. To remind you briefly, we agreed to use purple cards in Globomantics case to indicate the work items that depend on the third-party API. Now, if we touch upon classes of services, Juliana can do Cost of Delay analysis. She can narrow triage discipline down to specific classes of service. In other words, she can group requests into those three categories, discard immediately, do it now, leave it for later, based on the cost of delay of work items. The cost of delay can be explained as the amount of a work item value that will be lost if we delay its implementation by a specified period. Kanban defines four types of delay costs: Expedite, Fixed date, Standard, and Intangible. Juliana can use these four classes of service to classify work items coming into her team's workflow.