Dependent events and statistical fluctuations or why the “waterfall” will die

Hike

The main character (Al) leads the schoolchildren in a campaign - the class of his son. The task is to get to the Devil's Gorge before dark, spend the night there and, the next day, go back. The kids line up in a row one by one and hit the road. The first is Al, the rest - as it should. The system is stretched and the main character has to move to the end so that no one is lost. Then the main character stops seeing the head of the system, which also worries him. He is trying to figure out how it turns out and the first thing that the main character sees is a fat boy who is harder to walk than others. After a short halt and a skirmish of the children because of the delay, they set off again and the behavior of the fat man changes - now he does not lag behind the one in front, because, probably, he was ashamed that he delays everyone. Now, with the accumulation of the backlog from the one in front, he goes on a run. Now the fat man spends more energy than others - will he last long enough?

If at least someone hesitated (hesitated, scratched, straightened the straps of the backpack), then the system stretches, and to reduce the system - EVERYONE must reduce the distance with the one in front, it is not enough just to reduce the distance to the nearest comrade.

Al decides to put the leader of the slowest, so that the line does not stretch. This works, although it causes dissatisfaction with the fastest, who have to trail at a speed that is completely inconsistent with their capabilities. All the others can go at a speed higher than the speed of the fat one, so the formation always remains compressed.

If you continue to go at the speed of the slowest, then you will not be able to clear the daylight towards the Devil's Gorge. But what can you do? The team does not abandon its members.
')
Illumination! Maybe a fat one can help? Hey, fat one, what's in your backpack? A frying pan, 4 bottles of soda, 3 cans of stew, package of marmalade bears, 2 packages of buckwheat. And let's distribute the contents of your backpack to others. Well, now we go to those as fast as the fastest could, but not very slowly.

Concepts

Reach the Devil's Canyon

This is the purpose of the group. Setting a goal is a way to make the group go in one direction and, moreover, to jointly look for ways to accelerate. Imagine how fast the system would move, and how strongly it would stretch if the group had no goal or it was formulated too vaguely or not formulated at all.

One by one

Development often takes the form of dependent events: requirements collection, design, development, testing, and then release. Until the requirements are collected, it is impossible to proceed with the design, etc. Trailing in the system can not be in front of the head.

Story is stretched

Each delay of any participant can cause an increase in the time, but the acceleration of any participant no longer reduces the development time. If the collection of requirements was delayed for a month, then testers will not be able to level this time already - unless they decide to release an untested product.

Go to running

This is one of the obvious solutions. The tester should work 12 hours a day. Then he can check the product 50% faster. Yes, some executives really think so.

Put the lead of the slowest

As a result, the release period is determined by the slowest link in development. How quickly developers and testers would not work, if the requirements are met for half a year, then release will not be released in less than half a year.

Fatty can help

In each specific delay, you can see specific problems and risks and influence them. Yes, the fat one can really help. To do this, the group must be attentive to each other's problems and constantly monitor the status of each work at each point in time.

Dependent events and statistical fluctuations

You should have already understood that dependent events are full in the life of each of us. It remains to understand that statistical fluctuations (to correct the straps of a backpack, to scratch, stumble) always work to increase the time, and not to reduce. To some it may seem that statistical fluctuations should ultimately level each other, but this, unfortunately, does not happen. Statistical fluctuations always work against us.

Try to play the game. Take a box of matches and your friends. The more friends there are, the more indicative the result will be. The first one rolls a die and pulls as many matches out of the box as it fell on the die and transfers them to the second. From the second to the last but one, they also, in their turn, roll the dice and shift as many matches as they fell on the dice, from their heap to the next group. The latter does the same thing only instead of passing matches to the next - sends them to the release. The average value that falls on the dice is 3.5. If the statistical fluctuations eventually go to zero, then in order to send 100 matches to a release, you will need 29 moves.

If someone tried to play this game - please write how many turns how many matches were sent to the release.

Ways to solve the problem described

The worst option that depletes a person is to go running. I usually do not consider it because I consider pernicious in a strategic perspective.

Helping a fat one is a good option. But how can a developer or a tester can help a business analyst to gather requirements or a system analyst to formalize them and develop a design solution? To some extent, this problem is solved with the help of cross-functional teams, where each person has more than one competence. Colleagues, in this case, can help each other.

But the most promising way, in my opinion, is combining mutual assistance in cross-functional teams with parallelization of work.

The first way of parallelization is to start testing simultaneously with the development:

• Writing test plans.
• Automation of functional tests. If we talk about the server API tests, then to write them you need to define the interfaces and the desired behavior, as soon as this is done, tests can be written right away. If we talk about automated user interface testing, the first thing you need to do is develop naming conventions for identifiers of objects to which tests will apply, once this has been done, and the composition of the screens is determined, you can immediately write UI tests.
• Drawing up criteria for accepting tasks.

The second way of parallelization is to split the work into smaller parts:

• No need to collect requirements for half a year. It is necessary to collect a minimum of requirements for one small piece, and transfer the requirements to the development. This will make it possible to launch development and testing in a couple of weeks and shorten the release period for almost the entire time of collecting requirements.
• Even if we cannot yet parallelize development and testing, testers will not have to wait long when the tested functionality is ready, because this is a very small block of the final product.

But there is another very important tool that imperceptibly but significantly (this is not a paradox!) Influences statistical fluctuations. This is the goal! The goal, if accepted by each person in the group, reduces the likelihood of delays and, moreover, creates the desire to reduce the gap between dependent events. You, as a person interested in achieving the goal, will strive to remove obstacles that stand both on your path and on the path of your colleagues. And if everyone in the group does this, the obstacles will become much less, the risks will be worked out in advance, no one will be alone with the overwhelming problem.

Conclusion

Information about dependent events and statistical fluctuations was taken from the book “Goal: the process of continuous improvement” by Eliyahu Goldratt. He took an example from a hike to the Devil's gorge and playing with matches from there.

From my in this article - the projection on the development.

The purpose of this article is, firstly, to tell about an interesting phenomenon and, secondly, to show the fundamental complexity of speeding up the development of a “waterfall”.