Hello, everyone! My name is Ayina Egorova, and I work as an Agile Coach at inDrive. I’d like to share here some of my experiences working with teams without any sprints while leveraging the Kanban system. We hope that this article will be useful for team leaders and scrum masters, and any other change agents.

Here you will learn how to quickly get your teamwork going without any sprints: find out where to start, what tools we use in the company, and what mistakes to avoid. Separately, we will look into an example of a STATIK workshop within our Localization Team.

Introduction

If you have a team that is tired of sprints and interested in implementing the Kanban method, the first thing you need to figure out is whether this style of work is a good fit for the team. In our work, we use an iterative-incremental process, i.e., an approach to organization that combines stage-by-stage execution and incremental product development (value creation). One example of such a framework is Scrum.

It often happens, when a team’s work is based or focused on Scrum, that it delivers value in stages, using roles and events from the framework. At the beginning of each sprint, the team plans out work tasks, whereas at its end, it demonstrates the finished part of the product. Let’s not dwell here on the definition of Scrum. More details can be found in the official guide.

The only thing you need to know is the criteria which can be discussed and checked together with the team. This will help you understand whether you and your stakeholders are comfortable working with the framework.

Scrum criteria as the basis for teamwork:

• Product development can be broken down into meaningful stages with tangible business value at each stage.
• Operating in an environment of high uncertainty without knowing what practices and tools might work.
• Defining each sprint as an experiment — product-, team-specific, organizational.
• Having product hypotheses that involve the entire team. Understanding the metrics that are affected by the team.
• Organizing the team around one single goal for the sprint.
• Product tasks in the backlog prevail (80%+) over service tasks for other teams.
• A greater degree of autonomy for the team to make decisions and manage their backlog, i.e., what, when, why, and in what order should be developed.

What else could be used?

Recently, the Kanban method has been gaining popularity as a tool for managing intellectual work tasks and aligning processes within product teams. You can use all the practices of this method, some of them, or only one as the context may require. There is no firm definition of what constitutes the Kanban method, nor is there any cutoff point that determines whether the task is being processed according to the Kanban method. Read more about the relevant practices in this guide.

Let’s move on to see how we apply Kanban practices in our product and service teams.

Kanban can be applied to the following cases and needs:

• The need for visualizing invisible knowledge work.

• The need for workflow alignment.

• The need for eliminating bottlenecks for the workflow and employees.

• The need for value delivery to be predictable.

• Complex organizational conditions and the need to start somewhere right now.

• Clear stressors and motivators for change, e.g., dissatisfied management, customers, or teams.

  
  

If the organization is not prepared to make an abrupt shift to agile practices (e.g., scaling frameworks) or widely used agile approaches are not a good fit for it, the Kanban method offers an alternative approach to organizational agility.

What essential elements are required to start using Kanban?

The Kanban method greatly increases the productivity of teams faced with a constant stream of new tasks. This system is used in a variety of areas from construction to IT. Even though it’s recommended to adopt all six core practices of Kanban, I have singled out visualizing the workflow and making workflows explicit as the two most valuable practices for beginners. To begin with, I will tell you about the first practice.

Visualizing the workflow

There are several options for visualizing the Kanban workflow. The most popular of these is a web-based task board. It's important to take into account what information you use on the Kanban board for decision making. Ideally, the Kanban cards should fit and meet the needs of the context. Example: If you need to track task completion times, the card should reflect the deadlines.

Why visualization is required:

• To identify hidden work and visualize the full scope of tasks the team is working on.
• To display the blocking tasks that cannot be worked on.
• To figure out what types of work are being done.

For example, different colored cards for tweaks and tech debt. To determine the amount of work at each stage and visualize the task assignees. Note that in today's world, a physical board is hardly ever used. Below I'll share with you what visualization tools we use at inDrive.

1. Wrike. Wrike is a convenient tool to create a space for the work of a particular division, as well as keep track of deadlines and assigned employees. You can create a color flag, prioritize tasks, make a checklist, or assign multiple employees to a task.

   

   
   

2. Jira. This tool is a great choice for teamwork in software development. You can use it to capture changes in code, build roadmaps, and generate detailed reports in the form of metrics and graphs, as well as to create a backlog list.

Making process policies explicit

You have to clearly establish the rules and make them transparent for each team member so as to minimize human-factor issues. They should be simple, clear, precisely articulated, flexible, and applicable in all settings.

It’s a good idea to start off with simple rules and make improvements as needed. It's important to understand that the rules evolve and change during the process. Some examples of basic rules are described below:

• Arrangements for scheduled completion times.
• Readiness criteria (When can a task be considered completed?)
• Criteria for moving between statuses (When can a work item move from one status to another?)
• Prioritization criteria (Which tasks are considered priority tasks?)
• When do you need to add to the backlog?
• How long can work items stay in a column?
• Adding when selecting new tasks.

The rules should be established and followed to enable the team to operate independently. Discussing and setting up agreements is part of the STATIK strategy.

This approach is used to implement a Kanban system or find the current growth points. The following example is a step-by-step breakdown of the STATIK workshop within our Localization Team.

Description of the system via STATIK

What is this? The System Thinking Approach to Introducing Kanban (STATIK) is a strategy for making it easier to implement a Kanban system. This is a workshop in which you have to go through certain steps: assess project tasks, problems and expectations, priorities of tasks.

Why is this needed? STATIK is conducted by different people: process, project and team managers who intend to change a process or implement a Kanban system. Typically, teams want to figure out how Kanban can affect the process and how to design their first Kanban system.

The format. This is a workshop with facilitation and discussion arrangements that takes from one to several days. You don't have to do it all in one go, and it’s okay to break it down into short sessions of two hours each. It’s best to keep the intervals between sessions short, as the team must maintain concentration throughout the period, because this is the only way to achieve the desired results.

STATIK includes eight key steps, but we skipped some of them and tweaked the workshop a bit to suit our own needs. Below, I will describe in detail how I conducted the workshop for our Localization Team. The goal was to achieve process transparency and find points of improvement.

Workshop for our Localization Team

Our Localization Team is responsible for translating and localizing the inDrive app into different languages. We split up this workshop into two 120-minute sessions, held one week apart, to make sure the entirety of the learning material is well retained. Below I will provide a step-by-step description of each stage along this journey. The first session included steps 1-4, and the second one included steps 5-7.

Step One. What is STATIK?

Duration: 10-15 minutes.

The facilitator describes the context for the team: sets out the purpose of the workshop, explains the theory, and establishes the ground rules together with the team, if necessary. The format used in my case:

• What is STATIK? What is its purpose and what does it accomplish?
• When is this strategy used and what for?
• What are the steps to be taken?
• What will we do during the workshop?
• I established the ground rules for participants: participate, actively engage in discussion and activities, be present here and now. I emphasized the benefits of the workshop and why it was worth taking.

Step Two. Ice-Breaker

Duration: 10-15 minutes.

Assignment: Upload a meme or a picture that answers the question: "What does our process look like?"

It took 3-4 minutes to gather information, then every participant described their chosen option and shared what the processes within the team meant to them.

Step Three. Sources of dissatisfaction

Objective: Identify points of growth and raise awareness as to why the team needs to change.

Duration: 20-25 minutes.

Format: The team is seen as a boat being weighed down by an anchor. This makes it easier to seek out and get rid of the hidden sources of discontent. Divide the board into two sections: write internal sources on the left-hand side and external sources on the right-hand side.

Assignment:

1. Describe your team's internal sources of dissatisfaction.
2. Describe your customer’s external sources of dissatisfaction.

Note: It took us a long time to complete this assignment because we were describing external and internal sources of dissatisfaction separately. To save time, it’s best to fill out and discuss both columns at once. The problems collected were dealt with in more detail in a retrospective.

Step Four. Demand and capability analysis

Duration: 40 minutes.

Objective: To assess how much the service is in demand and what types of input tasks are processed. Format: Identify the work by type.

Assignment: Write on stickers the tasks the team is currently working on.

1. Where does the workload come from?
2. What is the customer asking for?
3. For each type of work, we analyze the speed at which the task is input, the nature of the workload, and customer expectations.

Note: The assignment was done with the team as a whole, without participants being divided into subgroups.

Step Five. Life cycles of different types of work

Duration: 35 minutes.

Objective: To understand the stages of a task, as well as how we accumulate knowledge about it, and deliver value.

Format: Put together a complete path of knowledge acquisition that would lead to a finished work-type item. In our case, to avoid time constraints, we chose two types: the most common and the longest.

Assignment:

5 minutes — choose the longest and the most frequent types of work.

15 minutes — combine and break down into stages, as per the current practice. The current statuses can be opened.

10 minutes — how do you figure out the principle according to which the tasks are moved on to the next stage? Definition of Done, triggers for each status.

Here it’s important to look not only at your team, but also to consider the time points before and after. For example, what is the status of the work task when it gets to us?

Note: This stage of the workshop was run as a separate session. Before we got started, we spent 7-10 minutes reviewing the previous session and going back through the key training points.

Step Six. Classes of services

Duration: 20 minutes.

Objective: To understand how we work with tasks

Format: Joint teamwork, distribution of task types by class of service.

Assignment:

10 minutes — ask the team to provide examples for all types of queries in their specific situations:

Fast-track. Work tasks so urgent that they require immediate action and any other work has to be put aside.

Fixed delivery date. Work tasks which, if not completed by a specific date, result in the imposition of a substantial penalty that is not commensurate to any benefit from early delivery.

Standard. Work tasks to be performed as per the procedure agreed upon with the customer.

15 minutes — distribution of task types, class of service required.

Note: What risks do you have associated with different types of queries? What is the cost of delay?

Step Seven. Kanban system design

Objective: To record the next steps, what data we will enter into the system and when.

Format: To assess what we have achieved.

Questions for discussion:

• What does a Kanban board with work tasks look like?
• Does it have enough space?
• How are the work tasks progressing within the interval from one project meeting to the next?
• Does the Kanban board make sense to those who will be using it?

A good Kanban board ensures transparency. It’s important to improve the flow of work and change the board to make sure that the system itself is changed as a result.

Note: We didn’t have enough time to go through this step together during the workshop. For this reason, I separately suggested further steps for improvement, and after the workshop, the team and I discussed what and when we would start implementing them.

The conclusions and results

1. Scrum is based on an iterative-incremental approach, a commitment to continuous learning, and adaptation to change. This strategy is most effective for small teams that create or improve a product in an uncertain environment.

2. The Kanban method focuses on the continuous delivery of value. You can use all the practices of this method, some of them, or only one, as there is no firm definition of the Kanban method.

3. Visualization as the backbone of Kanban helps you see the big picture and the individual parts that comprise it.

4. STATIK is an awesome workshop that covers a sequence of actions to be implemented for launching a new Kanban system or improving your existing one.

   
   

In the next part of the article, I'll tell you about how we assess work tasks and conduct events, and what metrics we monitor, as well as how we apply classes of service. A huge thank you to Daniil Korotkov for preparing this material and for sharing his expertise. I'll be happy to answer your questions in the comments :)

Also Published Here