Screaming
- I want to panic, okay?
-You'll arrange a slaughter there, not a panic.
"Big Kush"
For quite a long time, I have come across posts, articles, and even entire books, the purpose of which is to convey to the reader advice on how to do Scrum correctly. All of them, in general, are of the same type and are built on the assumption that most people incorrectly understand the proposed practices, their purpose and importance. In these sources, it is actively proved that Skram still works, speaks about accepting values, rebuilding thinking at the company level, about the intricacies of organizing meetings and other nuances that the car and the small trolley are recruited each time. Apparently, the problem does exist, for even Ken Schwaber and Jeff Sutherland describe Scrum as “ lightweight, easy to understand and difficult to master ” [1]. But is it just a matter of practice? Maybe people do not understand the very essence of Scrum? When something starts to make serious money, it is no secret that it is the profit that becomes the guiding star of this ship. Maybe all these trainings, certifications and hastily retraining to scram-masters project managers overshadowed the original message? Quite possibly. But is it? This opus is an attempt to look at the problem from a slightly different angle, in terms of more technical than any other.
Steve McConnell in his book “Perfect Code” writes: “ Complexity management is the most important technical aspect of software development. In my opinion, complexity management is so important that it should be the Main Technical Imperative of Development ”[2]. The idea itself is not new - the desire for simplicity permeates the entire history of software and is still cultivated. “ Simplicity is the key to reliability, ” Dijkstra used to say. “ Managing complexity is the quintessence of programming, ” Kernigan echoes. And here, suddenly with reference to Skram, we meet the definition of “difficult to master”. What is this? There is an obvious contradiction. We are actually struggling with all the difficulties with the complexity, so why do we need a clearly complex development methodology? Nonsense? But perhaps the answer is that Scrum is not a methodology. And not development.
I admit the thought that ending the previous paragraph plunged you into some confusion.
')
Well, let's understand, first with the first, then with the second. Referring to the original source:
“ Scrum is a framework within which it is possible to solve complex adaptive problems and at the same time productively and creatively develop products of the highest quality. "
The first thing we notice is the word “framework,” and it's worth noting that Ken Schvaber insists on this definition. But what is a framework from our technical point of view? This is an external frame that defines the structure of the system. One of the characteristic features of such frameworks is the implementation of the principle of inversion of control. Inversion of Control is a concept that is rather widely used today primarily in relation to the mechanism for introducing dependencies. However, as practice shows, people not only confuse the concepts of IoC and DI, but sometimes even identify them. Let's deal with this once and for all. Consider a simple program:
Our main method Main calls first function A, then B, and finally C. It can be library functions or some internal application methods. Thus, it is the program that determines the set and sequence of actions performed, it controls itself. This control flow is called direct. If the direction of this stream is reversed, we will get what is also called the Hollywood principle - do not call us, we will call you (or in a more technical language: do not call us, we will call you). The frameworks implement just such an approach, providing extension points. We, as developers, connect our code to these points, which is called exactly when the external frame considers it necessary to do this, while the code of the frame itself remains unchanged. This is exactly what frameworks differ from conventional libraries, and such a control flow is called inverted.
So what do we have? If Scrum is a framework, then, therefore, it is a kind of external framework that provides a flow of control that does not change itself, and allows us to embed our own mechanisms. Let's check these assumptions.
Does Scrum manage the flow of execution? Yes of course. It provides us with an iterative-incremental concept of sprints, defines a list of actions for each sprint, and even sets the daily routine. There are no questions.
Is Scrum unchanged? And yes again. The authors literally say this to us: “ Each element of the framework serves a specific purpose and is key to the success and use of Scrum. “Another direct hit.”
But what do we build into this framework, at these very points of expansion, located between grooming, stand-ups and retrospectives? Obviously, the development itself with all its components: design, testing, design, construction, refactoring, etc. And note that Scrum does not in any way try to climb into this process, does not attempt to either change it, or dictate its own rules and conditions. Like any decent framework, it knows nothing about the business logic with which it interacts. This means that instead of developing software, we can embed other things. And indeed, today Scrum is adapted for the sphere of finance, health care, and higher education. Some enthusiasts use it for building houses, housekeeping and even organizing weddings. But wait. If we embed development in a framework, literally as a black box, then is it possible that this external framework does not control the development itself? Exactly!
But what does he do then? There is no need to go far for an answer, it is enough to return to the original source: “ solves complex adaptive problems ”. In particular, “it shows the relative effectiveness of your product management and development practices, ” and the result of this observation is “the opportunity to improve them .”
To understand more clearly what we are talking about, let us make a little digression into history. Robert Martin, widely known also as Uncle Bob, in his speech “The Future of Programming” [3] highlights two prerequisites for the emergence of flexible processes. One of them is what we already know about in general: in the 90s, the world of software development began to actively change, and the waterfall began to fail. Accordingly, new approaches were needed, focused on dynamic businesses with all the following characteristics: the need for rapid adaptation to the market, a tendency to constant changes, etc. No wonder Kent Beck called one of the main goals of Agile " erasing the boundary between development and business ." Even more imbued with this statement can be, if we take into account that in fact, Beck used the word “heal” - healing. However, looking at the situation from the point of view of business alone would be wrong. If you open the list of authors of the famous Agile Manifesto, you will find that almost all of these people are hardened techies. It is logical to assume that they solved not only the problem of business, but also some kind of their own, purely technical. And indeed it is. According to the empirical estimate of the same Bob Martin, the number of programmers is doubled every five years. This means that at any given time, generally speaking, half of all developers are people with experience not exceeding a five-year period. Is this a problem? Perhaps, yes. Again, the essence of the issue is not in a specific time period, but in the amount of experience as such, because, frankly, the correlation between time and level of knowledge exists and is quite high. Thus, flexible methodologies not only try to meet the needs of the business, providing it with a more understandable, convenient and profitable model for developing software products, but also address the issue of insufficient professionalism in the teams of programmers.
Scram, being a framework, provides an organizational tool that allows, like litmus paper, as quickly as possible to identify problems in these two areas and respond promptly to them. But no more. If you are not able to adjust the work with the requirements, and your developers write poor-quality code creeping out of all terms and budgets, then Scrum itself will not change anything. The biggest misconception is that people expect that its use alone can optimize internal processes. “ Your expectations are your problems, ” as one well-known soccer player used to say. It also follows that the task of the scrum master is not so much the close and zealous tracking of events, artifacts and rules of the framework, but rather in identifying and eliminating problems that arise. And yes, this means that he must not only be able to distinguish a good user story from a bad one, but also directly influence the technical aspects of development, such as the introduction of various engineering practices. The four values ​​and twelve principles are just the tip of the Agile iceberg, and are supported by their naming convention, evolutionary design, code reviews, development through testing, refactoring, continuous integration, design patterns, pair programming, and other numerous technical techniques. Remember: it’s impossible to solve design problems with organizational conclusions alone. From stand-ups and retrospectives themselves, the best code will not appear in your repositories. But he has all the chances to be there, if you use the Scrum tools to learn how to identify team problems in technical areas and have enough competence to apply technical solutions to them.
And then no one will ever be able to scramble your “clean code that works” [4].
[1] Scrum Guide
[2] Steve McConnell "Perfect Code"
[3] The Future of Programming
[4] Ron Jeffreys
-You'll arrange a slaughter there, not a panic.
"Big Kush"
For quite a long time, I have come across posts, articles, and even entire books, the purpose of which is to convey to the reader advice on how to do Scrum correctly. All of them, in general, are of the same type and are built on the assumption that most people incorrectly understand the proposed practices, their purpose and importance. In these sources, it is actively proved that Skram still works, speaks about accepting values, rebuilding thinking at the company level, about the intricacies of organizing meetings and other nuances that the car and the small trolley are recruited each time. Apparently, the problem does exist, for even Ken Schwaber and Jeff Sutherland describe Scrum as “ lightweight, easy to understand and difficult to master ” [1]. But is it just a matter of practice? Maybe people do not understand the very essence of Scrum? When something starts to make serious money, it is no secret that it is the profit that becomes the guiding star of this ship. Maybe all these trainings, certifications and hastily retraining to scram-masters project managers overshadowed the original message? Quite possibly. But is it? This opus is an attempt to look at the problem from a slightly different angle, in terms of more technical than any other.
Steve McConnell in his book “Perfect Code” writes: “ Complexity management is the most important technical aspect of software development. In my opinion, complexity management is so important that it should be the Main Technical Imperative of Development ”[2]. The idea itself is not new - the desire for simplicity permeates the entire history of software and is still cultivated. “ Simplicity is the key to reliability, ” Dijkstra used to say. “ Managing complexity is the quintessence of programming, ” Kernigan echoes. And here, suddenly with reference to Skram, we meet the definition of “difficult to master”. What is this? There is an obvious contradiction. We are actually struggling with all the difficulties with the complexity, so why do we need a clearly complex development methodology? Nonsense? But perhaps the answer is that Scrum is not a methodology. And not development.
I admit the thought that ending the previous paragraph plunged you into some confusion.
')
Well, let's understand, first with the first, then with the second. Referring to the original source:
“ Scrum is a framework within which it is possible to solve complex adaptive problems and at the same time productively and creatively develop products of the highest quality. "
The first thing we notice is the word “framework,” and it's worth noting that Ken Schvaber insists on this definition. But what is a framework from our technical point of view? This is an external frame that defines the structure of the system. One of the characteristic features of such frameworks is the implementation of the principle of inversion of control. Inversion of Control is a concept that is rather widely used today primarily in relation to the mechanism for introducing dependencies. However, as practice shows, people not only confuse the concepts of IoC and DI, but sometimes even identify them. Let's deal with this once and for all. Consider a simple program:
static class Program { static void Main() { A(); B(); C(); } } Our main method Main calls first function A, then B, and finally C. It can be library functions or some internal application methods. Thus, it is the program that determines the set and sequence of actions performed, it controls itself. This control flow is called direct. If the direction of this stream is reversed, we will get what is also called the Hollywood principle - do not call us, we will call you (or in a more technical language: do not call us, we will call you). The frameworks implement just such an approach, providing extension points. We, as developers, connect our code to these points, which is called exactly when the external frame considers it necessary to do this, while the code of the frame itself remains unchanged. This is exactly what frameworks differ from conventional libraries, and such a control flow is called inverted.
So what do we have? If Scrum is a framework, then, therefore, it is a kind of external framework that provides a flow of control that does not change itself, and allows us to embed our own mechanisms. Let's check these assumptions.
Does Scrum manage the flow of execution? Yes of course. It provides us with an iterative-incremental concept of sprints, defines a list of actions for each sprint, and even sets the daily routine. There are no questions.
Is Scrum unchanged? And yes again. The authors literally say this to us: “ Each element of the framework serves a specific purpose and is key to the success and use of Scrum. “Another direct hit.”
But what do we build into this framework, at these very points of expansion, located between grooming, stand-ups and retrospectives? Obviously, the development itself with all its components: design, testing, design, construction, refactoring, etc. And note that Scrum does not in any way try to climb into this process, does not attempt to either change it, or dictate its own rules and conditions. Like any decent framework, it knows nothing about the business logic with which it interacts. This means that instead of developing software, we can embed other things. And indeed, today Scrum is adapted for the sphere of finance, health care, and higher education. Some enthusiasts use it for building houses, housekeeping and even organizing weddings. But wait. If we embed development in a framework, literally as a black box, then is it possible that this external framework does not control the development itself? Exactly!
But what does he do then? There is no need to go far for an answer, it is enough to return to the original source: “ solves complex adaptive problems ”. In particular, “it shows the relative effectiveness of your product management and development practices, ” and the result of this observation is “the opportunity to improve them .”
To understand more clearly what we are talking about, let us make a little digression into history. Robert Martin, widely known also as Uncle Bob, in his speech “The Future of Programming” [3] highlights two prerequisites for the emergence of flexible processes. One of them is what we already know about in general: in the 90s, the world of software development began to actively change, and the waterfall began to fail. Accordingly, new approaches were needed, focused on dynamic businesses with all the following characteristics: the need for rapid adaptation to the market, a tendency to constant changes, etc. No wonder Kent Beck called one of the main goals of Agile " erasing the boundary between development and business ." Even more imbued with this statement can be, if we take into account that in fact, Beck used the word “heal” - healing. However, looking at the situation from the point of view of business alone would be wrong. If you open the list of authors of the famous Agile Manifesto, you will find that almost all of these people are hardened techies. It is logical to assume that they solved not only the problem of business, but also some kind of their own, purely technical. And indeed it is. According to the empirical estimate of the same Bob Martin, the number of programmers is doubled every five years. This means that at any given time, generally speaking, half of all developers are people with experience not exceeding a five-year period. Is this a problem? Perhaps, yes. Again, the essence of the issue is not in a specific time period, but in the amount of experience as such, because, frankly, the correlation between time and level of knowledge exists and is quite high. Thus, flexible methodologies not only try to meet the needs of the business, providing it with a more understandable, convenient and profitable model for developing software products, but also address the issue of insufficient professionalism in the teams of programmers.
Scram, being a framework, provides an organizational tool that allows, like litmus paper, as quickly as possible to identify problems in these two areas and respond promptly to them. But no more. If you are not able to adjust the work with the requirements, and your developers write poor-quality code creeping out of all terms and budgets, then Scrum itself will not change anything. The biggest misconception is that people expect that its use alone can optimize internal processes. “ Your expectations are your problems, ” as one well-known soccer player used to say. It also follows that the task of the scrum master is not so much the close and zealous tracking of events, artifacts and rules of the framework, but rather in identifying and eliminating problems that arise. And yes, this means that he must not only be able to distinguish a good user story from a bad one, but also directly influence the technical aspects of development, such as the introduction of various engineering practices. The four values ​​and twelve principles are just the tip of the Agile iceberg, and are supported by their naming convention, evolutionary design, code reviews, development through testing, refactoring, continuous integration, design patterns, pair programming, and other numerous technical techniques. Remember: it’s impossible to solve design problems with organizational conclusions alone. From stand-ups and retrospectives themselves, the best code will not appear in your repositories. But he has all the chances to be there, if you use the Scrum tools to learn how to identify team problems in technical areas and have enough competence to apply technical solutions to them.
And then no one will ever be able to scramble your “clean code that works” [4].
[1] Scrum Guide
[2] Steve McConnell "Perfect Code"
[3] The Future of Programming
[4] Ron Jeffreys
Source: https://habr.com/ru/post/316730/
All Articles