Get best of the week

Kanban Method: Understanding Your Process as a Collective Learning Process

Foreword


In the Russian-speaking professional community of process managers, there is very little literature on the Kanban method in Russian. We decided to correct this injustice and we will publish the most significant articles from our point of view in Russian, which influenced the development of the method.

Understanding your process as a collective learning process


And the first article in the series on how to more efficiently build a visualization of your work processes and perceive a board. The author of the original article is Alexei Zheglov and can be found here.

There is a general trend and desire to make the work more collective. However, when I ask people in the office to draw a process of their work, they often provide something like this (I simplify):


In this view, workers form a conveyor belt, but their work does not really look like an assembly line. For example, a software developer can detect a logical inconsistency in the requirements specification and send the work back to business intelligence. A quality engineer (QA) can do the same when testing created software. The analyst will update the specification and send the task back to QA. QA can find an error in it and send it back to the developer. An implementation specialist might find something in the code that is preventing delivery. Then the developer makes the necessary changes. Now the code needs to be re-tested, so it returns to QA, after which it returns to implementation.

Such interaction occurs not only between individual team members, but also (importantly) between corporate departments, services and cross-functional teams. Therefore, people draw a lot of arrows connected in different configurations to show all these programs.

Some are trying to visualize this process on a board that they call "kanban":


Then they ask themselves: What if, for example, the tester returns the work item back to the analyst or developer? Should the card stay in place or move? What if we have a WIP limit (these numbers are in the column headers)? What if this column is already filled to the limit, another card should go back?

Is there a better way?


This question is quite common and rooted in a misunderstanding of the nature of professional service work. Instead of a series of transmissions between specialized jobs, it is mainly about creating information and accumulating knowledge. This becomes an obstacle when trying to make the process look like a flowchart. As well as a limitation when trying to visualize it, following the execution of the work.

In the example of delivering new functionality of a software product, the following knowledge can be created (not necessarily in this order):

  • exact configuration of the working environment (OS, web server, database server, third-party software)
  • key examples of the behavior of the developed functionality, use cases, acceptance criteria, executable specifications, etc.
  • ( , . .)
  • -
  • : , , ..
  •   , .

Everyone in any professional service can come up with their own list of knowledge that they create in their delivery process. When the work is completed, all this knowledge already exists, but when we are just starting to work on the needs of the client or the request for the supply of something, this is all missing.

If we tried to visualize the process of accumulating this knowledge, the result could look like this:


In this example, specification work is dominant at an early stage in the delivery process. Business analysts can conduct a functional analysis, decomposition, and refinement of requirements. But at the same time, other professionals can contribute. Testers can help turn acceptance criteria into executable tests. Deployment specialists and developers can evaluate the impact on the codebase and infrastructure.

This activity generates a lot of knowledge at the very beginning, but in the end it fades. We cannot analyze endlessly all the way to delivery. Thus, the development of code at some point becomes the main way of accumulating knowledge.

Of course, most of the code development falls on the shoulders of the developers, but others can help too. Requirements may still need clarification and clarification (hello analyst). The tester can take partially ready-made software, test it and give feedback to the developer. Developers can collaborate with implementation specialists to see how emerging changes will impact deployment.

But this activity will fade. We cannot make further progress by polishing the code. So, we move on to testing it.and focus on resolving any remaining errors. Another activity in the study of knowledge begins to dominate. Testers are responsible for it, but they need help from developers, bug fixes, as well as other specialists.

Note that the three tipping points in the new process diagram are not transfers between functional specialists or departments. These are changes in dominant activity and corresponding changes in the pattern of interaction.

Conclusion


We do not need to consider processes as a network of specialists and the transfer of authority. When we try to visualize our processes visually, we do not need to represent them in the form of blocks depicting specialists, and many arrows connecting them in all directions.

Instead, we can view our delivery process as obtaining information and creating knowledge. Asking ourselves the question, what actions do we perform in order to accumulate knowledge in order to deliver what we deliver , we can visualize our process as a sequence of joint actions.

What's next?


In the next few articles, I would like to give examples of the reflection of the process of knowledge accumulation, for processes outside the world of software development.

I need to prepare a number of articles, as recommendations: how a process specialist can compose a reflection of processes with professional services teams . For those who use Kanban systems, this approach has several advantages in the design and operation of these systems.

Many thanks to Aleksey Pimenov andStepev.

More articles:


All Articles