Kanban Methodology: Introduction
Good day!
One of my professional interests as a coordinator of a team of testers are software development methodologies. Currently, so-called Agile methodologies are becoming increasingly popular, especially Scrum and Kanban. Unscrupulous "trainers", seminars and certifications ("certified Scrum-master", "certified Product owner", etc.) are growing by leaps and bounds in “open” terms.
In most unscrupulous articles and trainings, any methodology is presented as a magic silver bullet that instantly solves the problems of communication, at once will save individual team members from incompetence. In general, it will help you to solve exactly your problems. This year I am enrolling in the magistracy of the Belarusian State University with a degree in personnel management technology and I plan to examine in detail the pros and cons, as well as limitations on the applicability of the most common software development methodologies.
In the course of my work, I often encountered misunderstanding and misinterpretation of the tools of methodologies, the application of fashionable methodology without taking into account the context. After reading the article, I realized that the problem is global rather than local. I propose today to consider a little Kanban, its history, basic principles, and possible limits of application.
')
Kanban is a Japanese term that began to be used in relation to production in the 60s of the 20th century in Toyota. The basis of this principle is the conveyor method of production, as well as the various speeds of execution of individual technological operations in production. I'll try to explain on the fingers. In any production there is a main production (“main conveyor”) and additional production (“additional conveyors”). The rate of production of final products sets the main conveyor, while additional conveyors can not accelerate the rate of production of the product, but can slow it down, in case of late release of the required parts.
Additionally, during production, a change of priorities may occur. For example, it turned out that the station that produced the left mirrors produced 20 pieces, and the station that produced the right mirrors - 10 pieces, while there are 15 cars on the conveyor and 15 pieces of both types of mirrors are needed. There is a conflict of metrics - quantitatively, production did not fall (additional conveyors released 30 products on time), but production still risks stopping. Kanban is designed to help with this problem.
In a simplified form, Kanban includes two simple rules:
Recently, Kanban is gaining great popularity in software production. Some teams consider this methodology to be extremely useful, some use the principle of the "cult of cargo". Based on my empirical experience, pure Kanban does not work well for product teams (read, “main pipeline”), but it works fine with support teams, such as:
Separately, it should be noted that Kanban works well in startups that do not have a clear plan, but are actively working on development. I propose to consider an example of using Kanban in software development. I apologize in advance for the ugly illustrations. Let's imagine a team of one developer working on a small project. The development plan (backlog) is sorted in order of priority of pieces of work, the team’s limit on tasks in the process is 1 pc.
To manage the process, the project manager can:
In the process of work, it may happen that the work is blocked (the hosting is broken, the required framework is not downloaded, etc.). In general, a blocked job is returned to the backlog, and a new task is selected, with maximum priority. Depending on the nature of the tasks and the type of team, the limit may be increased or decreased. For example, our developer can simultaneously draw a registration form and watch the process of deploying a new server. However, if the task completion time is less than required, the project manager can reduce the limit, or increase the team. Thus, with proper guidance, Kanban provides the maximum possible speed for this team, maximum response to changes and at the same time reduce the “costs” of supporting the methodology. Well, that's all! Kanban is not easy, simple. It is very easy!
The limitations of Kanban when using it in product teams include:
In conclusion, I want to add that the comparison of any methodologies according to the “who is better” principle is not productive and counter-constructive (the captain is obvious). Each, more or less common, methodology has its own advantages, disadvantages and limits of application. Additionally, Agile-methodologies, in principle, impose large demands on the harmony and experience of team members.
If you are interested in the topic, I will continue to consider Kanban in more detail. In a consequence, I suggest to sort on shelves and pictures Scrum and RUP.
In more detail, and visually you can see in:
One of my professional interests as a coordinator of a team of testers are software development methodologies. Currently, so-called Agile methodologies are becoming increasingly popular, especially Scrum and Kanban. Unscrupulous "trainers", seminars and certifications ("certified Scrum-master", "certified Product owner", etc.) are growing by leaps and bounds in “open” terms.
In most unscrupulous articles and trainings, any methodology is presented as a magic silver bullet that instantly solves the problems of communication, at once will save individual team members from incompetence. In general, it will help you to solve exactly your problems. This year I am enrolling in the magistracy of the Belarusian State University with a degree in personnel management technology and I plan to examine in detail the pros and cons, as well as limitations on the applicability of the most common software development methodologies.
In the course of my work, I often encountered misunderstanding and misinterpretation of the tools of methodologies, the application of fashionable methodology without taking into account the context. After reading the article, I realized that the problem is global rather than local. I propose today to consider a little Kanban, its history, basic principles, and possible limits of application.
')
History of the term
Kanban is a Japanese term that began to be used in relation to production in the 60s of the 20th century in Toyota. The basis of this principle is the conveyor method of production, as well as the various speeds of execution of individual technological operations in production. I'll try to explain on the fingers. In any production there is a main production (“main conveyor”) and additional production (“additional conveyors”). The rate of production of final products sets the main conveyor, while additional conveyors can not accelerate the rate of production of the product, but can slow it down, in case of late release of the required parts.
Additionally, during production, a change of priorities may occur. For example, it turned out that the station that produced the left mirrors produced 20 pieces, and the station that produced the right mirrors - 10 pieces, while there are 15 cars on the conveyor and 15 pieces of both types of mirrors are needed. There is a conflict of metrics - quantitatively, production did not fall (additional conveyors released 30 products on time), but production still risks stopping. Kanban is designed to help with this problem.
In a simplified form, Kanban includes two simple rules:
- the production station has a production plan for the parts ("backlog"). The plan is sorted by priority, and can change at any time (for example, a station producing too many left mirrors should be able to switch to the right as soon as possible);
- the number of tasks performed at the station at the same time is limited (i.e. to produce no more than a specified number of mirrors at the same time). This restriction is necessary to control the production rate at the plant, as well as the speed of response to plan changes.
Present tense
Recently, Kanban is gaining great popularity in software production. Some teams consider this methodology to be extremely useful, some use the principle of the "cult of cargo". Based on my empirical experience, pure Kanban does not work well for product teams (read, “main pipeline”), but it works fine with support teams, such as:
- software support groups, where the “plan” is not important, but the speed of response to changes is important;
- testing groups operating separately from development teams;
- support services;
- other examples of "non-core industries".
Separately, it should be noted that Kanban works well in startups that do not have a clear plan, but are actively working on development. I propose to consider an example of using Kanban in software development. I apologize in advance for the ugly illustrations. Let's imagine a team of one developer working on a small project. The development plan (backlog) is sorted in order of priority of pieces of work, the team’s limit on tasks in the process is 1 pc.
To manage the process, the project manager can:
- change the limit on the number of tasks in the work;
- add a task with a higher priority (for example, p0) in order for it to be taken as soon as possible;
In the process of work, it may happen that the work is blocked (the hosting is broken, the required framework is not downloaded, etc.). In general, a blocked job is returned to the backlog, and a new task is selected, with maximum priority. Depending on the nature of the tasks and the type of team, the limit may be increased or decreased. For example, our developer can simultaneously draw a registration form and watch the process of deploying a new server. However, if the task completion time is less than required, the project manager can reduce the limit, or increase the team. Thus, with proper guidance, Kanban provides the maximum possible speed for this team, maximum response to changes and at the same time reduce the “costs” of supporting the methodology. Well, that's all! Kanban is not easy, simple. It is very easy!
The limitations of Kanban when using it in product teams include:
- This methodology does not work well with large teams (more than 5 people);
- In its pure form, Kanban does not work well with cross-functional teams. Those. unlike Scrum, it’s hard to combine testing and development on the same team. A better idea is to break up the process into a “station” of development and a “station” of testing with individual managers and backlogs;
- Due to its history and specificity, Kanban is not intended for long-term planning.
Conclusion
In conclusion, I want to add that the comparison of any methodologies according to the “who is better” principle is not productive and counter-constructive (the captain is obvious). Each, more or less common, methodology has its own advantages, disadvantages and limits of application. Additionally, Agile-methodologies, in principle, impose large demands on the harmony and experience of team members.
If you are interested in the topic, I will continue to consider Kanban in more detail. In a consequence, I suggest to sort on shelves and pictures Scrum and RUP.
In more detail, and visually you can see in:
- the Kanban article on Wikipedia.org ;
- excellent book “SCRUM and KANBAN: squeezing the maximum”, Henrik Knbergberg and Matthias Skarin.
Source: https://habr.com/ru/post/230725/
All Articles