Checklist: we launch SCRUM-commands and we make vaccinations against zombie scram
SCRUM has become so popular that now they are trying to implement it almost everywhere. In large companies, sometimes it turns out that SCRUM is implemented for the sake of accountability, or in order to be “progressive” and “fashionable”. As a result, a situation that seemed to be a responsible manager put another tick, they say, it was necessary to implement the methodology - implemented, well done, but instead of some qualitative improvements, the output is the so-called “Zombie SCRUM”. This is when the framework is formally implemented, but nobody normally works on it. Hence the name.
My name is Oleg Egorkin, I am an agile coach at Rostelecom, and in this post I will explain why the “zombie-scram” generally occurs, how to avoid it and how to make sure that everything is ready in the company to launch a scram-team.
Sometimes they try to run Scrum Team in IT, that is, from bottom to top. This is when the developers and heads of departments themselves understand, that's all, it's time, we need scram for this product. Plus the fact that the initiative comes from people in the subject. Minus - with this approach, the business is not involved. And if a business is not involved, then the organizational structure itself with this approach either changes very little, or (more often) does not change at all. As a result, the probability of turning such a scram into a “zombie scrum” is very high. Needless to say, it will not be such that on the very first day everything will go wrong, as desired. But after about six months, people will realize that all the disadvantages that were at the start have not gone away. Hence the frustration, which is always sadly reflected in the product.
')
There is a reverse story - from top to bottom. Also not the thing to strive for. As an example, remember, a few years ago, at the dawn of Agile, in one green bank, 50 new teams were launched “by the summer”, and by the end of the year, 5000 were launched. This is the very approach about scrum for the sake of scrum. What happens then? People run rush to carry out orders. Under the scrum begin to row all that is not screwed. The scrum in this story is never the improvement of development and new methodologies, it’s just a tick in the manager’s KPI. In the end - "zombie scrum."
And there is a third approach - the initiative from above and below is co-directed. We were lucky, and in Rostelecom just now. Stuck in what. At the top management level there is a constant assistance to all transformational approaches in teams. In this case, no one puts "ambitious" plans.
For large and very large companies, this is not very familiar. It works like this: Once a month I do one-day basic Agile training. Employees from IT and people from business come to the trainings, about 25 people in a group. I try to talk about it as widely as possible. After some time (it can take from a week to several months), colleagues, having digested their knowledge, come back with a clear request to create a scrum team.
I get two types of requests - either to launch a team as part of the transformation of an existing product, or to a team for a new product. To handle these requests, I wrote a special checklist, with which I check all the conditions necessary for launching. If the application does not pass on any one item and does not fulfill the preliminary requirements, then we do not run the command. This is a conscious need - if you frankly score at least one of the points and run the team without it, it still will not bring results. Well, except that not weakly motivates all participants.
If someone from IT comes to me with an application, I ask him to talk to the business and come back together. Because business in Agile is the main component. From here we have the first checklist item:
Here, as with vampires, they cannot simply take and enter the house, they must be invited. C Agile-coaches are the same thing, in the sense that a change should be requested.
People from business and from IT notice that some product works in difficult market conditions, they turn to me and they say that the approach must be changed. And then if you are very lucky, the request comes at all at the very beginning, when the team is not there yet, but there is an idea by which people can start to collect. At the same time, everyone understands that a clear specification of the product does not form, it will change depending on the business model, and it is not clear which model will work and which one will not.
In general, it is very important that the business is involved.
And it is also important that the driver of this involvement was something tangible, and not just a hype. Therefore, I check that the motives of the business roughly fall into the following:
If one of these three points is there, then everything is fine, this is a sure sign that the team is launching with adequate expectations.
First, it makes sense. It is foolish to launch a product team for a product when you do not have a product. And it doesn’t matter what we start to do around it - around the product or service.
Moreover, the roadmap for the year ahead is at least, in the form of a top-level understanding of what will generally have to be done. Even if a person has 3-5 hypotheses about what business models he will apply, what he wants to explore. If I see that the roadmap is - continue.
Namely, the budget for the cross-functional team. Because under the product a team should be hired for full time, and the business should be ready to pay for it in the horizon about a year in advance. I definitely check that all this is done, I look at what center of financial responsibility is doing this, so that it does not work, that there is an idea, there is a desire to start a team, but there is no money.
Owner. Not the owners. One owner
Man, 100% dedicated exactly to this product. There was a case when two managers came and said - we want to make a motivational and educational product (such an internal piece for employees). I tell them - it's great, do you have a product owner? The answer is - yes, of course, one owner of the product for training, and the other - for motivation. The product is the same motivational and educational.
At that time I asked to think and agree on who will be responsible for the entire product. It turned out to be very difficult and the team was able to start only six months later.
One product - one product owner. It is important.
If someone from the development team works at 50%, 30%, 10% - this is not immediately. One must be completely in the product. But at the same time I do not require the presence of co-located teams. In our conditions, such a big rarity, Rostelecom is very large, we have a lot of subsidiaries and affiliates (affiliated companies), where the developers who work in the teams work. And they can be spaced around Moscow, Peter, Krasnodar and other cities of our vast country. To quickly assemble a team in Moscow is sometimes difficult and time consuming, and often fails at all.
Therefore, I am going to meet each other, but there is a counterclaim - for the team to get together for the first 2 days when training is going on, and then every six months to maintain personal contacts and discuss current issues.
It is also an important thing, like so much that is connected with money. When the owner of the product has a budget, it is spent on order. That is, TK is written to order, an assessment is made for its implementation, and then funds in the budget are allocated for this case. It sounds easy. But there are nuances.
When you go to order work, then at the end of the execution of orders should be the procedure of acceptance and transfer of the product into operation. And since the TK has already been approved, it is extremely difficult to make changes to it. Any changes need to be re-agreed, approved. This is a very complex and slow process, incompatible with a quick response to changes.
What we did to not dig in it and not go crazy.
You can work on Time & Materials when a contract is concluded and the time of the whole team is paid. That is, there is a team that works for the owner of the product. Her services are paid monthly or quarterly. But we cannot do this in its pure form, because there are bureaucratic restrictions.
Therefore, we began to work within the framework of custom development at the level of quarterly orders with roadmap fixation (not TZ), while the order does not detail how the roadmap will be implemented. The product owner has the flexibility to create backlog. And when the quarter ends, we unload the list of completed tasks from the Jiri and form acts on its basis, which are signed and paid. De facto it turns out the same Time & Material.
And here it is not necessary to clearly correspond to the TK, because there is no TK. Requirements that no longer make sense after testing hypotheses can simply not be done.
It is important just because the developers are hired by subsidiaries, where KPIs are used to being put to recycling (this is when a developer has to be constantly busy with something). In fact, almost all integrators work this way - in the conditions of a project shortage (or competing projects), the same developer is painted on several projects. And then, in order for the company to be in the black, the KPI is put in development, that it must always be busy at least 85%. That is, he actually has a certain KPI that motivates him to fit into the maximum number of projects in order to tailor his recycling to the necessary numbers.
Fortunately, there is no such need for the Scrum Team (de facto it is 100%). I make sure that the teams have no other KPIs other than grocery ones.
Here is my checklist. According to it, I check all the teams before launching, and since we have a consistent approach, I can demand a change in conditions if the team does not go through at least one of these points. Therefore, the output is obtained only those teams that are ready to implement the values ​​of the agile-approach.
If an application for a team passes through all these points, the next stage begins - training and launching the team.
Which I will discuss in the next post =)
My name is Oleg Egorkin, I am an agile coach at Rostelecom, and in this post I will explain why the “zombie-scram” generally occurs, how to avoid it and how to make sure that everything is ready in the company to launch a scram-team.
Existing approaches to running commands
Sometimes they try to run Scrum Team in IT, that is, from bottom to top. This is when the developers and heads of departments themselves understand, that's all, it's time, we need scram for this product. Plus the fact that the initiative comes from people in the subject. Minus - with this approach, the business is not involved. And if a business is not involved, then the organizational structure itself with this approach either changes very little, or (more often) does not change at all. As a result, the probability of turning such a scram into a “zombie scrum” is very high. Needless to say, it will not be such that on the very first day everything will go wrong, as desired. But after about six months, people will realize that all the disadvantages that were at the start have not gone away. Hence the frustration, which is always sadly reflected in the product.
')
There is a reverse story - from top to bottom. Also not the thing to strive for. As an example, remember, a few years ago, at the dawn of Agile, in one green bank, 50 new teams were launched “by the summer”, and by the end of the year, 5000 were launched. This is the very approach about scrum for the sake of scrum. What happens then? People run rush to carry out orders. Under the scrum begin to row all that is not screwed. The scrum in this story is never the improvement of development and new methodologies, it’s just a tick in the manager’s KPI. In the end - "zombie scrum."
And there is a third approach - the initiative from above and below is co-directed. We were lucky, and in Rostelecom just now. Stuck in what. At the top management level there is a constant assistance to all transformational approaches in teams. In this case, no one puts "ambitious" plans.
For large and very large companies, this is not very familiar. It works like this: Once a month I do one-day basic Agile training. Employees from IT and people from business come to the trainings, about 25 people in a group. I try to talk about it as widely as possible. After some time (it can take from a week to several months), colleagues, having digested their knowledge, come back with a clear request to create a scrum team.
About checklist
I get two types of requests - either to launch a team as part of the transformation of an existing product, or to a team for a new product. To handle these requests, I wrote a special checklist, with which I check all the conditions necessary for launching. If the application does not pass on any one item and does not fulfill the preliminary requirements, then we do not run the command. This is a conscious need - if you frankly score at least one of the points and run the team without it, it still will not bring results. Well, except that not weakly motivates all participants.
If someone from IT comes to me with an application, I ask him to talk to the business and come back together. Because business in Agile is the main component. From here we have the first checklist item:
1. Agile team must want to create a business.
Here, as with vampires, they cannot simply take and enter the house, they must be invited. C Agile-coaches are the same thing, in the sense that a change should be requested.
People from business and from IT notice that some product works in difficult market conditions, they turn to me and they say that the approach must be changed. And then if you are very lucky, the request comes at all at the very beginning, when the team is not there yet, but there is an idea by which people can start to collect. At the same time, everyone understands that a clear specification of the product does not form, it will change depending on the business model, and it is not clear which model will work and which one will not.
In general, it is very important that the business is involved.
And it is also important that the driver of this involvement was something tangible, and not just a hype. Therefore, I check that the motives of the business roughly fall into the following:
- reduce time to market if this indicator is too large;
- increase team efficiency;
- improve manageability in the face of changing priorities.
If one of these three points is there, then everything is fine, this is a sure sign that the team is launching with adequate expectations.
2. There must be a product to run.
First, it makes sense. It is foolish to launch a product team for a product when you do not have a product. And it doesn’t matter what we start to do around it - around the product or service.
3. The product owner should have a vision and roadmap for development.
Moreover, the roadmap for the year ahead is at least, in the form of a top-level understanding of what will generally have to be done. Even if a person has 3-5 hypotheses about what business models he will apply, what he wants to explore. If I see that the roadmap is - continue.
4. Business must have money.
Namely, the budget for the cross-functional team. Because under the product a team should be hired for full time, and the business should be ready to pay for it in the horizon about a year in advance. I definitely check that all this is done, I look at what center of financial responsibility is doing this, so that it does not work, that there is an idea, there is a desire to start a team, but there is no money.
5. Must be product owner in business
Owner. Not the owners. One owner
Man, 100% dedicated exactly to this product. There was a case when two managers came and said - we want to make a motivational and educational product (such an internal piece for employees). I tell them - it's great, do you have a product owner? The answer is - yes, of course, one owner of the product for training, and the other - for motivation. The product is the same motivational and educational.
At that time I asked to think and agree on who will be responsible for the entire product. It turned out to be very difficult and the team was able to start only six months later.
One product - one product owner. It is important.
6. All members of the development team should also be 100% allocated for the product.
If someone from the development team works at 50%, 30%, 10% - this is not immediately. One must be completely in the product. But at the same time I do not require the presence of co-located teams. In our conditions, such a big rarity, Rostelecom is very large, we have a lot of subsidiaries and affiliates (affiliated companies), where the developers who work in the teams work. And they can be spaced around Moscow, Peter, Krasnodar and other cities of our vast country. To quickly assemble a team in Moscow is sometimes difficult and time consuming, and often fails at all.
Therefore, I am going to meet each other, but there is a counterclaim - for the team to get together for the first 2 days when training is going on, and then every six months to maintain personal contacts and discuss current issues.
7. Method of payment for the product
It is also an important thing, like so much that is connected with money. When the owner of the product has a budget, it is spent on order. That is, TK is written to order, an assessment is made for its implementation, and then funds in the budget are allocated for this case. It sounds easy. But there are nuances.
When you go to order work, then at the end of the execution of orders should be the procedure of acceptance and transfer of the product into operation. And since the TK has already been approved, it is extremely difficult to make changes to it. Any changes need to be re-agreed, approved. This is a very complex and slow process, incompatible with a quick response to changes.
What we did to not dig in it and not go crazy.
You can work on Time & Materials when a contract is concluded and the time of the whole team is paid. That is, there is a team that works for the owner of the product. Her services are paid monthly or quarterly. But we cannot do this in its pure form, because there are bureaucratic restrictions.
Therefore, we began to work within the framework of custom development at the level of quarterly orders with roadmap fixation (not TZ), while the order does not detail how the roadmap will be implemented. The product owner has the flexibility to create backlog. And when the quarter ends, we unload the list of completed tasks from the Jiri and form acts on its basis, which are signed and paid. De facto it turns out the same Time & Material.
And here it is not necessary to clearly correspond to the TK, because there is no TK. Requirements that no longer make sense after testing hypotheses can simply not be done.
8. The team should not have any KPIs other than those associated with the product.
It is important just because the developers are hired by subsidiaries, where KPIs are used to being put to recycling (this is when a developer has to be constantly busy with something). In fact, almost all integrators work this way - in the conditions of a project shortage (or competing projects), the same developer is painted on several projects. And then, in order for the company to be in the black, the KPI is put in development, that it must always be busy at least 85%. That is, he actually has a certain KPI that motivates him to fit into the maximum number of projects in order to tailor his recycling to the necessary numbers.
Fortunately, there is no such need for the Scrum Team (de facto it is 100%). I make sure that the teams have no other KPIs other than grocery ones.
Total
Here is my checklist. According to it, I check all the teams before launching, and since we have a consistent approach, I can demand a change in conditions if the team does not go through at least one of these points. Therefore, the output is obtained only those teams that are ready to implement the values ​​of the agile-approach.
If an application for a team passes through all these points, the next stage begins - training and launching the team.
Which I will discuss in the next post =)
Source: https://habr.com/ru/post/457988/
All Articles