An island forgotten by Scrum
I stumbled upon the original of this article by accident, digging out mail and stumbled upon the ScrumAlliance newsletter. Subject metrics Scrum commands and directly code, I have been interested for a long time. It is especially curious what to do next with these metrics, and first of all - why are they needed at all?
In this paper, the author raises the most important topic for young Scrum teams - why does productivity lose over time and how to keep it in the long term?
I have reserved boring prefaces for my cozy blog , and I suggest you familiarize yourself with the essence.
To broaden your horizons, as well as get an answer to your internal questions, welcome under the…
')
What is wrong with many scrum projects? Why, at first, the performance of the team jumps, and then begins to fall? Why do some Scrum teams periodically refuse Scrum? What's happening?
As one of those who were called to save Scrum teams from such a renunciation, I tell you that the problem is not that the teams lose their motivation. Often the problem is that the software that teams develop becomes more difficult and it becomes more difficult to work with.
Scrum gives you a quick start! It is perfectly. Often the first sprints are faced with the first features of Scrum. Managers and customers are happy. The team works brilliantly and she is happy too. Everyone is happy and they see huge success in Scrum.
This is repeated in the next and next sprint. Performance is high. The system is gradually built, and all the functionality is already working. Expectations created. Plans are built. Enthusiasm hovers over Scrum. Hyper-performance achieved!
One of the reasons for hyper-productivity is the small size of the code base. A small code base is easier to manage. Corrections are easy to make; new features are easy to add.
But the code is growing fast; and when the code base becomes larger, it becomes hard to maintain. Programmers slow down significantly due to code degradation. Teams are “blown away” to the impossible because of the huge burden of a poorly written system. If this is not taken care of in advance, the hyperproductive Scrum team falls into a disease that kills many software projects. They created a mess (Approx. Lane: mess).
“Wait!” - I hear you say. “I thought that Scrum is needed to strengthen the team! I figured the team would do everything possible to ensure quality. I thought the Scrum-reinforced team wouldn't create a mess! ”
Yes you are right. The problem is that even a strengthened team is still made up of people, and they work for what they are given. Will they be awarded for quality? Or will they be rewarded for their productivity? How much meaningful will the team get for good code quality? How much do they get for delivering working functionality?
There is no answer. The reason is that the scrum team creates a mess, because it is reinforced and stimulated to create it. And the Scrum team can create it quickly, very, very quickly! Scrum team is hyper-productive in creating mess. Until you know about it, the mess will become “so big and so deep, so high that you cannot eliminate it. No exit".
And when it does, productivity drops. Morality falls. Customers and managers are getting angry. Life is bad.
So how do you stimulate the Scrum team so that it doesn't make a mess? Can we just ask not to create it? We tried. This does not work. Stimulation to work faster is based on the tangibility of the result. But to reward the team for a good code, if you do not know the way to objectively evaluate it, it is impossible. Without an unambiguous way to measure confusion, one cannot stop creating it.
We need to move fast and stay clean while maintaining speed. How to encourage the team to achieve two goals? Simply. We measure both and reward equally. If a team moves fast, but works dirty, it will not receive a reward. If the team stays clean, but moves slowly, no reward. If a team moves fast and keeps clean, then it is encouraged!
We can measure confusion by introducing engineering disciplines and practices, such as development through tests (TDD), continuous integration (Continuous Integration), pair programming, collective code ownership and refactoring; those. Extreme Programming Engineering Practices (XP).
It is usually best to start with TDD simply because any code base without tests is messy, no matter how clean it is. This is a harsh statement, but it is strictly rational, emerging from an older discipline: accounting. Just as an accountant can be mistaken in calculations, a programmer can make a mistake in a program. So how do accountants prevent a mistake? They do everything twice.
Accountants use double entry , which is part of International Accounting Standards . Accountants who do not adhere to INBOs quickly change their profession or remain on the sidelines. Double entry is a simple practice of repeating one transaction twice - once on the debit side, the other on the credit side. These two values ​​follow different mathematical operations, but in the end their difference should be equal to zero. Any reporting performed without double entry will be recognized by the accountants as garbage, regardless of how carefully and accurately this reporting has been performed.
TDD is an analogue of double-entry only for software, and should be part of MSPG (International Standards for Programming Practices). The characters with which the accountants operate are no less important for companies than the symbols that programmers manipulate. Can programmers then do less work than an accountant to secure their code?
Programmers practicing TDD create a large number of automatically tests that support each other and are a regression set. This is what you can measure! Measure coverage. Measure the number of tests. Measure the number of new tests in the sprint. Measure the number of defects reported in each sprint and use this to determine the adequacy of code coverage with tests (Note: the test coverage).
The challenge is to increase confidence in the test suite to such a state that you can deliver the product (Note: deploy the product) as soon as the test suite has passed. Therefore, measure the number of "other" tests that you consider necessary to conduct, and make the reduction of their number a priority; especially if it's manual tests!
A set of tests gives great strength. With them, you can refactor without fear. You can make changes to the code without fear of breaking it. If someone sees that something is not obvious or looks dirty, he can fix it without fear of unexpected consequences.
Undocumented systems, or systems where the documentation is not updated according to the product code (Note. Lane: production code) are messy. The unit tests obtained during TDD are documents describing the low-level system architecture. Each programmer who needs to know how one or another part of the system works can rely on reading tests as an unambiguous and accurate description. These documents will never lose relevance, as long as they work out.
Measure the size of the tests. Test methods should be from five to twenty lines of code. The total number of the test code should be approximately equal to the number of the product code.
Measure the speed of tests. Tests must work quickly; minutes, not hours. Encourage quick tests.
Measure the fragility of the tests (Note lane: test breakage). Tests should be designed in such a way that changes in the product code lead to small breakdowns of the tests. If most of the tests fall when the product code changes, then the tests require refactoring (Approx. Test design needs improvement).
Measure Cyclomatic Complexity . Functions that are very complex (for example, cc> 6 or close to this) should be refactored. Use tools like Crap4J to identify methods and functions that violate this rule and have the least test coverage.
Measure the size of functions and classes. The average function must have less than 10 lines of code. Functions longer than 20 lines must be split. Classes with more than 500 lines should be divided into two or more classes. Measure the Braithwaith correlation, it should have a value greater than 2.
Measure dependency metrics. Ensure that there are no circular dependencies. Ensure that the flow of dependencies goes in the direction of abstraction, in accordance with the principle of reversing dependencies and the principle of stable abstractions ( Approx. The principle of stable abstractions: packages that are as permanent as possible should be as abstract as possible. Changeable packages should be concrete. Abstraction from the package should be proportional to it variability. ).
Use static analysis tools like FindBugs or Checksty to identify obvious weak points. These tools also allow you to find and measure the amount of duplicate code.
Implement continuous integration . Set up a build server like Hudson , Team City or Bamboo . Let the server build the system each time a developer adds a code (Note: commits some code). Run all tests on this assembly and troubleshoot it without fail.
Count the number of commits per day. This number must be greater than the number of developers in the team. Encourage frequent commits.
Count the number of days on which the assembly fell this month. Encourage months without falling. Measure the time while the faults remain unresolved.
Test Stories (Note: Story tests) are high-level documents developed by business analysts and testers. They describe the behavior of the system from the point of view of the customer. These tests, written using tools like FitNesse or Cucumber , are requirements that must be followed. When these tests have passed, the team knows that it has completed the stories that these tests described.
Measure “completeness” by running tests on a continuous integration system and watch test stories that have passed or fallen. Use this as a basis for team performance and progress. Introduce the rule that a user story is not considered complete until the relevant test history passes the test, and never allow tests that have already passed to break down.
Practice pair programming. Measure the time spent in pairs and programming time alone. Teams that work in pairs work cleaner. They create less clutter. They complement each other, because know each other's subject areas. They discuss implementation and architecture between themselves. They learn from each other.
And how after all these measurements to encourage the team? Post huge posters on the wall with metrics in the dining room, on the sidelines or in the project room. Show schedules to customers and performers and shout that your team is focused on quality and productivity. Organize parties to achieve milestone. Give out small rewards or rewards. For example, one manager I knew distributed t-shirts to everyone in the team when the team passed the mark of 1000 unit tests in the project. On T-shirts was the name of the project and the words "1000 unit tests."
How to protect the Scrum team from decreasing productivity? How to be sure that hyper-productivity does not get stuck in the quagmire? Make sure that the hyper-productive team does not create confusion! Make sure they use practices that produce a measurable result. Use this result to measure the quality of the code that the team creates; and encourage keeping this code clean.
In this paper, the author raises the most important topic for young Scrum teams - why does productivity lose over time and how to keep it in the long term?
I have reserved boring prefaces for my cozy blog , and I suggest you familiarize yourself with the essence.
To broaden your horizons, as well as get an answer to your internal questions, welcome under the…
')
The Land that Scrum Forgot
What is wrong with many scrum projects? Why, at first, the performance of the team jumps, and then begins to fall? Why do some Scrum teams periodically refuse Scrum? What's happening?
As one of those who were called to save Scrum teams from such a renunciation, I tell you that the problem is not that the teams lose their motivation. Often the problem is that the software that teams develop becomes more difficult and it becomes more difficult to work with.
Scrum gives you a quick start! It is perfectly. Often the first sprints are faced with the first features of Scrum. Managers and customers are happy. The team works brilliantly and she is happy too. Everyone is happy and they see huge success in Scrum.
This is repeated in the next and next sprint. Performance is high. The system is gradually built, and all the functionality is already working. Expectations created. Plans are built. Enthusiasm hovers over Scrum. Hyper-performance achieved!
One of the reasons for hyper-productivity is the small size of the code base. A small code base is easier to manage. Corrections are easy to make; new features are easy to add.
But the code is growing fast; and when the code base becomes larger, it becomes hard to maintain. Programmers slow down significantly due to code degradation. Teams are “blown away” to the impossible because of the huge burden of a poorly written system. If this is not taken care of in advance, the hyperproductive Scrum team falls into a disease that kills many software projects. They created a mess (Approx. Lane: mess).
“Wait!” - I hear you say. “I thought that Scrum is needed to strengthen the team! I figured the team would do everything possible to ensure quality. I thought the Scrum-reinforced team wouldn't create a mess! ”
Yes you are right. The problem is that even a strengthened team is still made up of people, and they work for what they are given. Will they be awarded for quality? Or will they be rewarded for their productivity? How much meaningful will the team get for good code quality? How much do they get for delivering working functionality?
There is no answer. The reason is that the scrum team creates a mess, because it is reinforced and stimulated to create it. And the Scrum team can create it quickly, very, very quickly! Scrum team is hyper-productive in creating mess. Until you know about it, the mess will become “so big and so deep, so high that you cannot eliminate it. No exit".
And when it does, productivity drops. Morality falls. Customers and managers are getting angry. Life is bad.
So how do you stimulate the Scrum team so that it doesn't make a mess? Can we just ask not to create it? We tried. This does not work. Stimulation to work faster is based on the tangibility of the result. But to reward the team for a good code, if you do not know the way to objectively evaluate it, it is impossible. Without an unambiguous way to measure confusion, one cannot stop creating it.
We need to move fast and stay clean while maintaining speed. How to encourage the team to achieve two goals? Simply. We measure both and reward equally. If a team moves fast, but works dirty, it will not receive a reward. If the team stays clean, but moves slowly, no reward. If a team moves fast and keeps clean, then it is encouraged!
We can measure confusion by introducing engineering disciplines and practices, such as development through tests (TDD), continuous integration (Continuous Integration), pair programming, collective code ownership and refactoring; those. Extreme Programming Engineering Practices (XP).
It is usually best to start with TDD simply because any code base without tests is messy, no matter how clean it is. This is a harsh statement, but it is strictly rational, emerging from an older discipline: accounting. Just as an accountant can be mistaken in calculations, a programmer can make a mistake in a program. So how do accountants prevent a mistake? They do everything twice.
Accountants use double entry , which is part of International Accounting Standards . Accountants who do not adhere to INBOs quickly change their profession or remain on the sidelines. Double entry is a simple practice of repeating one transaction twice - once on the debit side, the other on the credit side. These two values ​​follow different mathematical operations, but in the end their difference should be equal to zero. Any reporting performed without double entry will be recognized by the accountants as garbage, regardless of how carefully and accurately this reporting has been performed.
TDD is an analogue of double-entry only for software, and should be part of MSPG (International Standards for Programming Practices). The characters with which the accountants operate are no less important for companies than the symbols that programmers manipulate. Can programmers then do less work than an accountant to secure their code?
Programmers practicing TDD create a large number of automatically tests that support each other and are a regression set. This is what you can measure! Measure coverage. Measure the number of tests. Measure the number of new tests in the sprint. Measure the number of defects reported in each sprint and use this to determine the adequacy of code coverage with tests (Note: the test coverage).
The challenge is to increase confidence in the test suite to such a state that you can deliver the product (Note: deploy the product) as soon as the test suite has passed. Therefore, measure the number of "other" tests that you consider necessary to conduct, and make the reduction of their number a priority; especially if it's manual tests!
A set of tests gives great strength. With them, you can refactor without fear. You can make changes to the code without fear of breaking it. If someone sees that something is not obvious or looks dirty, he can fix it without fear of unexpected consequences.
Undocumented systems, or systems where the documentation is not updated according to the product code (Note. Lane: production code) are messy. The unit tests obtained during TDD are documents describing the low-level system architecture. Each programmer who needs to know how one or another part of the system works can rely on reading tests as an unambiguous and accurate description. These documents will never lose relevance, as long as they work out.
Measure the size of the tests. Test methods should be from five to twenty lines of code. The total number of the test code should be approximately equal to the number of the product code.
Measure the speed of tests. Tests must work quickly; minutes, not hours. Encourage quick tests.
Measure the fragility of the tests (Note lane: test breakage). Tests should be designed in such a way that changes in the product code lead to small breakdowns of the tests. If most of the tests fall when the product code changes, then the tests require refactoring (Approx. Test design needs improvement).
Measure Cyclomatic Complexity . Functions that are very complex (for example, cc> 6 or close to this) should be refactored. Use tools like Crap4J to identify methods and functions that violate this rule and have the least test coverage.
Measure the size of functions and classes. The average function must have less than 10 lines of code. Functions longer than 20 lines must be split. Classes with more than 500 lines should be divided into two or more classes. Measure the Braithwaith correlation, it should have a value greater than 2.
Measure dependency metrics. Ensure that there are no circular dependencies. Ensure that the flow of dependencies goes in the direction of abstraction, in accordance with the principle of reversing dependencies and the principle of stable abstractions ( Approx. The principle of stable abstractions: packages that are as permanent as possible should be as abstract as possible. Changeable packages should be concrete. Abstraction from the package should be proportional to it variability. ).
Use static analysis tools like FindBugs or Checksty to identify obvious weak points. These tools also allow you to find and measure the amount of duplicate code.
Implement continuous integration . Set up a build server like Hudson , Team City or Bamboo . Let the server build the system each time a developer adds a code (Note: commits some code). Run all tests on this assembly and troubleshoot it without fail.
Count the number of commits per day. This number must be greater than the number of developers in the team. Encourage frequent commits.
Count the number of days on which the assembly fell this month. Encourage months without falling. Measure the time while the faults remain unresolved.
Test Stories (Note: Story tests) are high-level documents developed by business analysts and testers. They describe the behavior of the system from the point of view of the customer. These tests, written using tools like FitNesse or Cucumber , are requirements that must be followed. When these tests have passed, the team knows that it has completed the stories that these tests described.
Measure “completeness” by running tests on a continuous integration system and watch test stories that have passed or fallen. Use this as a basis for team performance and progress. Introduce the rule that a user story is not considered complete until the relevant test history passes the test, and never allow tests that have already passed to break down.
Practice pair programming. Measure the time spent in pairs and programming time alone. Teams that work in pairs work cleaner. They create less clutter. They complement each other, because know each other's subject areas. They discuss implementation and architecture between themselves. They learn from each other.
And how after all these measurements to encourage the team? Post huge posters on the wall with metrics in the dining room, on the sidelines or in the project room. Show schedules to customers and performers and shout that your team is focused on quality and productivity. Organize parties to achieve milestone. Give out small rewards or rewards. For example, one manager I knew distributed t-shirts to everyone in the team when the team passed the mark of 1000 unit tests in the project. On T-shirts was the name of the project and the words "1000 unit tests."
How to protect the Scrum team from decreasing productivity? How to be sure that hyper-productivity does not get stuck in the quagmire? Make sure that the hyper-productive team does not create confusion! Make sure they use practices that produce a measurable result. Use this result to measure the quality of the code that the team creates; and encourage keeping this code clean.
Source: https://habr.com/ru/post/163413/
All Articles