June 28, 2019 at 11:05Checklist: launch SCRUM commands and get vaccinations from zombie scrum
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 reporting, or in order to be “progressive” and “fashionable”. As a result, the situation, which seems to be like a responsible manager, set the next check mark, they say, it was necessary to implement the methodology - implemented, well done, but instead of some qualitative improvements, the so-called “Zombie SCRUM” appears on the output. This is when the framework is formally implemented, but no one works normally on it. Hence the name.
My name is Oleg Egorkin, I’m an agile coach in Rostelecom, and in this post I will explain why “zombie scrum” arises in general, how to avoid this and how to make sure that everything is ready for the company to launch a scrum team.
Sometimes they try to launch a scrum team in IT, that is, from bottom to top. This is when the developers themselves and the heads of departments understand that it’s time, for this product we need a scar. The plus is that the initiative comes from the people in the subject. Minus - with this approach, business is not involved. And if the business is not involved, then the organizational structure itself with this approach either changes very slightly, or (more often) does not change at all. As a result, the likelihood of such a scrum becoming a “zombie scrum” is very high. Of course, it will not be such that on the first day everything will go wrong as one would like. But after about six months, people will realize that all the minuses that were at startup did not go anywhere. Hence the frustration that always sadly affects the product.
There is a reverse story - from top to bottom. Also not the thing to strive for. As an example, remember, several years ago, at the dawn of Agile, 50 new teams were launched in a green bank on the instructions of high authorities “by the summer”, and by the end of the year - 5000. This is the very approach to scrum for the sake of scrum. What happens in this case? People rush to run errands. Under the screen, everything that is not screwed begins to row. Scrum in this story is never a development improvement and new methodologies, it’s just a tick in the manager’s KPI. The result is a “zombie scrum.”
And there is a third approach - the initiative is top and bottom codirectionally. We were lucky, and in Rostelecom just now. A thing in what. At the top management level, there is constant assistance to all transformational approaches in teams. At the same time, no one sets up “ambitious” plans.
For large and very large companies, this is not entirely familiar. It works something like this: once a month I give one-day basic training on Agile. Both IT employees and people from business come to the trainings, 25 people in the group. I try to talk about it as widely as possible and widely. After some time (it may take from a week to several months), colleagues, digesting the knowledge gained, come back with an understandable request to create a scrum team.
There are two types of requests for me - either to launch a team as part of the transformation of an existing product, or to a team for a new product. To process these requests, I wrote a special checklist, with the help of which I check all the conditions necessary to run. If the application does not go through any one point and does not fulfill the preliminary requirements, then we do not run the team. This is a recognized need - if you frankly score at least one of the points and run the team without it, it still will not bring results. Well, besides the fact that not weak demotivates 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 at Agile is a key component. From here we have the first checklist item:
Here, as with vampires - they cannot just take and enter the house, they must be invited. With Agile coaches, the same thing, in the sense that a change must be requested.
People from business and from IT notice that some product works in difficult market conditions, they contact me themselves and say - the approach needs to be changed. And here, if you are very lucky, then the request arrives at all at the very beginning, when there is no team yet, but there is an idea under which people can start to gather. At the same time, everyone understands that a clear specification for the product cannot be formed, it will change depending on the business model, and it is not clear which model will work and which does not.
In general, it is very important that the business is involved.
It’s also important that the driver of this involvement should be something tangible, and not just hype. Therefore, I check that the motives of the business roughly fall into the following:
If any of these three points is, then everything is fine, this is a sure sign that the team starts with adequate expectations.
Firstly, this is logical. It's silly to run a product team for a product when you don't have a product. And it doesn’t matter what we all begin to do around it - around a product or service.
Moreover, the roadmap for a year in advance is a minimum, in the form of the highest level understanding of what will generally need 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 there is a roadmap, continue.
Namely, the budget for a cross-functional team. Because the product should be hired for a full time team, and the business should be ready to pay for it in the horizon for about a year in advance. I make sure that all this is done, I look at which financial responsibility center is involved in this, so that it doesn’t work out that there is an idea, there is a desire to launch a team, but there is no money.
Owner. Not the owners. One owner.
A person who is 100% dedicated to this particular product. There was a case when two managers came and said - we want to create a motivational and educational product (such an internal thing for employees). I tell them - great, but do you have a product owner? They answer - yes, of course, one owner of the product is for training, and the other - for motivation. The product is motivational and educational.
At that time I asked to think and agree who will be responsible for the entire product. This turned out to be a very difficult matter and the team managed to be launched 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 right away. 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, it is such a rarity, Rostelecom is very large, we have a lot of subsidiaries and affiliates (subsidiary affiliates), where the developers included in the teams work. And they can be spread across Moscow, Peter, Krasnodar and other cities of our immense homeland. It is sometimes difficult and time consuming to quickly assemble a team in Moscow, but often it doesn’t work at all.
Therefore, I go forward, but there is a counter requirement - that the team get together for the first 2 days when training is in progress, and then every six months to maintain personal contacts and discuss current issues.
This is also an important thing, as well as a lot that is connected with money. When the owner of the product has a budget, it is spent on request. That is, TK is written on the order, an assessment is carried out for its implementation, and then funds in the budget are allocated for this case. That sounds easy. But there are nuances.
When you switch to custom work, then at the end of the execution of orders there should be procedures for accepting and transferring the product to operation. And since TK has already been approved, it is extremely difficult to make changes to it. Any edits must be renegotiated, approved. This is a very complex and slow process, incompatible with a quick reaction to changes.
What have we done so as not to bury ourselves in this and not to go crazy.
You can work on Time & Materials when a contract is concluded and the time of the entire 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 in our country this cannot be done in its pure form, because there are bureaucratic restrictions.
Therefore, we began to work as part of custom development at the level of quarterly orders with fixing roadmaps (not TK), while the order does not detail how the roadmap will be implemented. The product owner has the flexibility of backlog generation. And when the quarter ends, we unload from the diet a list of tasks done and on its basis we form acts that are signed and paid. It turns out the same Time & Material.
And here it is not necessary to clearly comply with TK, because there is no TK. Requirements that no longer make sense after testing hypotheses can simply not be made.
It is important precisely because the developers are hired by subsidiaries, where KPIs are used to setting up for recycling (this is when the developer must be constantly busy with something). In fact, almost all integrators work like this - in the conditions of a shortage of a project (or competing projects) of the same developer, they paint on several projects. And then, in order for the company to be in the black, they put the developer in KPI that he should always be at least 85% busy. That is, he actually has a certain KPI, which motivates him to fit into the maximum number of projects in order to tailor his disposal to the required numbers.
Fortunately, the scrum team does not have such a need (de facto it is 100%). I make sure that the teams do not have other KPIs besides grocery.
This is my checklist. According to it, I check all the teams before starting, and since we have a co-directional 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 only those teams that are ready to implement the values of the agile approach.
If the application for the team goes through all these points, the next stage begins - training and launching the team.
Which I will talk about in the next post =)
Existing Approaches to Running Commands
Sometimes they try to launch a scrum team in IT, that is, from bottom to top. This is when the developers themselves and the heads of departments understand that it’s time, for this product we need a scar. The plus is that the initiative comes from the people in the subject. Minus - with this approach, business is not involved. And if the business is not involved, then the organizational structure itself with this approach either changes very slightly, or (more often) does not change at all. As a result, the likelihood of such a scrum becoming a “zombie scrum” is very high. Of course, it will not be such that on the first day everything will go wrong as one would like. But after about six months, people will realize that all the minuses that were at startup did not go anywhere. Hence the frustration that always sadly affects the product.
There is a reverse story - from top to bottom. Also not the thing to strive for. As an example, remember, several years ago, at the dawn of Agile, 50 new teams were launched in a green bank on the instructions of high authorities “by the summer”, and by the end of the year - 5000. This is the very approach to scrum for the sake of scrum. What happens in this case? People rush to run errands. Under the screen, everything that is not screwed begins to row. Scrum in this story is never a development improvement and new methodologies, it’s just a tick in the manager’s KPI. The result is a “zombie scrum.”
And there is a third approach - the initiative is top and bottom codirectionally. We were lucky, and in Rostelecom just now. A thing in what. At the top management level, there is constant assistance to all transformational approaches in teams. At the same time, no one sets up “ambitious” plans.
For large and very large companies, this is not entirely familiar. It works something like this: once a month I give one-day basic training on Agile. Both IT employees and people from business come to the trainings, 25 people in the group. I try to talk about it as widely as possible and widely. After some time (it may take from a week to several months), colleagues, digesting the knowledge gained, come back with an understandable request to create a scrum team.
About the checklist
There are two types of requests for me - either to launch a team as part of the transformation of an existing product, or to a team for a new product. To process these requests, I wrote a special checklist, with the help of which I check all the conditions necessary to run. If the application does not go through any one point and does not fulfill the preliminary requirements, then we do not run the team. This is a recognized need - if you frankly score at least one of the points and run the team without it, it still will not bring results. Well, besides the fact that not weak demotivates 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 at Agile is a key component. From here we have the first checklist item:
1. Agile team should want to create a business
Here, as with vampires - they cannot just take and enter the house, they must be invited. With Agile coaches, the same thing, in the sense that a change must be requested.
People from business and from IT notice that some product works in difficult market conditions, they contact me themselves and say - the approach needs to be changed. And here, if you are very lucky, then the request arrives at all at the very beginning, when there is no team yet, but there is an idea under which people can start to gather. At the same time, everyone understands that a clear specification for the product cannot be formed, it will change depending on the business model, and it is not clear which model will work and which does not.
In general, it is very important that the business is involved.
It’s also important that the driver of this involvement should be something tangible, and not just 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 work efficiency;
- increase manageability in the face of changing priorities.
If any of these three points is, then everything is fine, this is a sure sign that the team starts with adequate expectations.
2. There must be a product for launch
Firstly, this is logical. It's silly to run a product team for a product when you don't have a product. And it doesn’t matter what we all begin to do around it - around a product or service.
3. The owner of the product must have a vision and roadmap for development
Moreover, the roadmap for a year in advance is a minimum, in the form of the highest level understanding of what will generally need 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 there is a roadmap, continue.
4. Business must have money
Namely, the budget for a cross-functional team. Because the product should be hired for a full time team, and the business should be ready to pay for it in the horizon for about a year in advance. I make sure that all this is done, I look at which financial responsibility center is involved in this, so that it doesn’t work out that there is an idea, there is a desire to launch a team, but there is no money.
5. Must be the product owner in the business
Owner. Not the owners. One owner.
A person who is 100% dedicated to this particular product. There was a case when two managers came and said - we want to create a motivational and educational product (such an internal thing for employees). I tell them - great, but do you have a product owner? They answer - yes, of course, one owner of the product is for training, and the other - for motivation. The product is motivational and educational.
At that time I asked to think and agree who will be responsible for the entire product. This turned out to be a very difficult matter and the team managed to be launched only six months later.
One product - one product owner. It is important.
6. All participants in 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 right away. 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, it is such a rarity, Rostelecom is very large, we have a lot of subsidiaries and affiliates (subsidiary affiliates), where the developers included in the teams work. And they can be spread across Moscow, Peter, Krasnodar and other cities of our immense homeland. It is sometimes difficult and time consuming to quickly assemble a team in Moscow, but often it doesn’t work at all.
Therefore, I go forward, but there is a counter requirement - that the team get together for the first 2 days when training is in progress, and then every six months to maintain personal contacts and discuss current issues.
7. Product payment method
This is also an important thing, as well as a lot that is connected with money. When the owner of the product has a budget, it is spent on request. That is, TK is written on the order, an assessment is carried out for its implementation, and then funds in the budget are allocated for this case. That sounds easy. But there are nuances.
When you switch to custom work, then at the end of the execution of orders there should be procedures for accepting and transferring the product to operation. And since TK has already been approved, it is extremely difficult to make changes to it. Any edits must be renegotiated, approved. This is a very complex and slow process, incompatible with a quick reaction to changes.
What have we done so as not to bury ourselves in this and not to go crazy.
You can work on Time & Materials when a contract is concluded and the time of the entire 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 in our country this cannot be done in its pure form, because there are bureaucratic restrictions.
Therefore, we began to work as part of custom development at the level of quarterly orders with fixing roadmaps (not TK), while the order does not detail how the roadmap will be implemented. The product owner has the flexibility of backlog generation. And when the quarter ends, we unload from the diet a list of tasks done and on its basis we form acts that are signed and paid. It turns out the same Time & Material.
And here it is not necessary to clearly comply with TK, because there is no TK. Requirements that no longer make sense after testing hypotheses can simply not be made.
8. The team should not have any KPI, except those associated with the product
It is important precisely because the developers are hired by subsidiaries, where KPIs are used to setting up for recycling (this is when the developer must be constantly busy with something). In fact, almost all integrators work like this - in the conditions of a shortage of a project (or competing projects) of the same developer, they paint on several projects. And then, in order for the company to be in the black, they put the developer in KPI that he should always be at least 85% busy. That is, he actually has a certain KPI, which motivates him to fit into the maximum number of projects in order to tailor his disposal to the required numbers.
Fortunately, the scrum team does not have such a need (de facto it is 100%). I make sure that the teams do not have other KPIs besides grocery.
Total
This is my checklist. According to it, I check all the teams before starting, and since we have a co-directional 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 only those teams that are ready to implement the values of the agile approach.
If the application for the team goes through all these points, the next stage begins - training and launching the team.
Which I will talk about in the next post =)