Scrum implementation by techie: real experience, pitfalls, tips & tricks
In recent years, the introduction of agile-methodologies in software development has become a whole industry: special literature is being published on this topic, subject conferences are being organized, and trainings are being organized. In the labor market, completely new professions have emerged, such as agile-coach or scrum master. Whole companies that specialize in the implementation of flexible methodologies in other companies have appeared.
In such conditions, it seems perfectly logical to order external consulting and “invite” a professional scrum master to your company for several months. And this is the perfect case, just a dream.
In real life, it is often different: the development team has long been tired of the tasks that are chaotically received by the management, and the management suffers from the lack of transparency of the development, constant deadlines and poor quality of the product. At the same time, top management does not want to hear about allocating a budget for the services of professional scram masters.
')
In such circumstances, the developer has two ways: to continue to endure or to take the initiative in their hands.
I chose the latter and today I will talk about the experience of introducing a scram in a company, being not a manager, but a technical specialist. Under the cut real experience, pitfalls and practical advice for those who dared.
First and foremost: the introduction of a scram by the developer is a difficult and ungrateful initiative. To decide on this, you, as a developer, have to have really good reasons.
Here are some formal signs that indicate that something is wrong with the development process in your team:
All these moments directly affect your comfort as a developer. If you listed more than half of the points in the list above, then perhaps you should think about how to implement scams in your team, because it really allows you to solve them.
If the points from above cause you to be perplexed, and the idea of ​​introducing a scram came to you as a result:
then, most likely, you do not need to take it. Just enjoy your work and praise those managers who provide you such working conditions.
Examine the Scrum theory perfectly. This is very important. I recommend the book by Henrik Kniberg " Scrum and XP: notes from the front line ": this is a very well-known Scrum guide which chews through every step of the process step by step. After reading it, you will understand why stand-ups should always be held standing and at the same time, why you should not score on a demo, why you need to evaluate the tasks by Planning Poker, and not openly. There will be an understanding of how this is all connected.
If you still have questions about the appropriateness of certain practices of Scrum, read the book again. If the questions still remain - perhaps you should not take up the introduction of Scrum.
Find yourself colleagues among the developers. Tell me at dinner what advantages they will get after the implementation of this process. Do not forget to say about the obligations imposed by the scram on the developers.
Most people are willing to support good beginnings. There may be someone who says that against the changes - this is normal. But if you are the only one in the team who thinks that the current process is uncomfortable for developers - perhaps you should not take up the implementation of Scrum in this team.
Find companions among the leadership. The more senior you tell about this, the higher the chances of success.
Start with the head of your unit. Move higher. In small companies (up to 50 people) I prefer to go right up to the director. Make a half-hour presentation describing the current process and its problems. Describe how scrum solves them.
Most managers should take your initiative neutral. But at least one leader must take your side and promise support. Remember this person, he is very useful to you in the future.
If you have failed to attract a single leader to your side - you definitely should not take up the introduction of Scrum in this company.
Explicitly announce to the management that scrum mastering takes your time and, accordingly, your efficiency as a techie will decrease by 30%. If the previous step is successful, then it will be perceived adequately. And do not rush at this stage to ask for an increase in salary, you have not done anything yet, for which you should pay more.
Look again at the work done. Here is all this talk, controversy and speech. If it seemed difficult to you and this is not what you would like to do in the next 6-9 months - you should not take up the introduction of Scrum. Because the introduction of Scrum is working with people. It will take away your time and soul. The first time you just have to combine it with your main, technical, activities.
This is the point of no return. You have not yet broken established processes. You can still refuse. Then you will not have this opportunity. If you go ahead and refuse, you will only make it worse: leave your colleagues with a broken process, without giving anything in return. Everyone hates such people.
Together with the management, select the project on which you will form the Scrum team. The ideal team is 4-6 cross-functional developers. This almost never happens, developers have their own specialization and do not want to engage in testing. Therefore, 3-4 non-cross-functional developers and 1-2 testers are also a very good team. You must be one of these guys. And now you are a scram master.
In no case do not agree to the introduction of Scrum at once in the whole company or in a team that you do not belong to - lose control.
An important point: get the management of the official notification of the team that the work is now being done on a scrum, and you are a scram master.
Professional scram masters come to the team with a whole portfolio of services and plug-ins that allow you to track scrum activity in online trackers. This is not your specialty, so do not bother with complex tools.
On the contrary, use analog tools: an offline board with handwritten stickers, sheets of retrospectives pinned to it, the burndown drawn with a marker on the adjacent board. At the stage of becoming a scram such things are even more obvious than their online counterparts.
Further steps are the formation of backlog, the first planning, stand-ups, demo, retro ... There are no special features for a scram master technician, follow the book.
But I want to dwell on one thing in more detail: a scrum master is a manager. Now you have certain levers of influence on the team and even on the person who is the product owner in your team. And you should (!) Use these levers.
I will explain with examples.
The product owner on your team was the manager who had previously set tasks for you. Now you, as a scram master, set tasks for him: to maintain backlog in the prioritized state, to form the User Story correctly and not to drop new tasks into the current sprint.
Suppose that in the hierarchy of the company this person is above you, an ordinary developer, but in the paradigm of the scram you can, and should, make sure that this person fulfills his duties towards the team.
You are a C ++ developer, and he is a C ++ technical developer who set you tasks before implementing the scram. You were on the same team. And at one of the stand-ups, this technical leader declares that he is engaged in a low priority task, although it is clear from the board that there are more important tasks in the sprint. According to the rules, you should ask him to switch to a higher priority task. This is usually enough. But sometimes it causes resentment for a technical member: “As it is, my subordinate tells me what to do!” You need to have the talent of diplomacy to talk from a position of a boss to your boss. But if you lose heart at this moment, the team will instantly feel a violation of the rules, which means that other team members will be tempted to break another rule.
Very often, this very moment turns out to be the most difficult for a scram master technician. I recommend to appeal to the interests of the team and the product owner at such moments: few people want to go against their team or manager. Use escalation of such problems to a higher management in the most extreme cases.
At the beginning of the performance of the team may fall, it is normal when the development process changes.
But after 2-3 sprints, you and other developers will feel the benefits of a scram: the tasks do not fly in a chaotic way, a two-week certainty appeared, the whole team is immersed in solving common tasks, testing occurs immediately after development.
The product owner will have an understanding of what the development is doing and some confidence that most of the planned tasks will be completed by the end of the sprint. Do not forget to highlight this on retro: techies tend to exaggerate and voice only problems.
If your team is doing well, you may be tempted to transmit the experience to other teams. Take your time with this.
First, wait for the other teams to ask you to inject scams for them.
Secondly, prepare yourself a replacement in the first team and only after that take up the establishment of a scram in the second. And yes, you have to go to this second team not only as a scrum master, but also as a developer.
Be prepared for the fact that now all questions regarding the development processes in the company will be addressed to you and you will have to spend time on their support.
An important point: at this stage, when the results of the introduction of the scram are already visible, talk to the management about the surcharge for the scram mastering. Ask + 15% to your salary - normal. Explain that this activity requires strength and nerves and does not last long on one enthusiasm. And indeed it is! I have seen a lot of scrum-masters of techies, whose pure enthusiasm was followed by resentment for unpaid hard work. As a result, the company lost and scrum master and developer.
This may seem strange, but the longer you have a comfortable process in a team, the more dissatisfaction comes to you. This is how the human psyche works: we get used to good things very quickly and stop noticing it, and tend to inflate negative things.
After some time, you will hear from the team members that scrum is not so good. That, they say, we have to pack in sprints and go to stand-ups, that we spend too much time talking. This is especially true for young developers who have joined after the introduction of the scram and have not seen it as it was before.
This is normal. Just prepare some pictures with the description as it was before and show them from time to time unhappy. Sometimes involve the product owner in such conversations, because he is like a senior comrade at the campfire: his stories about past times are perceived by the team very vividly.
In general, managers are dissatisfied with the scrum at the very beginning of implementation, when they first encounter a ban on introducing new tasks into the current sprint. But after the first demo they realize that the advantages of the process outweigh this limitation. In a few months, the manager will become the main lover of the scram
Again, techies from the team often inflate the negative, and managers see the picture more realistic. Therefore, if you feel that the critics have pecked you - drink coffee with your product owner, he will definitely support, and support at such moments is very important.
But criticism is constructive. It is impossible to perfectly adjust the scramble from scratch, so always listen to the advice and try it on your process. Meet each proposed change with two questions: “What problem will it solve?” And “What problems will it cause?”
Is it critical to shift the stand time from 10 am to 6 pm? Or make stand-up time floating? What if I cancel the demo? Or come up with a new type of meeting?
In this regard, Scrum is very similar to the software framework: you can make changes to it, but they will be useful only if you understand the purpose of your changes.
You must clearly understand how this change will affect the process and what additional actions you will need to maintain consistency.
There is no universal advice, but try to make changes to your process gradually and do not forget to evaluate them as a developer. If the change does not satisfy the idea, then boldly roll it back.
The purpose of this article is to highlight moments specific to the technical specialist who raised the flag of the introduction of the scram. I repeat once again - this is an activity which under no circumstances can be considered “background”, it is quite a challenge.
I hope now someone can better prepare for it. And someone will understand that it is not worth it and will not finally break at least some kind of working processes of the company.
Have questions or have your own experience? Welcome in the comments!
In such conditions, it seems perfectly logical to order external consulting and “invite” a professional scrum master to your company for several months. And this is the perfect case, just a dream.
In real life, it is often different: the development team has long been tired of the tasks that are chaotically received by the management, and the management suffers from the lack of transparency of the development, constant deadlines and poor quality of the product. At the same time, top management does not want to hear about allocating a budget for the services of professional scram masters.
')
In such circumstances, the developer has two ways: to continue to endure or to take the initiative in their hands.
I chose the latter and today I will talk about the experience of introducing a scram in a company, being not a manager, but a technical specialist. Under the cut real experience, pitfalls and practical advice for those who dared.
Prerequisites
First and foremost: the introduction of a scram by the developer is a difficult and ungrateful initiative. To decide on this, you, as a developer, have to have really good reasons.
Here are some formal signs that indicate that something is wrong with the development process in your team:
- the developer is constantly pulled and switched from task to task;
- tasks to the developer are uneven, then there is absolutely nothing, then a blockage;
- developers receive disparate tasks and do not see the whole product;
- By putting together tasks from different developers, we get a product that does not work as intended;
- product testing is detached from development, which gives rise to a long cycle of product stabilization;
- deadlines are always on.
All these moments directly affect your comfort as a developer. If you listed more than half of the points in the list above, then perhaps you should think about how to implement scams in your team, because it really allows you to solve them.
If the points from above cause you to be perplexed, and the idea of ​​introducing a scram came to you as a result:
- discussions with a friend from another company in the bar;
- the desire to try "something new";
- boredom;
- ...
then, most likely, you do not need to take it. Just enjoy your work and praise those managers who provide you such working conditions.
Stage 1. Preparation
Examine the Scrum theory perfectly. This is very important. I recommend the book by Henrik Kniberg " Scrum and XP: notes from the front line ": this is a very well-known Scrum guide which chews through every step of the process step by step. After reading it, you will understand why stand-ups should always be held standing and at the same time, why you should not score on a demo, why you need to evaluate the tasks by Planning Poker, and not openly. There will be an understanding of how this is all connected.
If you still have questions about the appropriateness of certain practices of Scrum, read the book again. If the questions still remain - perhaps you should not take up the introduction of Scrum.
Find yourself colleagues among the developers. Tell me at dinner what advantages they will get after the implementation of this process. Do not forget to say about the obligations imposed by the scram on the developers.
Most people are willing to support good beginnings. There may be someone who says that against the changes - this is normal. But if you are the only one in the team who thinks that the current process is uncomfortable for developers - perhaps you should not take up the implementation of Scrum in this team.
Find companions among the leadership. The more senior you tell about this, the higher the chances of success.
Start with the head of your unit. Move higher. In small companies (up to 50 people) I prefer to go right up to the director. Make a half-hour presentation describing the current process and its problems. Describe how scrum solves them.
Most managers should take your initiative neutral. But at least one leader must take your side and promise support. Remember this person, he is very useful to you in the future.
If you have failed to attract a single leader to your side - you definitely should not take up the introduction of Scrum in this company.
Explicitly announce to the management that scrum mastering takes your time and, accordingly, your efficiency as a techie will decrease by 30%. If the previous step is successful, then it will be perceived adequately. And do not rush at this stage to ask for an increase in salary, you have not done anything yet, for which you should pay more.
Look again at the work done. Here is all this talk, controversy and speech. If it seemed difficult to you and this is not what you would like to do in the next 6-9 months - you should not take up the introduction of Scrum. Because the introduction of Scrum is working with people. It will take away your time and soul. The first time you just have to combine it with your main, technical, activities.
This is the point of no return. You have not yet broken established processes. You can still refuse. Then you will not have this opportunity. If you go ahead and refuse, you will only make it worse: leave your colleagues with a broken process, without giving anything in return. Everyone hates such people.
Stage 2. Implementation
Together with the management, select the project on which you will form the Scrum team. The ideal team is 4-6 cross-functional developers. This almost never happens, developers have their own specialization and do not want to engage in testing. Therefore, 3-4 non-cross-functional developers and 1-2 testers are also a very good team. You must be one of these guys. And now you are a scram master.
In no case do not agree to the introduction of Scrum at once in the whole company or in a team that you do not belong to - lose control.
An important point: get the management of the official notification of the team that the work is now being done on a scrum, and you are a scram master.
Professional scram masters come to the team with a whole portfolio of services and plug-ins that allow you to track scrum activity in online trackers. This is not your specialty, so do not bother with complex tools.
On the contrary, use analog tools: an offline board with handwritten stickers, sheets of retrospectives pinned to it, the burndown drawn with a marker on the adjacent board. At the stage of becoming a scram such things are even more obvious than their online counterparts.
Further steps are the formation of backlog, the first planning, stand-ups, demo, retro ... There are no special features for a scram master technician, follow the book.
But I want to dwell on one thing in more detail: a scrum master is a manager. Now you have certain levers of influence on the team and even on the person who is the product owner in your team. And you should (!) Use these levers.
I will explain with examples.
Example 1
The product owner on your team was the manager who had previously set tasks for you. Now you, as a scram master, set tasks for him: to maintain backlog in the prioritized state, to form the User Story correctly and not to drop new tasks into the current sprint.
Suppose that in the hierarchy of the company this person is above you, an ordinary developer, but in the paradigm of the scram you can, and should, make sure that this person fulfills his duties towards the team.
Example 2
You are a C ++ developer, and he is a C ++ technical developer who set you tasks before implementing the scram. You were on the same team. And at one of the stand-ups, this technical leader declares that he is engaged in a low priority task, although it is clear from the board that there are more important tasks in the sprint. According to the rules, you should ask him to switch to a higher priority task. This is usually enough. But sometimes it causes resentment for a technical member: “As it is, my subordinate tells me what to do!” You need to have the talent of diplomacy to talk from a position of a boss to your boss. But if you lose heart at this moment, the team will instantly feel a violation of the rules, which means that other team members will be tempted to break another rule.
Very often, this very moment turns out to be the most difficult for a scram master technician. I recommend to appeal to the interests of the team and the product owner at such moments: few people want to go against their team or manager. Use escalation of such problems to a higher management in the most extreme cases.
Stage 3. Development
At the beginning of the performance of the team may fall, it is normal when the development process changes.
But after 2-3 sprints, you and other developers will feel the benefits of a scram: the tasks do not fly in a chaotic way, a two-week certainty appeared, the whole team is immersed in solving common tasks, testing occurs immediately after development.
The product owner will have an understanding of what the development is doing and some confidence that most of the planned tasks will be completed by the end of the sprint. Do not forget to highlight this on retro: techies tend to exaggerate and voice only problems.
If your team is doing well, you may be tempted to transmit the experience to other teams. Take your time with this.
First, wait for the other teams to ask you to inject scams for them.
Secondly, prepare yourself a replacement in the first team and only after that take up the establishment of a scram in the second. And yes, you have to go to this second team not only as a scrum master, but also as a developer.
Be prepared for the fact that now all questions regarding the development processes in the company will be addressed to you and you will have to spend time on their support.
An important point: at this stage, when the results of the introduction of the scram are already visible, talk to the management about the surcharge for the scram mastering. Ask + 15% to your salary - normal. Explain that this activity requires strength and nerves and does not last long on one enthusiasm. And indeed it is! I have seen a lot of scrum-masters of techies, whose pure enthusiasm was followed by resentment for unpaid hard work. As a result, the company lost and scrum master and developer.
Stage 4. Criticism
This may seem strange, but the longer you have a comfortable process in a team, the more dissatisfaction comes to you. This is how the human psyche works: we get used to good things very quickly and stop noticing it, and tend to inflate negative things.
After some time, you will hear from the team members that scrum is not so good. That, they say, we have to pack in sprints and go to stand-ups, that we spend too much time talking. This is especially true for young developers who have joined after the introduction of the scram and have not seen it as it was before.
This is normal. Just prepare some pictures with the description as it was before and show them from time to time unhappy. Sometimes involve the product owner in such conversations, because he is like a senior comrade at the campfire: his stories about past times are perceived by the team very vividly.
In general, managers are dissatisfied with the scrum at the very beginning of implementation, when they first encounter a ban on introducing new tasks into the current sprint. But after the first demo they realize that the advantages of the process outweigh this limitation. In a few months, the manager will become the main lover of the scram
Again, techies from the team often inflate the negative, and managers see the picture more realistic. Therefore, if you feel that the critics have pecked you - drink coffee with your product owner, he will definitely support, and support at such moments is very important.
But criticism is constructive. It is impossible to perfectly adjust the scramble from scratch, so always listen to the advice and try it on your process. Meet each proposed change with two questions: “What problem will it solve?” And “What problems will it cause?”
Is it critical to shift the stand time from 10 am to 6 pm? Or make stand-up time floating? What if I cancel the demo? Or come up with a new type of meeting?
In this regard, Scrum is very similar to the software framework: you can make changes to it, but they will be useful only if you understand the purpose of your changes.
You must clearly understand how this change will affect the process and what additional actions you will need to maintain consistency.
There is no universal advice, but try to make changes to your process gradually and do not forget to evaluate them as a developer. If the change does not satisfy the idea, then boldly roll it back.
Conclusion
The purpose of this article is to highlight moments specific to the technical specialist who raised the flag of the introduction of the scram. I repeat once again - this is an activity which under no circumstances can be considered “background”, it is quite a challenge.
I hope now someone can better prepare for it. And someone will understand that it is not worth it and will not finally break at least some kind of working processes of the company.
Have questions or have your own experience? Welcome in the comments!
Source: https://habr.com/ru/post/347404/
All Articles