What we should build Scrum: an interview with Agile-coach Vasily Savunov
Hello!
Today we have an agile-coach Vasily Savunov in touch. We will talk a little about the organization of the work of the Scrum system team, and also get valuable recommendations on the training of Scrum and Kanban.
Interviewer - Ilya Dzenski, freelancer, UX / UI designer, Agile adept.
')
Ilya: Hi, Vasily!
Vasily: Hi!
Ilya: Let's understand the terms. If you read articles on the Internet, for example an article on Rusbase , then you can get confused in terminology. Some experts say that Kanban and Scrum are from Agile, while others say that Kanban, Scrum, Agile are three different things, each of which must be applied at the right time and place. Which of them is right?
Vasily: Despite the fact that Agile entered Russia relatively long ago (the first Agile trainings started around 2007), there are not so many real experts on it. Therefore, confusion in terms still exists. When we talk about Agile, we mean 4 values ​​from the Agile manifest:
These 4 values ​​are supplemented by 12 principles, and all this together is called Agile. If you draw an analogy, Agile is like a Constitution, it is not very specific, but it gives a general direction and concept. And Scrum, Feature Driven Development, extreme programming, and the rest are concrete implementations of Agile. If we take our example above, Scrum is the law that implements the constitution in the form of events, roles and artifacts.
Agile is like an umbrella brand over agile approaches and methodologies that I called above. And these tools are much more. Scrum won the marketing war because of its external simplicity and more often than other methodologies used in companies. But outward simplicity is deceptive - there are a lot of nuances in Scrum.
Ilya: You said that Agile has 4 values. If I execute them, but at the same time I do not use any of the methodologies, and I do not have a team, then it turns out that Agile works even with one person?
Basil: Yes, Agile philosophy can work with one person.
But the whole devil lies in the fact that when we become more than one person (this is the customer, and the performer, and an expert in his field), then we need to understand and decide how we will specifically implement Agile. All methodologies, the same Scrum, are trying to bring order to this. He says: “There you have a series of actions and rules. If you follow these rules and actions, then you are guaranteed Agile. You have all 4 values ​​to be fulfilled. But if you break at least one of these things, for example, you stop conducting retrospectives, then you begin to lose feedback, you stop in business processes, and you will not achieve the necessary flexibility. ”
Answering your question: yes, Agile can work with one person, but initially it was designed for teams so that they could work in the same way.
Ilya: What is the optimal number of scrum teams and participants in teams?
From classical management it is known that there is a certain operational maximum. This is the number of people who can be led without loss of context and without loss of communication between them. It is believed that this is 7 + -2 people. Maximum - 9. Only a very talented leader can manage them and be in the context of what is happening with them. If we go beyond this amount, then the division into subgroups begins, and this division occurs naturally. If a team is significantly larger in terms of the number of people, then a significant loss and distortion of information begins when it is transmitted between participants.
As for the number of teams. A dedicated Scrum master can successfully lead 3-5 teams. More than 5 teams to one Scrum master are very difficult to conduct: one has to be in the context of all their problems, have time for all the events (planning, meeting, retrospective, demonstration) in all teams. And of course, a good Scrum master needs to understand the professional and technical context of what teams are doing.
The task of the dedicated Scrum-master is not to be an irreplaceable person with unique knowledge and skills, but to find or raise people within these very teams who are interested in doing similar organizational work and contribute to increasing the effectiveness of their teams. The scrum master must transfer his authority and organizational issues within teams as much as possible in order to increase the sustainability and stability of the organization as a whole. Then the need for a dedicated Scrum master disappears, and this role can be taken by someone from the team.
If this does not happen, the so-called “bus factor”, or “bus factor” appears. This is a somewhat joking term, but there is a lot of truth in it. It sounds like this: “How many people in your team should be shot down by bus in order for the project to get up?”. Accordingly, the smaller this number, the worse for you. If this is one person, then if he gets sick, quits, or he (God forbid) knocks down a bus, the team will not be able to move on because of the loss of unique competence, the project will stop, or even “die”.
There are more sophisticated and complex ways to organize work on Scrum on a large number of teams. To do this, there are process scaling scaling frameworks, such as LeSS and SAFe.
Classic LeSS, allows you to work on Scrum to 8 teams. If we have more teams, then Huge LeSS is applied.
SAFe helps to work on an even larger scale: 500-2000 people. For example, Sberbank uses SAFe. The system is very complex, and do not dare to tell it in an interview. There is a whole portal dedicated to how to apply it: www.scaledagileframework.com
Ilya: How to become a “dream team”?
Vasily: To begin with, Agile and Scrum are not for everyone. It is for those who know how to think with their heads, who want to understand and are ready to delve into business processes and business logic. And certainly not for those who work from 9 to 18:00 and only for clear TK.
Let me explain why this is so.
One of the values ​​of Agile is: “interaction with the customer is more important than agreeing the terms of the contract”. The contract in this case is considered the technical task too. Programmers are skilled people, and they are very good at manipulating contracts. It is not uncommon for a customer to ask at the time of delivery of a project: “Why did you not do this function here? She was asking for herself here. ” To which programmers respond: “This was not in the TK. Not written - not done. Next time, write. ” Because TK is a contract.
The customer may ask: “And talk?”, To which programmers say: “And we do not pay money for talking”. And the “battle for contract” begins, when programmers demand more and more detailed TK, and then interpret it in their favor. In turn, the customer can enter in the TK some requirement that is difficult to implement, but once there is in the TK, and this is a contract, programmers will begin to “wring their hands” that this requirement should be done.
We are fighting around formulations, and the product suffers.
Therefore, Agile directly declares: first talk, discuss together the nuances with the customer, and then fix the agreements on paper. Not the other way around.
Regarding the stages of the formation of the “dream team”. Each team will have certain stages that they will go through. These stages are well described in the so-called Bruce Tuckman model.
The first stage is called “forming” (forming), when people get to know each other, the effectiveness of teams is not very high, but there are no conflicts either.
The second stage is “storming”, when people know each other a little bit, but not enough to work together, but together they have to do some difficult task. Conflicts, insults, and division into subgroups begin.
That is why Scrum has a Scrum Master role. He must know and be able to control this dynamic and help the group go through a difficult “storm” stage. To do this, he should be able to competently organize discussions (facilitation), resolve conflicts, support, encourage, and help the team work together so that they can move on to the next stage of development - “norming”.
At the “normaling” stage (norming), the team has already resolved the main conflicts, team members have understood who and what is worth, how best to interact with each other, leaders stand out and weak links disappear.
If the Scrum-master is a smart person, he will reveal conflicts within the team, and organize a constructive search for solutions so that the team members learn to negotiate and make contacts with each other. Gradually, the team is becoming more stable, through the exchange of experience and willingness to replace or help each other in order to achieve a common goal. As a result, the elimination of individual members from the team becomes not so critical. Synergy appears, complementarity, when each team member knows the subtleties of his colleague’s work and, if he is absent, may, to some extent, do some of the work for him so that the movement towards the goal does not stop.
The final stage of development of the team is to perform when people work together, they are motivated, they are professionals, and they reach the maximum of their productivity.
Ilya: Imagine that one Scrum-master has 5 teams in “management”, he holds meetings, retro perspectives, and other events. Can Scrum-master combine several positions and functions (that is, to be, for example, a programmer), or is it undesirable?
Vasily: Good question. If it is a local master within one team, then combining is good and correct.
A scrum master is not a position, it is a role. It can be performed by any volunteer who will take it upon himself. I know positive examples when the role of the Scrum-master in the team is passing. In one sprint one scram-master works, in another sprint another. This is very conducive to team cohesion and respect for this role. In this sense, the local scrum master must be a member of the team.
It is not recommended to combine the role of the product owner and the scrum-master, since they have completely different tricks. The Product owner has a focus on the product, not on people, while the Scrum-master is completely the opposite. If these two roles are combined in one person, you will end up with an internal conflict of interests, which is very difficult to resolve harmoniously.
If the Scrum-master is specially allocated to several teams, then it will be practically impossible for him to combine a working position within one of the teams. He simply will not have time to do anything other than organizational activities.
Ilya: How difficult is it to organize a remote team when team members are located all over the country or in different countries?
Vasily: Let's be honest, Agile works quite hard in terms of the distribution of people. In my practice, there were cases when the distributed team was able to find the strength to organize itself. In general, this only works when these people with regularity of at least 1-2 months meet and work together. Otherwise, there is no “feeling of the elbow”.
37 Signals (now Basecamp) were the first to introduce remote work. They had no offices. At that time it was a trend. There is even a book Remote, which says that it is not necessary to keep offices, everyone can be in different countries and cities of the world. But lately life has shown that it is ineffective. Both Nokia and Apple are now assembling teams locally: they transport their employees to offices, so that everyone can sit together and see each other.
Psychologically, the interlocutor in Skype or instant messenger is perceived as a picture on the screen. There is no feeling that you are a living person, that I am responsible for you. On the Internet, you can not immediately answer the question of the interlocutor, but you try not to answer immediately if the person is sitting in front of you and asking you a question. Personal communication face to face, live, creates a sense of ownership, but communication via the Internet - no.
I had a precedent when we worked with two parts of one team - one part was in Moscow, and the second in Rostov. We brought them once a month and a half to Moscow, and for 2 weeks they worked in the same office with their Moscow colleagues, solved problems together, held demonstrations, and so on. As a result, this had a very important effect: an enormous number of conflicts and misunderstandings disappeared. People really felt like a team. And even when they returned to their homes in different cities, the sense of community remained. After all, it’s one thing when you communicate with some “Petya” in a little chatika, and you can get angry at him, that here he “doesn't understand anything” or “takes a long time to answer”, and quite another when you saw Petya alive, talked, solved with him the problem. And after that, in case of a misunderstanding, you just think “Yes, everything is fine, Petya is a good guy, we just got confused about something. Now I will call him and we will solve everything quickly. ”
Steve McConel introduced the concept of a half-life of trust. For example, if we met you, talked, and then did not communicate for a month and a half, did not correspond and did not contact at all: neither in the messenger, nor by telephone, nor by e-mail, then we will have to get to know you in a new way , as the feeling that we are our people will disappear, and it works in the same way in distributed teams.
The built-in synchronization process can be a guarantee of high-quality remote work, and you need to exert a lot of effort for this to happen.
It is very important to understand that the existence of mutual responsibility will not arise if there is no sense of danger. The dangers of this kind: if we do not agree now, then later we will turn up so that it becomes bad for everyone. In Scrum, this feeling is created through the demonstration of the result by the team to the customer. If it is organized correctly, then even in distributed teams there will be a feeling that we are all “in the same boat”. Even if you are in another city, a situation may well arise when it is you, remotely, who will have to demonstrate the result of the team’s work to the customer and answer all the questions. This is where you start to be interested in - and who did what? Is everything ready? Does the test bench work exactly? And what means of communication? Etc.
Distributed team greatly reduces the feeling of elbow, and requires tremendous effort from the Scrum-master. But with a strong Scrum master, anything is possible.
Ilya: What should the remote teams do then? Trying to implement Agile or move away from it, and pay attention to some other methodology?
Vasily: Implementing Agile in a remote team is possible, although its effectiveness will be much lower. The biggest problem with remote commands is mutual understanding.
The worst mutual understanding happens between people when they communicate via e-mail, a little better - audio (by phone). The ideal option is communication at the blackboard, when we can talk and draw.
To remote teams, I recommend starting with Kanban, when we first build the absolute transparency of our work in stages, clear and clear priorities, we can see the limitations of the team. We begin to understand our Wip-limits (restrictions Work in progress - work in progress). We are accustomed to the fact that it is more important to complete what we have begun, and not to start a new one. After all, if we start to do a lot, but we finish a little, then in essence - “we bury a lot of money“ in the ground ”. We need as quickly as possible to carry out puzzles from occurrence, before laying on the production-server. And this requires the efforts of the whole team.
When we thus build a good workflow, we will begin to rest on the interaction of people, and their mutual understanding. And here you can start thinking about Scrum.
Kanban and Scrum do not contradict each other. Kanban can be “imposed” on Scrum, these things complement each other, even though they have different goals.
Ilya: Imagine not a rare situation when a kanban is introduced into a remote team, but one of the participants constantly slows down the process. What to do with this person: motivate or dismiss?
Vasily: There is only one way out. It is necessary to create a proper sense of danger.
In other words, since we work in Kanban completely transparently, and there is work statistics, such a dialogue with this person is possible: “Look, 50% of processes hang on you. Here are the statistics: from the average time of passing tasks from beginning to end, most of the delays and returns of work - at your stage. This situation has lasted for quite a long time, so it's time to do something about it. Suggest a plan of improvements so that in 2-3 weeks the situation can be straightened, or you and I will have to leave, no matter how painful it is for us and for you. ” In practice, the creation of such a sense of danger will stir up even the most "difficult-lifting" comrades. Well, if not - then do we need to continue to work with him?
And I repeat that at the very beginning you should recruit a team of people who are initially set up for self-organization.
Ilya: Is it possible to learn Agile yourself? What literature can you advise to read?
Basil: There is a book in Russian from Scrum founder Jeff Sutherland “Scrum. A revolutionary project management method . ” This is a book that will give the necessary base. In Russian, unfortunately, the name was completely incorrectly translated, since in English it is called “How to do twice as many things in less time”.
For team building, I recommend the book “The Five Vices of the Team” by Patrick Lensioni, as well as the “One-minute Manager and Monkeys” by Ken Blanchard. The first book is about what a team is all about and what needs to be done for it to appear, and the second is about how to develop independence and self-organization in team members.
Ilya: Vasily, thank you for such detailed answers!
For subscribers: if you are interested in Agile, leave your comments. Basil will respond to them as far as possible and the availability of free time.
Today we have an agile-coach Vasily Savunov in touch. We will talk a little about the organization of the work of the Scrum system team, and also get valuable recommendations on the training of Scrum and Kanban.
Interviewer - Ilya Dzenski, freelancer, UX / UI designer, Agile adept.
')
Ilya: Hi, Vasily!
Vasily: Hi!
Ilya: Let's understand the terms. If you read articles on the Internet, for example an article on Rusbase , then you can get confused in terminology. Some experts say that Kanban and Scrum are from Agile, while others say that Kanban, Scrum, Agile are three different things, each of which must be applied at the right time and place. Which of them is right?
Vasily: Despite the fact that Agile entered Russia relatively long ago (the first Agile trainings started around 2007), there are not so many real experts on it. Therefore, confusion in terms still exists. When we talk about Agile, we mean 4 values ​​from the Agile manifest:
- people and interaction is more important than processes and tools;
- a working product is more important than comprehensive documentation;
- cooperation with the customer is more important than agreeing the terms of the contract;
- willingness to change is more important than following the original plan.
These 4 values ​​are supplemented by 12 principles, and all this together is called Agile. If you draw an analogy, Agile is like a Constitution, it is not very specific, but it gives a general direction and concept. And Scrum, Feature Driven Development, extreme programming, and the rest are concrete implementations of Agile. If we take our example above, Scrum is the law that implements the constitution in the form of events, roles and artifacts.
Agile is like an umbrella brand over agile approaches and methodologies that I called above. And these tools are much more. Scrum won the marketing war because of its external simplicity and more often than other methodologies used in companies. But outward simplicity is deceptive - there are a lot of nuances in Scrum.
Ilya: You said that Agile has 4 values. If I execute them, but at the same time I do not use any of the methodologies, and I do not have a team, then it turns out that Agile works even with one person?
Basil: Yes, Agile philosophy can work with one person.
But the whole devil lies in the fact that when we become more than one person (this is the customer, and the performer, and an expert in his field), then we need to understand and decide how we will specifically implement Agile. All methodologies, the same Scrum, are trying to bring order to this. He says: “There you have a series of actions and rules. If you follow these rules and actions, then you are guaranteed Agile. You have all 4 values ​​to be fulfilled. But if you break at least one of these things, for example, you stop conducting retrospectives, then you begin to lose feedback, you stop in business processes, and you will not achieve the necessary flexibility. ”
Answering your question: yes, Agile can work with one person, but initially it was designed for teams so that they could work in the same way.
Ilya: What is the optimal number of scrum teams and participants in teams?
From classical management it is known that there is a certain operational maximum. This is the number of people who can be led without loss of context and without loss of communication between them. It is believed that this is 7 + -2 people. Maximum - 9. Only a very talented leader can manage them and be in the context of what is happening with them. If we go beyond this amount, then the division into subgroups begins, and this division occurs naturally. If a team is significantly larger in terms of the number of people, then a significant loss and distortion of information begins when it is transmitted between participants.
As for the number of teams. A dedicated Scrum master can successfully lead 3-5 teams. More than 5 teams to one Scrum master are very difficult to conduct: one has to be in the context of all their problems, have time for all the events (planning, meeting, retrospective, demonstration) in all teams. And of course, a good Scrum master needs to understand the professional and technical context of what teams are doing.
The task of the dedicated Scrum-master is not to be an irreplaceable person with unique knowledge and skills, but to find or raise people within these very teams who are interested in doing similar organizational work and contribute to increasing the effectiveness of their teams. The scrum master must transfer his authority and organizational issues within teams as much as possible in order to increase the sustainability and stability of the organization as a whole. Then the need for a dedicated Scrum master disappears, and this role can be taken by someone from the team.
If this does not happen, the so-called “bus factor”, or “bus factor” appears. This is a somewhat joking term, but there is a lot of truth in it. It sounds like this: “How many people in your team should be shot down by bus in order for the project to get up?”. Accordingly, the smaller this number, the worse for you. If this is one person, then if he gets sick, quits, or he (God forbid) knocks down a bus, the team will not be able to move on because of the loss of unique competence, the project will stop, or even “die”.
There are more sophisticated and complex ways to organize work on Scrum on a large number of teams. To do this, there are process scaling scaling frameworks, such as LeSS and SAFe.
Classic LeSS, allows you to work on Scrum to 8 teams. If we have more teams, then Huge LeSS is applied.
SAFe helps to work on an even larger scale: 500-2000 people. For example, Sberbank uses SAFe. The system is very complex, and do not dare to tell it in an interview. There is a whole portal dedicated to how to apply it: www.scaledagileframework.com
Ilya: How to become a “dream team”?
Vasily: To begin with, Agile and Scrum are not for everyone. It is for those who know how to think with their heads, who want to understand and are ready to delve into business processes and business logic. And certainly not for those who work from 9 to 18:00 and only for clear TK.
Let me explain why this is so.
One of the values ​​of Agile is: “interaction with the customer is more important than agreeing the terms of the contract”. The contract in this case is considered the technical task too. Programmers are skilled people, and they are very good at manipulating contracts. It is not uncommon for a customer to ask at the time of delivery of a project: “Why did you not do this function here? She was asking for herself here. ” To which programmers respond: “This was not in the TK. Not written - not done. Next time, write. ” Because TK is a contract.
The customer may ask: “And talk?”, To which programmers say: “And we do not pay money for talking”. And the “battle for contract” begins, when programmers demand more and more detailed TK, and then interpret it in their favor. In turn, the customer can enter in the TK some requirement that is difficult to implement, but once there is in the TK, and this is a contract, programmers will begin to “wring their hands” that this requirement should be done.
We are fighting around formulations, and the product suffers.
Therefore, Agile directly declares: first talk, discuss together the nuances with the customer, and then fix the agreements on paper. Not the other way around.
Regarding the stages of the formation of the “dream team”. Each team will have certain stages that they will go through. These stages are well described in the so-called Bruce Tuckman model.
The first stage is called “forming” (forming), when people get to know each other, the effectiveness of teams is not very high, but there are no conflicts either.
The second stage is “storming”, when people know each other a little bit, but not enough to work together, but together they have to do some difficult task. Conflicts, insults, and division into subgroups begin.
That is why Scrum has a Scrum Master role. He must know and be able to control this dynamic and help the group go through a difficult “storm” stage. To do this, he should be able to competently organize discussions (facilitation), resolve conflicts, support, encourage, and help the team work together so that they can move on to the next stage of development - “norming”.
At the “normaling” stage (norming), the team has already resolved the main conflicts, team members have understood who and what is worth, how best to interact with each other, leaders stand out and weak links disappear.
If the Scrum-master is a smart person, he will reveal conflicts within the team, and organize a constructive search for solutions so that the team members learn to negotiate and make contacts with each other. Gradually, the team is becoming more stable, through the exchange of experience and willingness to replace or help each other in order to achieve a common goal. As a result, the elimination of individual members from the team becomes not so critical. Synergy appears, complementarity, when each team member knows the subtleties of his colleague’s work and, if he is absent, may, to some extent, do some of the work for him so that the movement towards the goal does not stop.
The final stage of development of the team is to perform when people work together, they are motivated, they are professionals, and they reach the maximum of their productivity.
Ilya: Imagine that one Scrum-master has 5 teams in “management”, he holds meetings, retro perspectives, and other events. Can Scrum-master combine several positions and functions (that is, to be, for example, a programmer), or is it undesirable?
Vasily: Good question. If it is a local master within one team, then combining is good and correct.
A scrum master is not a position, it is a role. It can be performed by any volunteer who will take it upon himself. I know positive examples when the role of the Scrum-master in the team is passing. In one sprint one scram-master works, in another sprint another. This is very conducive to team cohesion and respect for this role. In this sense, the local scrum master must be a member of the team.
It is not recommended to combine the role of the product owner and the scrum-master, since they have completely different tricks. The Product owner has a focus on the product, not on people, while the Scrum-master is completely the opposite. If these two roles are combined in one person, you will end up with an internal conflict of interests, which is very difficult to resolve harmoniously.
If the Scrum-master is specially allocated to several teams, then it will be practically impossible for him to combine a working position within one of the teams. He simply will not have time to do anything other than organizational activities.
Ilya: How difficult is it to organize a remote team when team members are located all over the country or in different countries?
Vasily: Let's be honest, Agile works quite hard in terms of the distribution of people. In my practice, there were cases when the distributed team was able to find the strength to organize itself. In general, this only works when these people with regularity of at least 1-2 months meet and work together. Otherwise, there is no “feeling of the elbow”.
37 Signals (now Basecamp) were the first to introduce remote work. They had no offices. At that time it was a trend. There is even a book Remote, which says that it is not necessary to keep offices, everyone can be in different countries and cities of the world. But lately life has shown that it is ineffective. Both Nokia and Apple are now assembling teams locally: they transport their employees to offices, so that everyone can sit together and see each other.
Psychologically, the interlocutor in Skype or instant messenger is perceived as a picture on the screen. There is no feeling that you are a living person, that I am responsible for you. On the Internet, you can not immediately answer the question of the interlocutor, but you try not to answer immediately if the person is sitting in front of you and asking you a question. Personal communication face to face, live, creates a sense of ownership, but communication via the Internet - no.
I had a precedent when we worked with two parts of one team - one part was in Moscow, and the second in Rostov. We brought them once a month and a half to Moscow, and for 2 weeks they worked in the same office with their Moscow colleagues, solved problems together, held demonstrations, and so on. As a result, this had a very important effect: an enormous number of conflicts and misunderstandings disappeared. People really felt like a team. And even when they returned to their homes in different cities, the sense of community remained. After all, it’s one thing when you communicate with some “Petya” in a little chatika, and you can get angry at him, that here he “doesn't understand anything” or “takes a long time to answer”, and quite another when you saw Petya alive, talked, solved with him the problem. And after that, in case of a misunderstanding, you just think “Yes, everything is fine, Petya is a good guy, we just got confused about something. Now I will call him and we will solve everything quickly. ”
Steve McConel introduced the concept of a half-life of trust. For example, if we met you, talked, and then did not communicate for a month and a half, did not correspond and did not contact at all: neither in the messenger, nor by telephone, nor by e-mail, then we will have to get to know you in a new way , as the feeling that we are our people will disappear, and it works in the same way in distributed teams.
The built-in synchronization process can be a guarantee of high-quality remote work, and you need to exert a lot of effort for this to happen.
It is very important to understand that the existence of mutual responsibility will not arise if there is no sense of danger. The dangers of this kind: if we do not agree now, then later we will turn up so that it becomes bad for everyone. In Scrum, this feeling is created through the demonstration of the result by the team to the customer. If it is organized correctly, then even in distributed teams there will be a feeling that we are all “in the same boat”. Even if you are in another city, a situation may well arise when it is you, remotely, who will have to demonstrate the result of the team’s work to the customer and answer all the questions. This is where you start to be interested in - and who did what? Is everything ready? Does the test bench work exactly? And what means of communication? Etc.
Distributed team greatly reduces the feeling of elbow, and requires tremendous effort from the Scrum-master. But with a strong Scrum master, anything is possible.
Ilya: What should the remote teams do then? Trying to implement Agile or move away from it, and pay attention to some other methodology?
Vasily: Implementing Agile in a remote team is possible, although its effectiveness will be much lower. The biggest problem with remote commands is mutual understanding.
The worst mutual understanding happens between people when they communicate via e-mail, a little better - audio (by phone). The ideal option is communication at the blackboard, when we can talk and draw.
To remote teams, I recommend starting with Kanban, when we first build the absolute transparency of our work in stages, clear and clear priorities, we can see the limitations of the team. We begin to understand our Wip-limits (restrictions Work in progress - work in progress). We are accustomed to the fact that it is more important to complete what we have begun, and not to start a new one. After all, if we start to do a lot, but we finish a little, then in essence - “we bury a lot of money“ in the ground ”. We need as quickly as possible to carry out puzzles from occurrence, before laying on the production-server. And this requires the efforts of the whole team.
When we thus build a good workflow, we will begin to rest on the interaction of people, and their mutual understanding. And here you can start thinking about Scrum.
Kanban and Scrum do not contradict each other. Kanban can be “imposed” on Scrum, these things complement each other, even though they have different goals.
Ilya: Imagine not a rare situation when a kanban is introduced into a remote team, but one of the participants constantly slows down the process. What to do with this person: motivate or dismiss?
Vasily: There is only one way out. It is necessary to create a proper sense of danger.
In other words, since we work in Kanban completely transparently, and there is work statistics, such a dialogue with this person is possible: “Look, 50% of processes hang on you. Here are the statistics: from the average time of passing tasks from beginning to end, most of the delays and returns of work - at your stage. This situation has lasted for quite a long time, so it's time to do something about it. Suggest a plan of improvements so that in 2-3 weeks the situation can be straightened, or you and I will have to leave, no matter how painful it is for us and for you. ” In practice, the creation of such a sense of danger will stir up even the most "difficult-lifting" comrades. Well, if not - then do we need to continue to work with him?
And I repeat that at the very beginning you should recruit a team of people who are initially set up for self-organization.
Ilya: Is it possible to learn Agile yourself? What literature can you advise to read?
Basil: There is a book in Russian from Scrum founder Jeff Sutherland “Scrum. A revolutionary project management method . ” This is a book that will give the necessary base. In Russian, unfortunately, the name was completely incorrectly translated, since in English it is called “How to do twice as many things in less time”.
For team building, I recommend the book “The Five Vices of the Team” by Patrick Lensioni, as well as the “One-minute Manager and Monkeys” by Ken Blanchard. The first book is about what a team is all about and what needs to be done for it to appear, and the second is about how to develop independence and self-organization in team members.
Ilya: Vasily, thank you for such detailed answers!
For subscribers: if you are interested in Agile, leave your comments. Basil will respond to them as far as possible and the availability of free time.
Source: https://habr.com/ru/post/352608/
All Articles