Flexible surrogate
The word “Scrum” refers to at least two entities: philosophy and the framework.
The philosophy, or approach to work, is described in a book by Jeff Sutherland.
Framework, i.e. the algorithm of actions described in a document called the Scrum Guide.
Philosophy turned into a framework because the authors of philosophy wanted to make money on it (in their own words).
The framework is greatly simplified compared to philosophy. The main thing is that the goal has been simplified, or rather thrown out.
The purpose of philosophy: accelerating the achievement of results. Moreover, at times. There are 8 times acceleration examples in the book.
The goal of the framework is to have Scrum. It says so: do according to the instructions - you have Scrum, violate the instructions - you do not have Scrum.
The framework does not imply accelerating the achievement of the result, in general.
People who teach or implement Scrum work with the framework. They tell and implement an algorithm that does not lead to any results, except for “we now have Scrum”.
The point is clear. Philosophy is very difficult to sell. The framework is simpler.
A framework is a product. He, as expected, passed the "packaging". It is simple, understandable, there is support and many specialists. Doesn’t resemble anything?
Everything is good, except for the result - it is not there.
If the customer is not familiar with the Scrum philosophy, then the implementation of the framework will suit him perfectly.
If the customer is familiar with the Scrum philosophy, then he will be disappointed with the implementation of the framework - there will be no acceleration in achieving the result.
It will be cool, fashionable, modern, but no business goals will be achieved (except for the development of the budget for “something new”).
How to be? Learn the philosophy of Scrum. It is based on the Japanese philosophy of quality management, the essence of which is: measurements and endless improvements.
Unfortunately, there you have to think, experiment, observe and, alas, work a lot. If this does not suit you, take the framework.
habr.com/en/post/345540
Variable environment
In order to increase the efficiency of a team of programmers, you need a mutable environment. There is already some kind of environment in the team - we need to make it changeable.
A mutable environment is the lack of formal, approved work algorithms.
Programmers like to work on the algorithm, because they themselves are engaged in the creation of algorithms.
A mutable environment is a type of debugging, it is not the program algorithm that is debugging, but the team’s work.
Just agree with the team that the era of change has begun. Today there are some rules, tomorrow others. Not because the reins got caught under the tail, but because the team needs to be debugged.
Debugging is the launch of an algorithm, tracking its operation, and making adjustments if something goes wrong as intended or as desired.
Most change projects fail because of a lack of a changeable environment. It’s scary to make changes in pieces, it’s scary to introduce new rules every day. It is much simpler, without changing anything, to develop a Large Document, in which Everything is Prescribed, and give it for execution.
This is, roughly speaking, how to write program code right away, without a single start. No, sometimes it’s possible to have fun, but on decent tasks this approach does not work - you have to be too smart. It is much easier to do debugging in a mutable environment.
habr.com/en/post/345830
Scrum master
The clean scrum described in the book, when used correctly, increases the team's efficiency by 2 times. This is tested in practice.
But other people's practice shows that no acceleration happens at all. Because the methodology described in the book was simplified for sale. It is she who is used - simplified.
Book Scrum involves three levels:
- The state of Xiu (“comply”) is the first step, train, repeat, not deviating from the rules;
- State Ha (“break through”) - we begin to change the rules, improvise;
- The state of Ri ("separate") - we are freed from the rules and begin to build.
As a rule, the first level is for sale - instruction, and the implementation of its implementation. To get a real increase in efficiency, you need to go to the second and third level. Think with your own head, look for ways to optimize, implement them and monitor the result.
The scrum master should deal with acceleration - this is his responsibility. So it is written in the book, I quote: The main concern of the Scrum-master is to lead the team to continuous improvement and regularly seek the answer to the question “How can we do better what we already do well?”
But this is the second and third level. And the first one is being sold and introduced.
At the first level, the scrum master has completely different responsibilities. Check on the Internet, the list will be something like this:
ABOUT
- organizes and holds rallies;
- Monitors compliance with the principles of scrum;
- Creates an atmosphere of cooperation;
- Resolves conflicts and protects the team.
Not a word about improving efficiency. Just following the instructions.
If you think logically, then how can efficiency increase if the team is constantly working according to the same rules? For something to change, you need to change something. But you can’t do this - according to the instructions it’s not allowed. Therefore, efficiency at the first level does not grow.
A scrum master should be a person who is interested in increasing efficiency. This work cannot be learned if it is not interesting. You have to think a lot, set up experiments, test hypotheses, constantly make mistakes and fill up cones.
It is much easier to issue instructions and monitor its implementation. Well, sometimes to facilitate (whatever that means).
I tried to put different people as scrum-masters, but few people became interested. This is normal.
If you are familiar with the Belbin test, then the Ideas Generator, the Analyst, and the Diplomat (resource investigator) are best suited.
The role of a scrum master is very similar to that of a programmer who optimizes the performance of an application. Only here is the system alive, out of people.
habr.com/en/post/346158
System submission
Outcome of most organizational changes: failed.
By-product: the technique is bullshit.
The methodology that underlies the changes. In particular, Scrum.
The reason is very simple: systemic insubordination.
Well, the solution is very simple: system submission.
Not systematic, but systemic. Submission as a system, as a principle.
In our country, disobedience is elevated to a cult - thanks to the centuries-old history of our state.
Systemic disobedience leads to strange feedback: new rules and laws are created taking into account the fact that no one will comply with them.
This is especially true for organizational change. Their author does not even consider the option that people will work according to the proposed rules. Therefore, it does not bother about the enforceability and adequacy of the rules.
However, there are examples of successfully implemented changes. Take the same video cameras at intersections.
Formally, the penalty for driving to the intersection at which the traffic jam is lined up has long existed. But this rule was practically not respected.
Now it is perfectly observed at separate intersections. On those where video capture cameras are installed.
Cameras just provided system submission. As soon as people began to obey the rule, it became clear that the rule itself was quite a working one. The same rule that used to be unanimously considered some kind of crap.
Also, any other rule, change, algorithm, technique or case. Any technique is useful.
If you think differently, if you say that “Scrum does not work,” or “TOS does not work,” or “Lean is bullshit,” then you are a great person. It’s just that you did not implement this technique because you did not provide system submission. And his inability to provide it was piled on the inoperability of the method.
Providing system submission is very simple. You have to start with yourself. It will be systemic self-submission.
Introducing Scrum on your team? Follow all declared rules, with no exceptions. Every day, without passes.
You will immediately see the advantages and disadvantages of the methodology - this, and any other.
If there is success, then you will be the reason. If there is failure, then you will be the cause.
habr.com/en/post/346712