STATIK or how to start the path to predictability

In my previous article, I talked about how visualisation is the key to success, and many might wonder, what's the actual advantage of visualisation? How can it help, considering the time investment required to maintain it, and so on? And I won't argue with you that certain time investments will indeed be needed, but the benefit you'll reap is difficult to underestimate.

In all modern project, initiative, product management approaches, and even in task flow management, visualisation is used in one form or another. It can range from Gantt charts to Story mapping, from Kanban boards to simple to-do lists. However, all these tools pursue one crucial goal - to display the entire volume of work that needs to be done. The associated benefits are equally important; having all tasks in sight allows you to forecast deadlines, make decisions, prioritize, build critical paths, and track risks.

As you may have guessed, I'm starting a series of articles on the topic of the Kanban method. Why Kanban, you may ask, and the answer is quite simple: Kanban can be applied in any field of activity, at any time, and on top of any existing process, framework, or methodology. It's like Lego, allowing you to choose the necessary set of built-in tools and adapt smoothly without disrupting the system's operation, but only by adjusting and gradually improving it.

So, where to start our visualisation, you may ask? Many would immediately start choosing a tool: Jira, Miro, Trello, etc. But that's not the most important thing; at the initial stage, it's crucial to identify all incoming flows and all stakeholders. So, set aside the visualisation tool for a while and let's start our immersion into Kanban through the use of STATIK (Systems Thinking Approach to Introducing Kanban).

STATIK is one of the tools of Systems Thinking that helps us understand how our system works as a whole, rather than its individual elements, actions, processes, and just steps within our system.

Now, we can move on to the most interesting part, building our system based on a tool proven by years and companies. There will be a total of 8 steps, so you'll need to allocate some time and conduct some research before you can visualize the entire value stream. And besides, you'll need participants; surround yourself with people involved in the process, those who work on delivering that very value. They are your treasure trove of knowledge; they perform daily work that comes to them from different parts of the system.

Step 1: Understand what makes the service fit for the purpose of the customer

At this stage, it's crucial to determine the satisfaction of our customers and understand what constitutes the primary value for them. Typically, criteria such as task completion time, quality, predictability, safety, compliance with non-functional requirements, among others, are included in the study, but not limited to them. In other words, we are defining the criteria for the suitability of the delivered value from the customer's perspective. These metrics will eventually become your key performance indicators and will be interpreted into KPIs, SLOs, SLAs, etc.

This step is often skipped due to team immaturity or because it requires significant investment in research, including establishing initial feedback loops with customers. I would like to emphasise that skipping this step is not advisable because by forgoing research at this stage, you will lose the most important aspect – the key performance indicators of your system's effectiveness.

Step 2: Understand sources of dissatisfaction with the current system

The second step is divided into two parallel actions. In the first case, we reach out to our customers to provide feedback on what specifically they are dissatisfied with. In the second case, you delve internally and investigate feedback from the organisation, team, or group of people working on delivering value to identify internal sources of dissatisfaction – factors that hinder performing good and professional work and meeting customer expectations. Often, the sources of dissatisfaction from both sides, external and internal, coincide: by fixing one, you will address the other.

Step 3: Analyze the demand

At this stage, we move on to the initial architecture of your future Kanban system, and to do this, we need to understand the demand. At this stage, you begin to think like your customer, identifying who your customers are; what they are requesting; the frequency, speed, and structure of incoming requests; and their expectations.

Next, we need to determine the types of work items. For example, if you're a customer support team at a bank, you provide support to customers both over the phone and through text-based communication channels such as email and chat. What would be equivalent to a customer's request to check their account balance versus an initial calculation for a potential auto loan?

I hope you grasp the depth of the issue, and yes, you are absolutely right – you've likely realised the non-trivial nature of defining work items. As a practitioner, I can say it's important to strike a balance between a sufficient level of detail and an appropriate level of abstraction for your system. Having multiple types will facilitate risk management and overall workflow, whereas too many types won't provide the necessary level of aggregation for complex requests.

For each identified type of work item, we want to understand the rate of arrival, the volume of demand and its structure, the rate of demand over time, and at different times of the day, days or weeks of the month, months or quarters of the year. In other words, we want to identify fluctuations in demand and correlate them with time.

Step 4: Analyze the capability

This step is often overlooked by newcomers or when building a new system. While in the latter case it may seem like a logical decision, I would still recommend newcomers to take the risk and try to expand their horizons – after all, isn't that how we grow? Besides, there are plenty of experienced people around who are likely willing to help you understand.

So, what do we do at this stage? We study the capabilities by examining historical data on service provision: order fulfilment time; functional and non-functional quality; predictability; compliance with regulatory requirements or standards.

The obtained results should be compared with customer expectations, and here you may make a discovery and find that there is a gap in your system, perhaps even a significant one, between current capabilities and existing customer expectations (if it's not significant, then congratulations – you have a well-balanced system). Very experienced users at this stage may even perform mathematical calculations to assess the success of the system relative to customer expectations.

Step 5: Model workflow

My favorite stage. So, we have all the calculations, feedback, and data collected; we know the types of work items – let's build our workflow. It's important to note that a separate workflow should be constructed for each type of work item; some of them can later be elegantly combined. In some cases, this can be done at the modelling stage, but there are situations where it's worth exploring all the workflows and then, based on experience, decide whether to abolish or merge them.

The Kanban method has taken the best from Value Stream Mapping or Gemba Walk techniques from Lean Manufacturing and Toyota and adapted it wonderfully to a wider range of applications. So, Lean knowledge will be useful to you, but don't confuse them: we're not building Value Stream Mapping, we're developing a map of a series or sequence of dominant steps to open new insights. It's important that we compare actions rather than the transfer of functions between people. Unlike Gemba Walk, we want to focus on the work and what's happening with it.

Step 6: Discover classes of service

Well, the workflow is modelled; let's move on to the rules, namely the classes of service, as they help us describe the policies of how to handle different types of work.

Typically, in Kanban systems, classes of service describe queue service policies or ticket priority. They may also describe the impact on the workflow, such as whether an item should undergo processing by a specialist or pass quality testing at a certain level. Additionally, classes of service may provide information on planning or whether an item is allowed to exceed the Work In Progress (WIP) limit.

Don't forget to review and consider the policies that existed before building the new system, especially if they were previously declared. However, of course, we are looking to identify hidden policies, and it's important to examine all situations or influences on the system. This often arises from the source of demand or the destination point of delivery. Requests from top management typically bypass formal management and selection processes and are given the highest priority. We want to capture these currently hidden classes of service and make them explicit.

We strive for predictability, so it's important for our Kanban system to be designed to handle them or for openness and transparency to foster discussion that will help us develop them.

Step 7: Design the Kanban System

I won't be original and just remind us that a Kanban system consists of four core elements: the Kanban system and its Kanban; ticket design; board design; adjustments to existing meetings and the introduction of some new ones to accommodate the feedback loops known as the Kanban Cadences.

To create it, we need a model of the workflow for each type of work, states of work, based on the dominant types of activities for opening new knowledge, and classes of service.

For ticket design, we'll need to understand what information is required at each stage of the workflow to make a decision about moving the item to the next action state.

For board design, we need to understand the workflow for each type of work. We need to decide: whether to have a single board for all types of work and classes of service or to have two or more boards. We need to decide how to distribute columns (usually these are states in the workflow), rows (usually types of work or sets of types of work), and the color of cards (usually for the class of service).

And, of course, the more complex and comprehensive our system, the more complex the workflow will be.

At this stage, it's also important not to forget about the 7 Kanban Cadences meetings. It's important to start with the ones that are key for you and add others as needed and as the system develops. But that's a topic for another article.

Step 8: Socialise the Design and Negotiate Implementation

As you've gathered from the previous steps and the title of this stage, it's critically important to socialize and resolve any conflicts during the construction of the system. At this stage, it's important to meet with individual stakeholders privately.

One of the most important pieces of advice I received at the outset of my Kanban journey and during the initial STATIK workshops is to start with humility. Acknowledge that the current system is far from perfect and that the service delivery does not meet customer expectations. Express your desire to improve your work to ultimately increase the value you bring to customers.

It's important to convey to customers, within the scope of this interaction, that the internal changes you're making will inevitably lead to improved quality and efficiency of your system's work. Emphasise that you value their input in these changes because you work for them.

Then, explain how the new system will work from their perspective. Document and thoroughly address all feedback. You may make incredible discoveries that will help you adjust work types, service classes, and ultimately the design of the entire system. In any case, promise to take into account all recommendations, objections, and requests, as this will bring invaluable results. Your customers will feel involved in the subsequent outcomes and will gladly share their observations and feedback on the operation of the new system.

Once you've completed processing and adjusting your system based on the feedback, you can proceed with its launch. Visualize the workflow, cards, and of course, your service classes. Everything should be transparent and understandable to all participants in the process.

After this, you'll see your throughput, the first and most important metric, which will give you an understanding of where compromises are necessary, as resources are not unlimited, and satisfying everyone without compromising quality and accumulating technical debt is often impossible.

Congratulations, at this stage, you've reviewed your system and embarked on the path of its improvement. The first step is taken, and you're on the right track. At this stage, you can already see everything and start accumulating statistics and observing the system to make necessary adjustments as it evolves.