Scrum: Game Rules
About Scrum you can often hear phrases like “Orthodox Scrum”, “we use the best practices from Scrum” or “that almost always remains” from Scrum techniques when implementing it.
Saying this, it is implied that Scrum is an esoteric technique that is not applicable in real life for one reason or another. For example, because “for scams you need a lot of money, and we have to live within our means” or “in Scrum, developers should be super universal, and we don’t have such people”. And if so, the conclusion is drawn that “you need to think with your head,” and everything must be done in its own way. As a result of this approach, there are some improvements in the workflow, but in general nothing changes, which further convinces that Scrum are fantasies unrelated to the real world. This is not true.
Almost everyone who is trying to implement Scrum make two key mistakes. First, they try to implement Scrum only in development, without changing relations with the business, which guarantees failure of the idea. Secondly, Scrum is trying to be implemented in part, which also makes the project hopeless.
')
In this post I will tell why Scrum needs to be implemented in development, only having achieved support for this idea throughout the company.
The most accurate description of Scrum is on the front page of the Scrum Guide .
Scrum are the rules of the game.
Scrum is not only a description of the process (planning, daily, review, retro), but also defining the roles of the game participants, their relationship with each other and the values they share.
For example, chess. Two players move pieces to the field. One is only white. The other is black only. There is a sequence of moves and rules according to which the knight and pawn proceed. Serious chess is played on time.
What will happen if players declare that they are playing “chess”, and in fact will continue to play checkers with chess pieces? What will happen if, playing “chess”, one player will follow the rules of real chess, and the second one will play “Chapaeva”?
Scrum Guide - thoughtful, reasonable, deep, balanced, difficult to understand document. By the current edition of 2016, it is over 20 years old (Scrum was publicly announced in 1995), while its volume is only 17 pages. Is it enough one to organize the work of the company? No, just like chess rules are not enough to learn how to play well.
At the same time, Scrum Guide did not emerge from a vacuum and in fact is based on the principles and techniques of work organization developed in production and which have proven their viability in practice. History knows examples of the application of theoretical principles in practice with varying degrees of success.
Hennig Brand , based on the principles of alchemy, tried to get gold by evaporating water from urine. The basic idea was that it was golden. We can not say that the idea is completely failed. As a result, in 1669 he received phosphorus, which, like gold, has a certain commercial value. But it was still pure luck. “Start-up” built on these principles, although it initially brought some income to the owner, generally failed quickly and was sold for a relatively small amount.
On the other hand, Humphrey Devi , based on the principles of electrolysis, discovered potassium, sodium, barium and calcium in 1807 (and this is not a complete list of the chemical elements it discovered). It is difficult to call its result otherwise than logical. That, however, does not detract from his personal talent, perseverance and fearlessness.
Eliyahu M. Goldratt , the recognized guru of the theory of business management, the author of the Theory of Constraints , in the book “The Goal” explains the techniques of searching and eliminating bottlenecks in the production process. In “Isn't it Obvious?” He talks about how to increase sales by reducing the number of missing positions in the most popular products by reorganizing the work of the warehouse-store system.
His theory is united by the idea that in order to achieve real results for a company, all these processes must be reorganized simultaneously, in a complex and taking into account the interests of all parties. This idea is expressed in a book summarizing the previous one, “Beyond the Goal” . The paradox is that the optimization of only part of the company's processes, for example, development only, will not only lead to the growth of the business as a whole, but may also have a negative impact on the employees of the department who have achieved significant improvements in the productivity of their work.
This fully applies to Scrum. Implementing it only in the development, not reaching the understanding and agreement of work on Scrum in the whole company is obviously a bad idea. Yes, Scrum technology can significantly expand development opportunities. This will quickly and efficiently release many new features of the application ... which as a result will be completely unnecessary to users. “Your product is too complicated, we could not figure out a sad smile”. The result is business discontent and frustration on the development side.
Before you change anything in the development process, you must achieve full recognition of Scrum by everyone in the company. In particular, this requires a general acceptance of Scrum values (Scrum Guide, Scrum Values: commitment, courage, focus, openness and respect.): Diligence, courage, focus, openness and respect.
Ignoring Scrum's values, it’s easy to destroy all the benefits it can give.
If the business owner does not respect the right of the Product Owner to make decisions on product development and imposes a specific action plan on him, the entire Scrum team loses the ability to quickly adapt, since it cannot make any decisions on its own.
If the Product Owner does not fulfill its obligation to increase the value of the product, which is its sole responsibility, how can it retain the confidence of the business owners?
If the Product Owner does not have the courage to change the product and try something new, how can he increase the value of the product? After all, any improvement is ultimately a change.
If the Product Owner does not respect the development team’s right to organize itself, and on a daily basis intervenes in the work of the team, constantly changing plans and controlling all phases of work, the Development Team will not be able to improve its performance. The result of her work will be consistently miserable and mediocre.
If the Development Team does not keep promises to achieve the goals taken in the sprint, how can it maintain its independence and trust on the part of the Product Owner?
If the Scrum Team fails to focus its work on a specific goal for a particular sprint, and instead sprays efforts in many ways, how will it achieve tangible results? And if there is no return from the work, even if it is negative, it will be possible to understand whether it is worth further developing the chosen direction or vice versa you need to return everything, as it was, and throw out what has been done. And in order to be able to throw out from the product what has been done, but it turned out to be unnecessary, courage and determination are also needed.
If all parties are not open to each other in the problems that they face and will hide the difficulties of a commercial or technical plan, it will still be known over time. But trust and respect will be lost.
It is not enough just to say “yes, they say, we all understand what Scrum is and we will act according to its principles”. First of all, everyone needs to read the Scrum Guide. Seriously, you need to read. Questions and misunderstandings should be discussed and agreed. When all conflicts are resolved, each of the parties must state directly and unambiguously how it intends to work on Scrum, or interact with Scrum teams. And only then will it be possible to begin to act, and it is necessary to act decisively and immediately.
To achieve a common understanding of the process, everyone must adhere to a common terminology. Although it seems a trifle and formalism, it is really important. If a business owner calls a Product Owner a “Product Manager,” the developers are “heads,” and the Product Owner itself calls itself, for example, “The Emperor,” can we say that mutual understanding has been achieved?
Achieving the company's overall strategy for Scrum is an important and difficult task. Without her decision to move on is meaningless. Nevertheless, it is doable. But this is only the first step, and the difficulties are just beginning.
In the next post, I will try to reveal in more detail the typical errors in the implementation of Scrum in development, the reasons why they reduce the benefits of Scrum to zero and how to correct them.
Dmitry Mamonov
Development department,
Merge's division into master,
Department of work with git,
Junior console bash operator
Saying this, it is implied that Scrum is an esoteric technique that is not applicable in real life for one reason or another. For example, because “for scams you need a lot of money, and we have to live within our means” or “in Scrum, developers should be super universal, and we don’t have such people”. And if so, the conclusion is drawn that “you need to think with your head,” and everything must be done in its own way. As a result of this approach, there are some improvements in the workflow, but in general nothing changes, which further convinces that Scrum are fantasies unrelated to the real world. This is not true.
Almost everyone who is trying to implement Scrum make two key mistakes. First, they try to implement Scrum only in development, without changing relations with the business, which guarantees failure of the idea. Secondly, Scrum is trying to be implemented in part, which also makes the project hopeless.
')
In this post I will tell why Scrum needs to be implemented in development, only having achieved support for this idea throughout the company.
Scrum as a Game
The most accurate description of Scrum is on the front page of the Scrum Guide .
Scrum are the rules of the game.
Scrum is not only a description of the process (planning, daily, review, retro), but also defining the roles of the game participants, their relationship with each other and the values they share.
For example, chess. Two players move pieces to the field. One is only white. The other is black only. There is a sequence of moves and rules according to which the knight and pawn proceed. Serious chess is played on time.
What will happen if players declare that they are playing “chess”, and in fact will continue to play checkers with chess pieces? What will happen if, playing “chess”, one player will follow the rules of real chess, and the second one will play “Chapaeva”?
Scrum Guide - thoughtful, reasonable, deep, balanced, difficult to understand document. By the current edition of 2016, it is over 20 years old (Scrum was publicly announced in 1995), while its volume is only 17 pages. Is it enough one to organize the work of the company? No, just like chess rules are not enough to learn how to play well.
At the same time, Scrum Guide did not emerge from a vacuum and in fact is based on the principles and techniques of work organization developed in production and which have proven their viability in practice. History knows examples of the application of theoretical principles in practice with varying degrees of success.
Hennig Brand , based on the principles of alchemy, tried to get gold by evaporating water from urine. The basic idea was that it was golden. We can not say that the idea is completely failed. As a result, in 1669 he received phosphorus, which, like gold, has a certain commercial value. But it was still pure luck. “Start-up” built on these principles, although it initially brought some income to the owner, generally failed quickly and was sold for a relatively small amount.
On the other hand, Humphrey Devi , based on the principles of electrolysis, discovered potassium, sodium, barium and calcium in 1807 (and this is not a complete list of the chemical elements it discovered). It is difficult to call its result otherwise than logical. That, however, does not detract from his personal talent, perseverance and fearlessness.
Scrum and Goldratt's theory of constraints
Eliyahu M. Goldratt , the recognized guru of the theory of business management, the author of the Theory of Constraints , in the book “The Goal” explains the techniques of searching and eliminating bottlenecks in the production process. In “Isn't it Obvious?” He talks about how to increase sales by reducing the number of missing positions in the most popular products by reorganizing the work of the warehouse-store system.
His theory is united by the idea that in order to achieve real results for a company, all these processes must be reorganized simultaneously, in a complex and taking into account the interests of all parties. This idea is expressed in a book summarizing the previous one, “Beyond the Goal” . The paradox is that the optimization of only part of the company's processes, for example, development only, will not only lead to the growth of the business as a whole, but may also have a negative impact on the employees of the department who have achieved significant improvements in the productivity of their work.
This fully applies to Scrum. Implementing it only in the development, not reaching the understanding and agreement of work on Scrum in the whole company is obviously a bad idea. Yes, Scrum technology can significantly expand development opportunities. This will quickly and efficiently release many new features of the application ... which as a result will be completely unnecessary to users. “Your product is too complicated, we could not figure out a sad smile”. The result is business discontent and frustration on the development side.
A game for everyone
Before you change anything in the development process, you must achieve full recognition of Scrum by everyone in the company. In particular, this requires a general acceptance of Scrum values (Scrum Guide, Scrum Values: commitment, courage, focus, openness and respect.): Diligence, courage, focus, openness and respect.
Ignoring Scrum's values, it’s easy to destroy all the benefits it can give.
If the business owner does not respect the right of the Product Owner to make decisions on product development and imposes a specific action plan on him, the entire Scrum team loses the ability to quickly adapt, since it cannot make any decisions on its own.
If the Product Owner does not fulfill its obligation to increase the value of the product, which is its sole responsibility, how can it retain the confidence of the business owners?
If the Product Owner does not have the courage to change the product and try something new, how can he increase the value of the product? After all, any improvement is ultimately a change.
If the Product Owner does not respect the development team’s right to organize itself, and on a daily basis intervenes in the work of the team, constantly changing plans and controlling all phases of work, the Development Team will not be able to improve its performance. The result of her work will be consistently miserable and mediocre.
If the Development Team does not keep promises to achieve the goals taken in the sprint, how can it maintain its independence and trust on the part of the Product Owner?
If the Scrum Team fails to focus its work on a specific goal for a particular sprint, and instead sprays efforts in many ways, how will it achieve tangible results? And if there is no return from the work, even if it is negative, it will be possible to understand whether it is worth further developing the chosen direction or vice versa you need to return everything, as it was, and throw out what has been done. And in order to be able to throw out from the product what has been done, but it turned out to be unnecessary, courage and determination are also needed.
If all parties are not open to each other in the problems that they face and will hide the difficulties of a commercial or technical plan, it will still be known over time. But trust and respect will be lost.
It is not enough just to say “yes, they say, we all understand what Scrum is and we will act according to its principles”. First of all, everyone needs to read the Scrum Guide. Seriously, you need to read. Questions and misunderstandings should be discussed and agreed. When all conflicts are resolved, each of the parties must state directly and unambiguously how it intends to work on Scrum, or interact with Scrum teams. And only then will it be possible to begin to act, and it is necessary to act decisively and immediately.
To achieve a common understanding of the process, everyone must adhere to a common terminology. Although it seems a trifle and formalism, it is really important. If a business owner calls a Product Owner a “Product Manager,” the developers are “heads,” and the Product Owner itself calls itself, for example, “The Emperor,” can we say that mutual understanding has been achieved?
Achieving the company's overall strategy for Scrum is an important and difficult task. Without her decision to move on is meaningless. Nevertheless, it is doable. But this is only the first step, and the difficulties are just beginning.
In the next post, I will try to reveal in more detail the typical errors in the implementation of Scrum in development, the reasons why they reduce the benefits of Scrum to zero and how to correct them.
Dmitry Mamonov
Development department,
Merge's division into master,
Department of work with git,
Junior console bash operator
Source: https://habr.com/ru/post/315580/
All Articles