Scrum: Game Rules
You can often hear phrases about Scrum like “Orthodox Scrum”, “we use best practices from Scrum” or “what almost always remains” from Scrum techniques when implementing it.
Saying this, it is understood that Scrum is some esoteric technique that is not applicable in real life for one reason or another. For example, because “Scrum needs a lot of dough, and we must live within our means” or “in Scrum, developers must be super universal, but we don’t have one.” And if so, it concludes that “you need to think with your head”, and everything needs to be done in its own way. As a result of this approach, some improvements appear in the workflow, but overall nothing changes, which further convinces us that Scrum is a fantasy that has nothing to do with the real world. This is not true.
Almost everyone who tries to implement Scrum makes two key mistakes. Firstly, they are trying to introduce Scrum only in development, without changing their relationship with the business, which guarantees failure of the venture. Secondly, Scrum is trying to partially implement, which also makes the venture hopeless.
In this post, I will explain why Scrum should be implemented in development only after gaining 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 a definition of the roles of the game participants, their relationship with each other and the values that they share.
For example, chess. Two players move pieces on the field. One is only white. The other is just black. There is a sequence of moves and rules by which a knight and a pawn move. Serious chess is played for a while.
What will happen if the players say that they are playing “chess”, but actually continue to play checkers with chess pieces? What will happen if, while playing “chess”, one player will follow the rules of real chess, and the second will play “Chapaev”?
Scrum Guide - a thoughtful, reasonable, deep, balanced, difficult to understand document. By the current edition of 2016, he is over 20 years old (Scrum was publicly announced in 1995), while its volume is only 17 pages. Is it enough alone to organize the work of the company? No, just like chess rules is not enough to learn how to play well.
At the same time, the Scrum Guide did not appear out of the vacuum and, in fact, is based on the principles and techniques of work organization developed in production and proved their worth 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 main idea was that both were golden. This is not to say that the venture completely failed. As a result, in 1669 he received phosphorus, which, like gold, has a certain commercial value. But it was still pure luck. Built on these principles, a “startup”, although it initially brought some income to the owner, on the whole quickly failed and was sold for a relatively small amount. Humphrey Devi
, on the other hand, based on the principles of electrolysis, in 1807 discovered potassium, sodium, barium and calcium (And this is not a complete list of chemical elements discovered by them). It is difficult to call its result otherwise than natural. Which, however, does not detract from his personal talent, perseverance and fearlessness.
Eliyahu M. Goldratt , a recognized guru of the theory of business management, the author of Theory of Constraints , in The Goal explains the techniques for finding and eliminating bottlenecks in the manufacturing process. In “Isn't it Obvious?” He talks about how to increase sales by reducing the number of missing items of the most popular goods by reorganizing the work of the store-warehouse system.
His theory is united by the idea that in order to achieve real results for the company, all these processes should be reorganized simultaneously, in a complex and taking into account the interests of all parties. He expresses this idea in a book summarizing the previous one, “Beyond the Goal”. The paradox is that optimizing only part of the company's processes, for example, only development, not only does not lead to the growth of the business as a whole, but can also negatively affect the employees of the unit, which has achieved significant improvements in the productivity of their work.
This fully applies to Scrum. Implementing it only in development, without understanding and agreeing to work on Scrum throughout the company, is obviously a bad idea. Yes, Scrum techniques can significantly expand development capabilities. This will quickly and efficiently release many new features of the application ... which as a result will be completely unnecessary for users. “Your product is too complex, we could not figure it out, sad smiley.” The result is frustration on the part of the business and frustration on the development side.
Before changing anything during the development process, it is necessary to achieve full recognition of Scrum by everyone in the company. In particular, this requires the general acceptance of Scrum values (Scrum Guide, Scrum Values: commitment, courage, focus, openness and respect.): Diligence, courage, focus, openness and respect.
Neglecting Scrum's values, it is easy to destroy all the benefits that it can give.
If the business owner does not respect the right of the Product Owner to make decisions on the development of the product and imposes a specific action plan on him, the entire Scrum-team is deprived of the opportunity to quickly adapt, because it will not be able to make any decisions on its own.
If Product Owner does not fulfill the obligation to increase the value of the product, which is his sole responsibility, how can he maintain the trust of business owners?
If the Product Owner does not have the courage to change the product and try something new, how will he be able to increase the value of the product? After all, any improvement is ultimately a change.
If the Product Owner does not respect the right of the Development Team to self-organize, and on a daily basis interferes in the work of the team, constantly changing plans and monitoring all stages of work, the Development Team will not be able to improve its productivity. The result of her work will be stably miserable and mediocre.
If the Development Team does not fulfill its promises to achieve the goals of the sprint, how will it be able to maintain the independence and trust 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 areas, how will it achieve tangible results? And if the work will not show returns, albeit negative, as 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, also need courage and determination.
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 become 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 will act according to its principles”. First of all, everyone needs to read the Scrum Guide. Seriously, you need to read. Issues and misunderstandings need to be discussed and agreed upon. When all conflicts are resolved, each side must directly and unequivocally state how it intends to work on Scrum, or interact with Scrum teams. And only then it will be possible to begin to act, and you need to act decisively and immediately.
To achieve a common understanding of the process, everyone must adhere to a common terminology. Although this seems like a trifle and formalism, it is really important. If the business owner calls the Product Owner “the Product Manager”, the developers “the bosses”, and the Product Owner himself calls himself, for example, the “Emperor”, can we say that mutual understanding has been reached?
Achieving Scrum’s overall business strategy is an important and challenging task. Without her decision, moving on is pointless. However, it is doable. But this is only the first step, and difficulties are only beginning.
In the next post I will try to reveal in more detail the typical mistakes in the implementation of Scrum in development, the reasons why they reduce the benefits of Scrum to zero and how to fix them.
Dmitry Mamonov
Development Department,
Merge Division in the Master,
Department for work with git,
Junior Bash Console Operator
Saying this, it is understood that Scrum is some esoteric technique that is not applicable in real life for one reason or another. For example, because “Scrum needs a lot of dough, and we must live within our means” or “in Scrum, developers must be super universal, but we don’t have one.” And if so, it concludes that “you need to think with your head”, and everything needs to be done in its own way. As a result of this approach, some improvements appear in the workflow, but overall nothing changes, which further convinces us that Scrum is a fantasy that has nothing to do with the real world. This is not true.
Almost everyone who tries to implement Scrum makes two key mistakes. Firstly, they are trying to introduce Scrum only in development, without changing their relationship with the business, which guarantees failure of the venture. Secondly, Scrum is trying to partially implement, which also makes the venture hopeless.
In this post, I will explain why Scrum should be implemented in development only after gaining 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 a definition of the roles of the game participants, their relationship with each other and the values that they share.
For example, chess. Two players move pieces on the field. One is only white. The other is just black. There is a sequence of moves and rules by which a knight and a pawn move. Serious chess is played for a while.
What will happen if the players say that they are playing “chess”, but actually continue to play checkers with chess pieces? What will happen if, while playing “chess”, one player will follow the rules of real chess, and the second will play “Chapaev”?
Scrum Guide - a thoughtful, reasonable, deep, balanced, difficult to understand document. By the current edition of 2016, he is over 20 years old (Scrum was publicly announced in 1995), while its volume is only 17 pages. Is it enough alone to organize the work of the company? No, just like chess rules is not enough to learn how to play well.
At the same time, the Scrum Guide did not appear out of the vacuum and, in fact, is based on the principles and techniques of work organization developed in production and proved their worth 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 main idea was that both were golden. This is not to say that the venture completely failed. As a result, in 1669 he received phosphorus, which, like gold, has a certain commercial value. But it was still pure luck. Built on these principles, a “startup”, although it initially brought some income to the owner, on the whole quickly failed and was sold for a relatively small amount. Humphrey Devi
, on the other hand, based on the principles of electrolysis, in 1807 discovered potassium, sodium, barium and calcium (And this is not a complete list of chemical elements discovered by them). It is difficult to call its result otherwise than natural. Which, however, does not detract from his personal talent, perseverance and fearlessness.
Scrum and Goldratt's theory of constraints
Eliyahu M. Goldratt , a recognized guru of the theory of business management, the author of Theory of Constraints , in The Goal explains the techniques for finding and eliminating bottlenecks in the manufacturing process. In “Isn't it Obvious?” He talks about how to increase sales by reducing the number of missing items of the most popular goods by reorganizing the work of the store-warehouse system.
His theory is united by the idea that in order to achieve real results for the company, all these processes should be reorganized simultaneously, in a complex and taking into account the interests of all parties. He expresses this idea in a book summarizing the previous one, “Beyond the Goal”. The paradox is that optimizing only part of the company's processes, for example, only development, not only does not lead to the growth of the business as a whole, but can also negatively affect the employees of the unit, which has achieved significant improvements in the productivity of their work.
This fully applies to Scrum. Implementing it only in development, without understanding and agreeing to work on Scrum throughout the company, is obviously a bad idea. Yes, Scrum techniques can significantly expand development capabilities. This will quickly and efficiently release many new features of the application ... which as a result will be completely unnecessary for users. “Your product is too complex, we could not figure it out, sad smiley.” The result is frustration on the part of the business and frustration on the development side.
Game for everyone
Before changing anything during the development process, it is necessary to achieve full recognition of Scrum by everyone in the company. In particular, this requires the general acceptance of Scrum values (Scrum Guide, Scrum Values: commitment, courage, focus, openness and respect.): Diligence, courage, focus, openness and respect.
Neglecting Scrum's values, it is easy to destroy all the benefits that it can give.
If the business owner does not respect the right of the Product Owner to make decisions on the development of the product and imposes a specific action plan on him, the entire Scrum-team is deprived of the opportunity to quickly adapt, because it will not be able to make any decisions on its own.
If Product Owner does not fulfill the obligation to increase the value of the product, which is his sole responsibility, how can he maintain the trust of business owners?
If the Product Owner does not have the courage to change the product and try something new, how will he be able to increase the value of the product? After all, any improvement is ultimately a change.
If the Product Owner does not respect the right of the Development Team to self-organize, and on a daily basis interferes in the work of the team, constantly changing plans and monitoring all stages of work, the Development Team will not be able to improve its productivity. The result of her work will be stably miserable and mediocre.
If the Development Team does not fulfill its promises to achieve the goals of the sprint, how will it be able to maintain the independence and trust 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 areas, how will it achieve tangible results? And if the work will not show returns, albeit negative, as 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, also need courage and determination.
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 become 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 will act according to its principles”. First of all, everyone needs to read the Scrum Guide. Seriously, you need to read. Issues and misunderstandings need to be discussed and agreed upon. When all conflicts are resolved, each side must directly and unequivocally state how it intends to work on Scrum, or interact with Scrum teams. And only then it will be possible to begin to act, and you need to act decisively and immediately.
To achieve a common understanding of the process, everyone must adhere to a common terminology. Although this seems like a trifle and formalism, it is really important. If the business owner calls the Product Owner “the Product Manager”, the developers “the bosses”, and the Product Owner himself calls himself, for example, the “Emperor”, can we say that mutual understanding has been reached?
Achieving Scrum’s overall business strategy is an important and challenging task. Without her decision, moving on is pointless. However, it is doable. But this is only the first step, and difficulties are only beginning.
In the next post I will try to reveal in more detail the typical mistakes in the implementation of Scrum in development, the reasons why they reduce the benefits of Scrum to zero and how to fix them.
Dmitry Mamonov
Development Department,
Merge Division in the Master,
Department for work with git,
Junior Bash Console Operator