How to use Kanban for convenient work of not only managers, but also programmers
Kanban is a management methodology that is used about 10 times less frequently than Scrum, but this does not make it any less interesting. It is based on the presentation of the process of the whole organization as a set of interrelated services, which ultimately are a service for the end user.
Kanban is especially easy to implement since the top management and is perfectly combined with the theory of restrictions, presented in the book “The Goal” to Eliyahu Goldrath . Kanban is chosen for itself by technical support departments, system administrators, and even HR managers and accountants who work closely with IT.
One of the main distinguishing features is the principles of Kanban implementation: “Start with what you have, visualize the process, agree on an evolutionary change in the processes.”
')
Note that this is not about loudly announcing the introduction of Kanban, but only about how to change the processes of evolution towards improvement. You probably thought: “It doesn't sound scary. Who will refuse such a thing? Nevertheless, to achieve significant results from the point of view of business without major changes will not work.
Following the innocent phrase “let's agree on an evolutionary change of processes” there can be many different proposals. And if the implementing kanban is experienced enough, it will all go very carefully. Below are described the benefits for which it is worth implementing kanban and practices that can be used to improve processes.
No one will teach programmers to program faster using these methods, naturally. But most of the time, tasks are more likely to be in the queue or blocked for one reason or another, and sometimes they are simply forgotten in the thick of unfinished business. With the introduction of order in the tasks of kanban can quite cope.
In our time, when the interest in the word Agile, to put it mildly, is overheated, it may not be assumed initially. But still, even if it was started with the aim of fulfilling the assignments, it is still possible to benefit from the implementation.
1) Kanban is designed to increase the transparency of processes within the organization.
How often does it happen that people do not understand how the processes are organized in the part of the company with which they have to interact, but which performs a different function? For example, how many marketers know about the work of programmers? And programmers about the work of marketers?
Ignorance of the organization of the processes of another division often causes illusions and disregard for the work of others, in such conditions it becomes more difficult to establish contact, and departments may even turn into warring states.
2) Kanban helps fight "multitasking" in its worst manifestations.
Somewhere on the courses they teach “effective managers”, who then do it themselves and advise others if the task does not exceed 5 minutes, postpone what you are doing right now and do a short task in order to permanently get rid of a small ballast, and then return to the main But the most shrewd customers are starting to present each task as super-small and requiring such a priority approach.
3) Kanban allows you no longer to assess the timing of a specific task.
Instead, it is supposed to use statistical methods. Imagine that you measure the diameter of the cross section of a water pipe and the flow rate, rather than predicting how quickly a particular drop (even if marked with a blue dye) will fly through the pipe from point A to point B.
Unlike Scrum, the introduction of which is associated with a number of rituals, the introduction of Kanban occurs much more smoothly and imperceptibly. However, it also gives a lower economic effect at first, as a simple board, no matter how beautiful it is, is still not a kanban implanted.
Kanban Board of the organization as a whole and the lower level boards associated with it for divisions. It is an important attribute, but its presence does not yet guarantee the availability of flexible thinking and the presence of any methodology in the management of an organization. Many implementations in Russia end at this stage, however, you can also see many implementations of the scram, of which only sprints managed to earn.
1) Determine which states your typical task actually goes through. The option “anger, despair, bargaining, depression, acceptance”, of course, is not accepted, but it sounds amazingly often.
For example, these may be the following columns for the overall IT process (strategic level):
In line | In work | Analysis | Design | Design | Development | Testing | Display
Or such (for a dedicated division of UX-designers):
In line | In work | Layout | Prototype | Layout | Submitted to the development
And the second board can be a decoding of the word “Design” in the first board, when one card on a large board looks like a lot of small subtasks for a design in technical.
2) Spill and arrange a physical or virtual board. At the first stage, it is recommended to simply hang the marker or cork board on the wall and separate it with lines according to your intended process.
Physical movement of cards on the board instead of the electronic version gives a certain pleasure, although it gives inconvenience, especially to distributed teams. After 2-3 weeks, when you understand exactly what conditions your works actually have, you can switch to the electronic version.
This practice is an essential part of kanban, and without it, the economic effect is achievable with a much lower probability. In the practice of the author, the introduction of the limit always occurs with serious resistance, since the restriction on the tasks in each status is perceived intuitively as a restriction of the rights and freedoms of the working people, which in fact is certainly not the case.
1) discuss the blockages of unfinished tasks (if any) and decide to deal with them;
2) enter the restriction on the most collapsed column and only on it;
3) as soon as we begin to pay particular attention to some part of the process and eliminate the “blockage” in this place, then another bottleneck will become the bottleneck, find the new bottleneck and put a restriction on this column
(even if for this you have to convince the adjacent unit to get a kanban board too, why not) ;
4) consistently implement and squeeze the restrictions on the columns of the boards associated with the process you need, but not to the extent that people are out of work simply because of the rule, a small, reasonable stock of work in any status must remain.
The initiative to introduce this practice is best taken from the performers themselves, it is almost impossible to implement from above, but it's worth it. It is easy enough for a coach to persuade her to use people, showing her advantages in a Kanban simulation game.
Despite the fact that the name translates as an agreement, in fact it is an element of statistics, indicating how quickly the tasks were performed on average and, in connection with this, to build realistic expectations.
But, unlike statistics, this level may include a small margin when communicating it to internal or external customers.
1) Calculate by statistical methods, how much time on average passes from setting the task to the queue by the customer (internal or external). And also, in what time interval the fastest 10% (let's call it X), and in what only 90% (we call it Y), met it. Calculate also the time Z for “long-term construction”, how long the longest tasks took.
2) Take an X and add Y to it, and you will get realistic deadlines for completing 90% of tasks, even if customers “run in” with urgent orders that cannot wait for the specified deadline and move your tasks back. We tell you a secret that they probably come with urgent tasks and now, too, in a special order. The author is aware of a case of “internal corruption”, where a violation of priorities cost a cup of coffee or chocolate, some talk about real money paid.
3) Agree with the customer (it does not matter, internal or external) that in a normal situation a task is processed during X + Y, and only 10% of tasks can be performed extremely long for one reason or another, up to time Z.
In fact, we cheated a little by telling you about the service classes a couple of paragraphs higher, but not naming them. This name sounds too complicated and sometimes frightening, but the approach itself is an essential part of introducing Kanban to provide flexibility in working with internal and external customers.
To discuss this opportunity, write an official letter and add a line separation to the board, it is usually called Swimlines, and if in Jira there were no problems with this in the old version, then in Asana it seems without additional scripts that is impossible.
In the Kanban materials, the authors rarely honestly say that this role is needed rather to not dismiss the Product Owner when moving from the Scram, but in this position (SRM) there is no particular need if there are no problems with getting assignments from the customer. This role can be useful for those teams that suffer from the lack of a “single point of entry” in grocery companies. Then this person can establish formal policies and deal with the incoming queue, but this is not exactly intended as a full-time job. Alternatively, you can have one manager request for several teams and turn the former project manager or development team leader into it (in general, the one who was left without extra work in the new process).
Service delivery manager is a much stronger role, and it is often the project manager who is most often assigned to it, as someone who is initially needed to get things done. In the presence of a manager’s manager, in most cases, the role of the request manager is practically unnecessary, although formally they provide dual power, the request manager is engaged in tasks that have not yet decided whether to do it or not, and the manager’s manager will have those that already need to be done and brought to the end.
There are many such meetings in kanban, even too many. Various meetings from daily to delivery planning meetings and and planning for filling the queue (analogous to the planning of the sprint in the scram).
On stand-ups, unlike scram, much more pleasant questions for performers are discussed. It is not necessary to remember painfully what you did yesterday, it’s enough to look at the board together with everyone and determine what prevents each task from right to left to move to the right, and what it can prevent
How to work not to go into formalism and following the rules to the detriment of the product?
This is where the Operations Review meeting, which differs from the agile retrospectives, is very helpful because it considers the processes in the organization as a whole, so as not to engage in local optimization at retrospective meetings of each team, since according to the same theory of constraints, local optimization is more likely to harm performance organization, what helps her.
Provide yourself technical support engineers who, without increasing staff and other external signs of a problem, more and more efficiently and quickly respond to the growing number of complaining users, but since they need to respond quickly, do not pass the information to the development team. Imagine this is not difficult, this happens in technical support of a huge number of Russian and foreign companies. No matter how efficiently, quickly, and beautifully they answered, if they do not signal the source of the problem, then the problem is more difficult to detect and correct, and it will be more difficult for them to compare with the increasing load.
At this meeting, which does not occur exactly once every 2 weeks, but occurs exactly when there are any problems with delivery or uncertainty, for example, in marketing, you can conduct a review of what is more ready to be completed and choose those tasks which are more priority for the nearest delivery.
Honestly, there was never any particular need for the author’s teams, this problem was more likely to be overcrowded due to the large number of customers, but nevertheless the need for this meeting is easy for those who have ever made a product from scratch and remembers a fresh project for example in Jira. At such a meeting, you can create jointly top-priority tasks across a product or even organization. With the decomposition on the technical level, engineers will perfectly cope.
There is a standard set of product metrics: revenue, profit, ARPPU (average rate per paying user), slightly more unloved ARPU (average rate per user, which takes into account revenue in terms of all users, not just paying) and others. These metrics are very useful for any process in a grocery company, slightly different, but very similar for an outsourcing one. But this of course concerns the strategic level.
At the level of functional units, it is important to introduce those metrics or their indirect projections that will really direct the process in the right direction. And this is not always the average number of tasks performed per day, or the time over which tasks are done on average. Although these metrics are proposed by default in kanban, the process should be a priori adapted to the needs of a specific internal and external customer. Only in this way can a company become a set of interrelated services for each other in order to provide services to the end customer.
The product manager's profession is similar to the startups, with the only difference that the product manager only has a salary and, if lucky, a percentage of the profits, but the startup starter does not have a salary, but the potential profit belongs to him completely (or in shares with partners).
Product managers exist in the company in order to develop individual products, take care of increasing their profitability and, in principle, do good for their customers through solving real problems of real people, rather than implementing the next set of ideas of the CEO, who can already have fantasy has long ended or there has never been a special vision for this particular direction.
Product managers are owners of budgets and formulate a strategy, including the types of services provided to the client and payroll budgets for the implementation of the plan. Product managers define key metrics that products must achieve. Units can be directly subordinated to the product manager, as well as the traditional matrix structure is possible, which is much worse for manageability and increases the load on the communications of certain people (heads of departments trying to do manual control).
The product manager can design the process he needs and set the metrics he needs. He can selectively use scrum or kanban or even fast waterfall in different parts of his process, because ultimately, any methodology is only a way to achieve the goal.
You can use cross-functional commands in a scram. You can even use a cross-functional scram command as a cell of a common kanban organization structure.
But do not directly oppose Kanban to Scrum and in a hurry to replace one with another. Kanban is best suited for service units, and not for cross-functional "combat" teams, each of which can do everything from marketing to technical support.
In cross-functional teams, it is better not to divide work into different types and not to create confrontation in the spirit of “this task is not in my column”, in divisions with the same function of employees and a large number of similar tasks, this approach will show itself well with less effort.
How to make the programmer, tester or any other engineer no longer tugged at the manager or any representative of related departments with the question "when will it be ready?"
It is enough to teach people to read the board and set tasks on the board. Indeed, in the view of many kanban = board , although this is actually not the case.
Usually, internal customers are delighted, and if you show them a team that uses all of the above methods, and some of them even implement kanban in their own unit, if they like the result, without waiting for any requirements from above, which makes it possible to run kanban as a virus management methodologies within medium-sized organizations.
In the author's practice, there was even a case of losing a client, since the kanban “finished” itself with the help of the specialists who started it in more detail, and the general director was removed from manual control of the processes, which made him satisfied.
Bibliography:
Kanban is especially easy to implement since the top management and is perfectly combined with the theory of restrictions, presented in the book “The Goal” to Eliyahu Goldrath . Kanban is chosen for itself by technical support departments, system administrators, and even HR managers and accountants who work closely with IT.
One of the main distinguishing features is the principles of Kanban implementation: “Start with what you have, visualize the process, agree on an evolutionary change in the processes.”
')
Note that this is not about loudly announcing the introduction of Kanban, but only about how to change the processes of evolution towards improvement. You probably thought: “It doesn't sound scary. Who will refuse such a thing? Nevertheless, to achieve significant results from the point of view of business without major changes will not work.
Following the innocent phrase “let's agree on an evolutionary change of processes” there can be many different proposals. And if the implementing kanban is experienced enough, it will all go very carefully. Below are described the benefits for which it is worth implementing kanban and practices that can be used to improve processes.
No one will teach programmers to program faster using these methods, naturally. But most of the time, tasks are more likely to be in the queue or blocked for one reason or another, and sometimes they are simply forgotten in the thick of unfinished business. With the introduction of order in the tasks of kanban can quite cope.
Benefits of implementation
In our time, when the interest in the word Agile, to put it mildly, is overheated, it may not be assumed initially. But still, even if it was started with the aim of fulfilling the assignments, it is still possible to benefit from the implementation.
1) Kanban is designed to increase the transparency of processes within the organization.
How often does it happen that people do not understand how the processes are organized in the part of the company with which they have to interact, but which performs a different function? For example, how many marketers know about the work of programmers? And programmers about the work of marketers?
Ignorance of the organization of the processes of another division often causes illusions and disregard for the work of others, in such conditions it becomes more difficult to establish contact, and departments may even turn into warring states.
2) Kanban helps fight "multitasking" in its worst manifestations.
Somewhere on the courses they teach “effective managers”, who then do it themselves and advise others if the task does not exceed 5 minutes, postpone what you are doing right now and do a short task in order to permanently get rid of a small ballast, and then return to the main But the most shrewd customers are starting to present each task as super-small and requiring such a priority approach.
3) Kanban allows you no longer to assess the timing of a specific task.
Instead, it is supposed to use statistical methods. Imagine that you measure the diameter of the cross section of a water pipe and the flow rate, rather than predicting how quickly a particular drop (even if marked with a blue dye) will fly through the pipe from point A to point B.
Useful tools that make kanban efficient
Unlike Scrum, the introduction of which is associated with a number of rituals, the introduction of Kanban occurs much more smoothly and imperceptibly. However, it also gives a lower economic effect at first, as a simple board, no matter how beautiful it is, is still not a kanban implanted.
Kanban board
Kanban Board of the organization as a whole and the lower level boards associated with it for divisions. It is an important attribute, but its presence does not yet guarantee the availability of flexible thinking and the presence of any methodology in the management of an organization. Many implementations in Russia end at this stage, however, you can also see many implementations of the scram, of which only sprints managed to earn.
Implementation Instructions:
1) Determine which states your typical task actually goes through. The option “anger, despair, bargaining, depression, acceptance”, of course, is not accepted, but it sounds amazingly often.
For example, these may be the following columns for the overall IT process (strategic level):
In line | In work | Analysis | Design | Design | Development | Testing | Display
Or such (for a dedicated division of UX-designers):
In line | In work | Layout | Prototype | Layout | Submitted to the development
And the second board can be a decoding of the word “Design” in the first board, when one card on a large board looks like a lot of small subtasks for a design in technical.
2) Spill and arrange a physical or virtual board. At the first stage, it is recommended to simply hang the marker or cork board on the wall and separate it with lines according to your intended process.
Physical movement of cards on the board instead of the electronic version gives a certain pleasure, although it gives inconvenience, especially to distributed teams. After 2-3 weeks, when you understand exactly what conditions your works actually have, you can switch to the electronic version.
Limit on the number of jobs in the process. (WIP Limit)
This practice is an essential part of kanban, and without it, the economic effect is achievable with a much lower probability. In the practice of the author, the introduction of the limit always occurs with serious resistance, since the restriction on the tasks in each status is perceived intuitively as a restriction of the rights and freedoms of the working people, which in fact is certainly not the case.
How to implement:
1) discuss the blockages of unfinished tasks (if any) and decide to deal with them;
2) enter the restriction on the most collapsed column and only on it;
3) as soon as we begin to pay particular attention to some part of the process and eliminate the “blockage” in this place, then another bottleneck will become the bottleneck, find the new bottleneck and put a restriction on this column
(even if for this you have to convince the adjacent unit to get a kanban board too, why not) ;
4) consistently implement and squeeze the restrictions on the columns of the boards associated with the process you need, but not to the extent that people are out of work simply because of the rule, a small, reasonable stock of work in any status must remain.
The initiative to introduce this practice is best taken from the performers themselves, it is almost impossible to implement from above, but it's worth it. It is easy enough for a coach to persuade her to use people, showing her advantages in a Kanban simulation game.
SLA - Service level agreement, or service level agreement
Despite the fact that the name translates as an agreement, in fact it is an element of statistics, indicating how quickly the tasks were performed on average and, in connection with this, to build realistic expectations.
But, unlike statistics, this level may include a small margin when communicating it to internal or external customers.
Implementation
1) Calculate by statistical methods, how much time on average passes from setting the task to the queue by the customer (internal or external). And also, in what time interval the fastest 10% (let's call it X), and in what only 90% (we call it Y), met it. Calculate also the time Z for “long-term construction”, how long the longest tasks took.
2) Take an X and add Y to it, and you will get realistic deadlines for completing 90% of tasks, even if customers “run in” with urgent orders that cannot wait for the specified deadline and move your tasks back. We tell you a secret that they probably come with urgent tasks and now, too, in a special order. The author is aware of a case of “internal corruption”, where a violation of priorities cost a cup of coffee or chocolate, some talk about real money paid.
3) Agree with the customer (it does not matter, internal or external) that in a normal situation a task is processed during X + Y, and only 10% of tasks can be performed extremely long for one reason or another, up to time Z.
Classes of services
In fact, we cheated a little by telling you about the service classes a couple of paragraphs higher, but not naming them. This name sounds too complicated and sometimes frightening, but the approach itself is an essential part of introducing Kanban to provide flexibility in working with internal and external customers.
How to implement?
To discuss this opportunity, write an official letter and add a line separation to the board, it is usually called Swimlines, and if in Jira there were no problems with this in the old version, then in Asana it seems without additional scripts that is impossible.
Role of the Query Manager (SRM)
In the Kanban materials, the authors rarely honestly say that this role is needed rather to not dismiss the Product Owner when moving from the Scram, but in this position (SRM) there is no particular need if there are no problems with getting assignments from the customer. This role can be useful for those teams that suffer from the lack of a “single point of entry” in grocery companies. Then this person can establish formal policies and deal with the incoming queue, but this is not exactly intended as a full-time job. Alternatively, you can have one manager request for several teams and turn the former project manager or development team leader into it (in general, the one who was left without extra work in the new process).
Delivery Manager Role (SDM)
Service delivery manager is a much stronger role, and it is often the project manager who is most often assigned to it, as someone who is initially needed to get things done. In the presence of a manager’s manager, in most cases, the role of the request manager is practically unnecessary, although formally they provide dual power, the request manager is engaged in tasks that have not yet decided whether to do it or not, and the manager’s manager will have those that already need to be done and brought to the end.
Cadenza. Various meetings with variable under the process frequency
There are many such meetings in kanban, even too many. Various meetings from daily to delivery planning meetings and and planning for filling the queue (analogous to the planning of the sprint in the scram).
Daily fly-up standup
On stand-ups, unlike scram, much more pleasant questions for performers are discussed. It is not necessary to remember painfully what you did yesterday, it’s enough to look at the board together with everyone and determine what prevents each task from right to left to move to the right, and what it can prevent
Operations Review
How to work not to go into formalism and following the rules to the detriment of the product?
This is where the Operations Review meeting, which differs from the agile retrospectives, is very helpful because it considers the processes in the organization as a whole, so as not to engage in local optimization at retrospective meetings of each team, since according to the same theory of constraints, local optimization is more likely to harm performance organization, what helps her.
Provide yourself technical support engineers who, without increasing staff and other external signs of a problem, more and more efficiently and quickly respond to the growing number of complaining users, but since they need to respond quickly, do not pass the information to the development team. Imagine this is not difficult, this happens in technical support of a huge number of Russian and foreign companies. No matter how efficiently, quickly, and beautifully they answered, if they do not signal the source of the problem, then the problem is more difficult to detect and correct, and it will be more difficult for them to compare with the increasing load.
Delivery planning
At this meeting, which does not occur exactly once every 2 weeks, but occurs exactly when there are any problems with delivery or uncertainty, for example, in marketing, you can conduct a review of what is more ready to be completed and choose those tasks which are more priority for the nearest delivery.
Backlog filling
Honestly, there was never any particular need for the author’s teams, this problem was more likely to be overcrowded due to the large number of customers, but nevertheless the need for this meeting is easy for those who have ever made a product from scratch and remembers a fresh project for example in Jira. At such a meeting, you can create jointly top-priority tasks across a product or even organization. With the decomposition on the technical level, engineers will perfectly cope.
Metrics
There is a standard set of product metrics: revenue, profit, ARPPU (average rate per paying user), slightly more unloved ARPU (average rate per user, which takes into account revenue in terms of all users, not just paying) and others. These metrics are very useful for any process in a grocery company, slightly different, but very similar for an outsourcing one. But this of course concerns the strategic level.
At the level of functional units, it is important to introduce those metrics or their indirect projections that will really direct the process in the right direction. And this is not always the average number of tasks performed per day, or the time over which tasks are done on average. Although these metrics are proposed by default in kanban, the process should be a priori adapted to the needs of a specific internal and external customer. Only in this way can a company become a set of interrelated services for each other in order to provide services to the end customer.
Interaction with product management
The product manager's profession is similar to the startups, with the only difference that the product manager only has a salary and, if lucky, a percentage of the profits, but the startup starter does not have a salary, but the potential profit belongs to him completely (or in shares with partners).
Product managers exist in the company in order to develop individual products, take care of increasing their profitability and, in principle, do good for their customers through solving real problems of real people, rather than implementing the next set of ideas of the CEO, who can already have fantasy has long ended or there has never been a special vision for this particular direction.
Product managers are owners of budgets and formulate a strategy, including the types of services provided to the client and payroll budgets for the implementation of the plan. Product managers define key metrics that products must achieve. Units can be directly subordinated to the product manager, as well as the traditional matrix structure is possible, which is much worse for manageability and increases the load on the communications of certain people (heads of departments trying to do manual control).
The product manager can design the process he needs and set the metrics he needs. He can selectively use scrum or kanban or even fast waterfall in different parts of his process, because ultimately, any methodology is only a way to achieve the goal.
Cross-functional teams
You can use cross-functional commands in a scram. You can even use a cross-functional scram command as a cell of a common kanban organization structure.
But do not directly oppose Kanban to Scrum and in a hurry to replace one with another. Kanban is best suited for service units, and not for cross-functional "combat" teams, each of which can do everything from marketing to technical support.
In cross-functional teams, it is better not to divide work into different types and not to create confrontation in the spirit of “this task is not in my column”, in divisions with the same function of employees and a large number of similar tasks, this approach will show itself well with less effort.
And again about the board, which many mistaken for kanban itself
How to make the programmer, tester or any other engineer no longer tugged at the manager or any representative of related departments with the question "when will it be ready?"
It is enough to teach people to read the board and set tasks on the board. Indeed, in the view of many kanban = board , although this is actually not the case.
Usually, internal customers are delighted, and if you show them a team that uses all of the above methods, and some of them even implement kanban in their own unit, if they like the result, without waiting for any requirements from above, which makes it possible to run kanban as a virus management methodologies within medium-sized organizations.
In the author's practice, there was even a case of losing a client, since the kanban “finished” itself with the help of the specialists who started it in more detail, and the general director was removed from manual control of the processes, which made him satisfied.
Bibliography:
Source: https://habr.com/ru/post/334860/
All Articles