July 22, 2014 at 18:13Kanban Methodology: Introduction
Good afternoon!
One of my professional interests as the coordinator of the testing team is software development methodologies. Currently, the so-called Agile methodologies, especially Scrum and Kanban, are gaining more and more popularity. Unscrupulous “trainers” play on “common” terms, seminars and certifications (“certified Scrum-master”, “certified Product owner”, etc.) are growing by leaps and bounds.
In most unscrupulous articles and trainings, any methodology is presented as a magic silver bullet that instantly solves communication problems and immediately saves individual team members from incompetence. In general, it will help you solve your problems. This year, I am enrolling in the master's program at Belarusian State University with a degree in HR technology and plan to consider in detail the pros and cons, as well as the limitations of the applicability of the most common software development methodologies.
In the process, I often came across a misunderstanding and incorrect interpretations of the methodology tools, the use of fashionable methodology without taking into account the context. After reading the articleI realized that the problem is more global than local. I propose today to consider a little Kanban, its history, basic principles, and possible boundaries of application.
Kanban is a Japanese term that began to be used in relation to production in the 60s of the 20th century at Toyota. This principle is based on the conveyor production method, as well as various speeds 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 main conveyor sets the production rate of the final products, while additional conveyors cannot accelerate the production rate of the product, but can slow it down if the required parts are not delivered on time.
Additionally, a priority shift may occur during production. For example, it turned out that the station that produced the left mirrors produced 20 pcs., And the station that produced the right mirrors - 10 pcs., While there are 15 cars on the conveyor and 15 pieces of mirrors of both types are needed. There is a conflict of metrics - quantitatively, production has not fallen (additional conveyors have released 30 products on time), but production still risks stopping. Kanban aims to help with this problem.
In a simplified version, Kanban includes two simple rules:
Recently, Kanban is gaining great popularity in software production. Some teams find this methodology extremely useful, some use the principle of the "Cargo cult." Based on my empirical experience, pure Kanban doesn’t work well for product teams (read the “main pipeline”), but works great 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 the use of 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 limit for 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 (hosting has broken, the necessary framework has not been downloaded, etc.). In the general case, the blocked work is returned to the backlog, and a new task is selected with the highest priority. Depending on the nature of the tasks and the type of team, the limit can be increased or decreased. For example, our developer can simultaneously draw up a registration form and watch the process of deploying a new server. However, if the completion time is less than required, the project manager can reduce the limit, or increase the team. Thus, with competent leadership, Kanban provides the maximum possible speed for this team, the maximum speed of response to changes and at the same time reduce the "costs" of supporting the methodology. Well, that's all! Kanban is not easy simply. It is very easy!
Kanban’s limitations when using it in product teams include:
In conclusion, I want to add that a comparison of any methodology on the principle of "who is cooler" is not productive and counter-constructive (captain evidence). Each, more or less common, methodology has its pros, cons, and application limits. Additionally, Agile methodologies, in principle, place great demands on the harmony and experience of team members.
In case of interest in the topic, I will continue to review Kanban in more detail. Later, I propose to make out on shelves and pictures Scrum and RUP.
In more detail, and clearly can be found in:
One of my professional interests as the coordinator of the testing team is software development methodologies. Currently, the so-called Agile methodologies, especially Scrum and Kanban, are gaining more and more popularity. Unscrupulous “trainers” play on “common” terms, seminars and certifications (“certified Scrum-master”, “certified Product owner”, etc.) are growing by leaps and bounds.
In most unscrupulous articles and trainings, any methodology is presented as a magic silver bullet that instantly solves communication problems and immediately saves individual team members from incompetence. In general, it will help you solve your problems. This year, I am enrolling in the master's program at Belarusian State University with a degree in HR technology and plan to consider in detail the pros and cons, as well as the limitations of the applicability of the most common software development methodologies.
In the process, I often came across a misunderstanding and incorrect interpretations of the methodology tools, the use of fashionable methodology without taking into account the context. After reading the articleI realized that the problem is more global than local. I propose today to consider a little Kanban, its history, basic principles, and possible boundaries of application.
Term history
Kanban is a Japanese term that began to be used in relation to production in the 60s of the 20th century at Toyota. This principle is based on the conveyor production method, as well as various speeds 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 main conveyor sets the production rate of the final products, while additional conveyors cannot accelerate the production rate of the product, but can slow it down if the required parts are not delivered on time.
Additionally, a priority shift may occur during production. For example, it turned out that the station that produced the left mirrors produced 20 pcs., And the station that produced the right mirrors - 10 pcs., While there are 15 cars on the conveyor and 15 pieces of mirrors of both types are needed. There is a conflict of metrics - quantitatively, production has not fallen (additional conveyors have released 30 products on time), but production still risks stopping. Kanban aims to help with this problem.
In a simplified version, Kanban includes two simple rules:
- The production station has a parts production plan (“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 right mirrors as soon as possible);
- the number of tasks performed at the station is simultaneously limited (i.e., to produce no more than a given number of mirrors at a time). This limitation is necessary to control the speed of production at the plant, as well as the speed of response to changes in the plan.
Present
Recently, Kanban is gaining great popularity in software production. Some teams find this methodology extremely useful, some use the principle of the "Cargo cult." Based on my empirical experience, pure Kanban doesn’t work well for product teams (read the “main pipeline”), but works great 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 that work separately from development groups;
- 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 the use of 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 limit for tasks in the process is 1 pc.
To manage the process, the project manager can:
- change the limit on the number of tasks in work;
- add a task with a higher priority (for example, p0) so that it is taken as soon as possible;
In the process of work, it may happen that the work is blocked (hosting has broken, the necessary framework has not been downloaded, etc.). In the general case, the blocked work is returned to the backlog, and a new task is selected with the highest priority. Depending on the nature of the tasks and the type of team, the limit can be increased or decreased. For example, our developer can simultaneously draw up a registration form and watch the process of deploying a new server. However, if the completion time is less than required, the project manager can reduce the limit, or increase the team. Thus, with competent leadership, Kanban provides the maximum possible speed for this team, the maximum speed of response to changes and at the same time reduce the "costs" of supporting the methodology. Well, that's all! Kanban is not easy simply. It is very easy!
Kanban’s limitations when using it in product teams include:
- this methodology does not work well with large teams (more than 5 people);
- in its purest form, Kanban does not work well with cross-functional teams. Those. unlike Scrum, it’s hard to combine testing and development in one team. A better idea is to break down the process into a “development” station and a “testing” station with separate managers and backlogs;
- Due to its history and specifics, Kanban is not intended for long-term planning.
Conclusion
In conclusion, I want to add that a comparison of any methodology on the principle of "who is cooler" is not productive and counter-constructive (captain evidence). Each, more or less common, methodology has its pros, cons, and application limits. Additionally, Agile methodologies, in principle, place great demands on the harmony and experience of team members.
In case of interest in the topic, I will continue to review Kanban in more detail. Later, I propose to make out on shelves and pictures Scrum and RUP.
In more detail, and clearly can be found in:
- Kanban article on Wikipedia.org ;
- excellent book “SCRUM and KANBAN: squeeze the maximum”, Henrik Kniberg and Matthias Skarin.