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

• ptimize 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

• n 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

• n 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.

Expedite services are those that will cost Juliana the most if she postpones and delays them. They are critical and top priority items that require immediate handling. An example of this type of service are critical production issues. With fixed date items, Juliana is safe up until some specific date. There is no direct benefit from implementing them sooner, but if the team exceeds the deadline, they will get penalties. An excellent example in practice is the implementation of GDPR. If the Globomantics team falls behind schedule, fixed date items can become expedited, and they will probably have to speed up their execution. Intangible services can be linked to maintenance. In the Globomantics team case, those are the items for maintaining the Agri-line robot. As you can see from the diagram, the intangible services are not urgent. However, Juliana has to be careful as they can become critical in the long run and can be escalated to the expedited ones. Items that fall under the Standard class of service are usually handled on a First In First Out (FIFO) basis. These are the work items that aim to solve business and customer requirements without a fixed timeline or sense of urgency. The majority of items Globomantics will cope with will fall into this category. Please remember that you can define additional classes of services, but in our scenario, Juliana decides to follow the general recommendation for capacity allocation, and she sets up the following policies for the items coming into the Globomantics workflow:

• Expedite – +5%
• Fixed date – 20%
• Intangible – 30%
• Standard – 50%.

Handling Resource Bottlenecks

In the previous module, we have already spoken about the ways to identify and resolve

• bottlenecks. You saw that setting up WIP limits helps to expose them. You also learned

about some general guidelines you can follow to fix the bottlenecks. We have followed the Globomantics team and together with them, faced the following three situations:

• When a previous column does not have any items that are ready to be pulled;
• When the team manages to finish all cards in an intermediate column, but the next

column’s resources are not available to pull them further;

• And the situation when it happens that it takes more time for a team member to finish

a ticket than expected. We have witnessed how the Globomotics team resolved those situations in the first phases

• f their transition. However, as the teams' practices evolve and they become more and more

experienced, they can apply some other solutions. In other words, they come to a point where they start implementing the Kanban's sixth practice, "Improve and evolve." In this clip, we will see additional options for handling the bottlenecks effectively. Before we continue, I think it's essential that we all agree about the term bottleneck. I hope we have the shared understanding that a bottleneck in a system controls the flow, i.e., a bottleneck restricts our potential for throughput. If we take a look at any Kanban board, we

can say that a bottleneck in a process is where work items are piled up and are waiting to be

• processed. In the example of our Globomantics team, we can get the implemented cards

waiting to be reviewed, or reviewed tickets that are now waiting for testing, or maybe verified items waiting to be deployed. What we can see as a bottleneck as well are non-instant available resources. Although they are not a direct bottleneck, we are often in a position to take the same actions to compensate for them as we do for the bottlenecks. Kanban welcomes continuous improvement, so it is open to implementing different CI

• methods. One of the well-known schools that Kanban supports is the Theory of Constraints

and its framework, known as the "Five Focusing Steps." Shall we go briefly through the steps? Number one is, "Identify the constraint." In our case, we can say we should find a bottleneck in our value stream. Number two is "Decide how to ​exploit ​the constraint," i.e., identify the potential throughput of the bottleneck—and then compare it to what is happening. The next step we have is to "​Subordinate ​everything else in the system to the decision made in the previous step." Please note here that we are not asked to make changes only in the bottleneck, but anywhere in the system with the ultimate goal to get the maximum capacity from the bottleneck. Step four says, "​Elevate ​the constraint." This step indicates that the bottleneck is operating at its full capacity, but still without enough throughput. So, the suggestion is to implement improvements to relieve the current bottleneck and move the system constraint elsewhere in the value stream. And finally, the last step is to "Identify the next constraint and return to step 2." With this final step, we achieve continuous improvement where we are always working on increasing throughput. In the previous module, we have already spoken about how to identify bottlenecks. Let's tackle step 2 in more depth now. Exploitation ​actions are also known as ​protection ​actions. So, what are the cases when we might consider protecting the bottleneck? In instances where the arrival rate of work is irregular, resources may become idle. Or when the resources are not available, and work starts to pile up. And what is the best practice to protect a bottleneck or non-instant available resources? By introducing buffering columns in front of them. The purpose of the buffering columns is to absorb the variability in the arrival rate of new work queuing. Many Kanban teams use separate columns to indicate the buffering states. These columns usually have names like 'Ready for review,' or 'Ready for testing.' In order not to create waste by introducing buffering columns, there is a suggestion to add a shortlist at the bottom

• f each column. The list represents the Definition of ready. What is also essential when

visualizing queues on the Kanban Board is to manage their WIP limits strictly. By doing so, the teams allow for the pull system to be implemented. When team members start to pay attention to buffering columns, they begin to realize how damaging these waiting states are to their process.

I would like to emphasize that it's up to you and your team to decide whether you should map your value stream to visualize the buffering columns or to eliminate them. In the second case, I suggest you use the so-called Drum-Buffer-Rope Kanban implementation. We will not go deeper into this topic in this course, but I encourage you to investigate further as your team's practice evolves. If we visit our Globomantics team and join them for a meeting in front of their board, we can hear James, Devops speaking. "I know I've suggested adding my tasks on the board, but lately, I feel more like a bottleneck. I'm not sure if we mapped the value stream correctly. If we look at the Agri-line robot's maintenance, the flow is good, as I should deploy fixes as we make them. But I'm worried about the development of new features of Home 1 robot. It often happens that Emma verifies several tasks before I need to deploy them for the client. I suggest we add a buffering column in front of the Deploy column. Emma can use this column to indicate which items are Deployment ready. And perhaps in the case of Home 1 development, we can group the cards somehow, as I'm deploying a batch of functionalities anyway, not one by one. The solution I'm suggesting would help us with the other issue I'm facing as well. I've just been assigned to another project and will be available for you only 4 hours per day." "I like your ideas," jumps in Juliana. "Let's give them a try. I have just one remark to add. If we add the Deployment Ready column to the flow, we need to be careful how big we'll make it, i.e., it should be big enough to allow the flow to continue. Still, on the other hand, it must not be too large so that you can't handle it during your availability. In other words, we need to set the correct WIP limit to it." Let's pause here. As I’ve already mentioned, adding buffers into the process is not always the best solution. But having them as a short-term, tactical-exploitation strategy might be the right solution. Now, let's examine step three. What do you think? What could be ​subordination ​actions in the case of the Globomantics team? Let me remind you that subordination actions generally involve making policy changes across the value stream, not strictly at the bottleneck. In James' scenario, the team could agree that not only James can do the Deployment. A valid solution can be that, for example, Mark, the senior developer, takes part in the deployment process and handles it during the hours of James' unavailability. Another option is to add a staff member to the DevOps team. In the Globomantics team, it would mean that the newcomer will be idle occasionally. Plus, James would have to conduct the interviews and provide proper training to whoever joins the team. What do you think? Is it a profitable solution for the team? Before making decisions like these, you need to do the Cost of Delay analysis and compare the alternatives. It all depends on different factors.

• Remember. There is no one-fits-all design when it comes to Kanban.

And to round up this clip, let's see an option for ​Elevation ​actions the team can perform. A long term solution for the Globomantics scenario can be to invest in automating the build

• process. Be aware that solutions like these usually take considerable time and budget, and

probably require hiring more staff members who are automation experts. But as I said, having automation as a long term elevation strategy can be very profitable.

Indicating Concurrent and Unordered Workflow Activities

In some situations, you may face tasks that you need to perform in parallel. Or there could be several activities that your team can do in any order. An example might be a tester who prepares and writes the test cases for a feature currently being implemented by a developer. Another typical example from practice is a card that a team pulls into the 'Development in progress' column. However, there are actually three possible actions for them to perform with this card while it's in the development state: UI design, business logic, and database development. One of the designs that can help you in situations like these is the use of checkboxes. So, you use a single card to indicate all activities, but you use checkboxes to distinguish them. The card is ready to be pulled into the next column only when all checkboxes are ticked. What I just explained is a simple solution that you can apply either using a physical board or some of the electronic options. As an extension of this option, you can opt to split the column where unordered activities

• ccur, and introduce partial rows. For example, you can create a card 'Login form,' add the

checkboxes: UI design, business logic, and database development. Then, split the column 'Development in progress' and add the rows with the following labels: UI, BL, and DB. As an additional improvement, you can consider adding WIP limits to each of the partial rows. The team should move the card inside the column as activities are performed, and once each is done, the team should check the corresponding checkbox. This solution helps significantly in increasing transparency and quickly following the status. As your team evolves, you might consider implementing another option to handle parallel or unordered activities. It is to split and merge workflows. Let me elaborate a bit. The solution suggests that, at one point in the flow, you broke a task into a couple or multiple cards that your team can process simultaneously, and this way, handle them in parallel. After they all finish with their activities, the smaller tasks are merged back to the original card. The original card then continues to flow through the rest of the system. In addition to this solution, as in the previous case, you should split one or more columns into two or more rows to visualize the flow. When you use sticky notes on a physical board, the original one can be stuck behind one of the new ones. However, when using electronic boards, you might face a

• challenge. It can be hard to implement this solution as it may affect the metrics and
• reporting. If you still decide to opt for it, the suggestion is to create two or more child tickets,

if the software supports hierarchical work items. The children tickets should flow through the partial rows of the flow, and the parent card can continue its flow only after all children have arrived at the end of their partial rows. Be careful with WIP limits if you decide to create new cards out of a single card. In the parts

• f the flow where you are splitting and merging the items, the WIP limits should be reviewed

and adjusted appropriately.

Now, I'd like you to think for a moment. Do you have any ideas on how you would visually represent optional activities? A good practice is to use checkboxes in this case as well. So, next to the checkboxes that you have already introduced to track the parallel and unordered activities, you can add fields to indicate if the task is mandatory or optional.

Introducing Kanban Tools

Physical whiteboards in the office are a great way to set up your Kanban system. They encourage team collaboration and engagement and help with increasing the sense of

• wnership by all team members.

After setting up your system and gaining more experience and more team maturity, you can consider introducing an electronic board. Some teams choose to keep the whiteboard and to maintain them both. Others opt for only one option. Having an e-board can extensively help you collect historical data and generate reports. In the era of an increased demand for working from home, having an e-board as the first and

• nly choice is becoming more and more popular. Electronic boards are the right choice for

distributed teams as well. So, let me name a few software tools that you can opt to use. Those are Planview LeanKit, Kanbanize, Swift Kanban, and Trello. You can play around with each of them, try them for a trial period, evaluate the pricing models, and make your own decision on what fits your teams' needs the best. Another widely used tool is Jira. Here, at Pluralsight, you can watch two great courses created by my fellow author Xavier Morera, on how to use Jira. Xavier covered using Jira for both, the teams practicing Scrum, and those practicing Kanban. I highly recommend you watch both of these courses. Great job, my friends! We have come to the end of one more module. By now, we have covered several Kanban practices and principles. At this point, you should possess significant knowledge on how to transition from Scrum to Kanban smoothly. We will continue this course by covering even more advanced topics that can additionally help you with increasing your team's efficiency. I invite you to join me in the next module, where you'll discover different feedback loops applicable in Kanban.