May 13, 2019 at 13:44How to escape from a sect?
Our world is very strange. And the further you go, the weirder it gets. And you’ll understand what the hell.
There are engineers and programmers in the world. Sometimes all rolled into one. People who understand what an algorithm is. Moreover, people who create these algorithms. They are well aware that the created algorithm is suitable for solving one problem, but is not suitable for another. Understanding that if the algorithm is slightly changed, then it will be able to solve related problems. Do not hesitate to throw out half of someone else's algorithm so that it better solves the current problem.
Programmers create a solution for a task, or for a class of tasks. This is the essence of the profession. Where possible, use ready-made pieces of their own or someone else's code. And all is well.
But, as soon as it comes to creating algorithms outside the computer, programmers suddenly lose their heads. I'm not talking about drawing algorithm diagrams on paper, as was the case at the university exam - here any of us can handle it.
I’m talking about “implementation of techniques”, “work on the framework”, “mandatory use of all artifacts”. About sects, in short.
Everyone knows what a conditional operator is. There is no life without him. No decent algorithm will work. Neither in the computer, nor in life.
Now imagine: a certain person appeared, for example, John, and noticed that there is a conditional statement in BASIC. I picked it up, figured it out, made sure - there is, it works, without it in any way.
Let's say John is dumb. But he decided to conquer the world. Went to sell BASIC. Not the language itself, but some kind of “coolest software development technique”, the central link of which is ... And John will not say until you complete the course.
Okay, there were course lovers, especially since the price is not high. They came, listened, gasped. The main element of the coolest software development methodology is the Conditional Operator. We listened a lot about the conditional statement. For example, how to turn it into a multiple choice operator. They gasped again - what a powerful Conditional Operator.
Half of the audience was programmers. Neighing, went home. Another quarter were managers. They became thoughtful, posed questions, someone decided to implement this cool methodology at home. The last quarter were the same as John. They persuaded the guy to create a franchise, Community, Certification Authority and Contingent University.
Programmers from the course returned to work, no longer remembering the Conditional Operator. But an hour later, managers came and announced that now software development will be conducted according to the coolest method. Yes, which is about the Conditional Operator. In general, it’s better to write in basic.
The timid, if not timid objections of the programmers were ignored. Phrases such as “damn it is a conditional operator, it is everywhere” were perceived as attempts to show off. The wheel spun.
And John quickly realized that just one Conditional Operator is not enough. There should also be a Loop, Subroutine, Variable, Array, etc. We should somehow call all this ... In a word ... Oh, let it be Artifacts! No more, no less!
The main thing remained: to add to the methodology the clause that the coolest software development methodology is holistic, holistic knowledge. So, not a single piece can be thrown out of it. And you can’t add anything to it - it will stop working. As it is written, so do it.
Thanks to the enthusiasm of John and his friends, now the whole world uses not a conditional operator, but a Conditional Operator, not a cycle, but a Cycle, etc., according to the list. Those who understood the idiocy of the situation had long retired or shut up. Those who have come recently strongly believe that the Conditional Operator is part of the coolest software development methodology created by John. And all other conditional operators are a miserable likeness, a faded copy and a piece of Knowledge torn out of context.
Anyone who dares to vote on the Internet (or, God forbid, inside the team) will be subjected to fierce condemnation and angry minusculation - you, boots, do not see the benefits of the Conditional Operator! And if the unfortunate person asks to explain what is the meaning and difference from the conditional operator in C ++, javascript or even 1C, he will get the answer “it’s impossible to explain”, “you don’t understand”, or “go read the guide”.
Everyone understands what a conditional operator is, and how to use it in algorithms. In the same way, everyone understands what, for example, is a sticker with a recorded task. Stickers appeared before the scrum, and live outside it. Look at the computer of the accountant, supplier, or seller. They have not yet eliminated the habit of hanging a bunch of stickers with urgent tasks on the monitor. A password will be written on one of the stickers.
Any technique is easily disassembled into tools, principles, and relationships. Just like any algorithm is disassembled into figures of different forms and purposes - the beginning and end of the algorithm, action, condition, subroutine.
Any technique has a scope. Not everything is absolutely there - there is a more suitable environment, there is less. Same as algorithms.
Any technique can be modified. Throw out pieces, add new ones, modify specific tools. Just like algorithms.
Any techniques can be mixed, in whole or in pieces. Take half of one, a quarter from the other, another quarter - invent yourself. When you create an application or service, it is obvious to you.
True, the question remains - will the methodology be a methodology, if it is changed?
Here's how to answer this question, for example, the well-known Scrum Guide:
Is it really scary? What will happen if some of the artifacts are thrown out or replaced? And in general, what's the point? Where did they come from? Why is it believed that they work only in such a combination, as the authors decided?
Let's try to figure out the parts.
Great tool, by the way. Invented, probably, a thousand years ago. It’s always been called differently, but the most common, probably, is the “Plan”. And humanly - "to do a certain amount of work for a certain period of time."
To me, as 1Sniku, it is better known as space-calendar planning (OKP). It is widely used in production and sales planning. For example, a manager’s sales plan of 1 million rubles per month is a backlog and sprint. Sometimes a figure is enough, sometimes there is a breakdown by product group, or restrictions on the market, or there is even a specific list of items, if required by the company's strategy.
The production is even easier. Bushings - 1000 pcs., Shafts - 2000 pcs., Rotors - 500 pcs. This is, say, a weekly plan. He is the backlog of the weekly sprint of the production site. True, you can not explain to the workers that this is not a plan, but a sprint.
The tool is good in comparison with the widespread time management, when the programmer’s task pool is estimated by labor costs, sorted by some criterion, and each task has a deadline. In production, this is called shift planning, or workshop planning, from which production tasks are then created containing a list of parts and semi-finished products, technical operations, materials, inputs and outputs (where to get what and where to transfer the result).
For programmers, workshop planning does not work well, and there is nothing to discuss here. The processing time of a part on a specific model of the machine has been known for a long time and quite accurately. Frequency of service - too. Sufficiency of materials evaluated. Take and do. Variations that interfere with the implementation of the plan in mass production usually do not have a significant effect. And if they do, there are excellent methods for analyzing and eliminating them.
Programmer variations are much stronger. He is not a machine tool, just as some managers who came to IT from sales or production would not like. Therefore, workshop planning (task + deadline) is not suitable for a programmer. So sensible people came up with - you need to rise to a higher level, not to schedule the performance in minutes, but give volume for a period. Only they came up with another name - sprint and backlog.
Filling the volumetric-calendar production plan is based on principles similar to the formation of a sprint backlog. Even there is such a thing - "pick a plan." There are the needs of the same sales department (= large backlog), there is production throughput (= team capabilities in numbers), plus there are clear selection criteria - the amount of sales, profitability of each position, customer parameters (for example, payment terms). Scored a production plan - and immediately see what an approximate financial result you get. This is not an ephemeral "release."
Are there any drawbacks to this tool? Of course, like any other.
If you understand, the sprint backlog is the same workshop planning, only without a well-organized sequence of problem solving. Therefore, all tasks have one deadline - the end of the sprint. Once the tasks have one deadline, an unpleasant effect appears - at the beginning of the sprint, activity can be significantly lower than at the end.
This is how any human psychology works. One always wants to fall for the start of the execution period, whether it is one task, or a backlog. Take a break from the past period, especially - from its final part, when it was necessary to give a "huge" result. Of course, there are people who are stable and rhythmic, working all week at the same speed, but most begin to "work normally" somewhere on Wednesday.
Is it possible to do without sprint and its backlog? Easy.
For example, using the tool "as soon as possible." In general, this is not a Praporsky manners, but quite a normal strategy for the same workshop planning (As Soon As Possible, ASAP). It means that the issues will “stick” to the beginning of the time interval, i.e. By Monday, not Friday, as in the “As Last As Possible, ALAP” strategy.
Planning as such is not necessary in this case. There is a product backlog, there are priorities, there is a rule "as soon as possible." You take the first and do it. Finished - take the second. And so - from the fence to dinner. Sprint, or rather, its essence, i.e. the length of time you can leave for understanding and analyzing performance (week to week, month to month, etc.).
Are there any shortcomings in the strategy "as soon as possible"? Of course, a million. First of all, a person can get tired quickly. Secondly, he will feel like a machine tool. Thirdly, he will most likely run away - to where ordinary sprints with a backlog are used. Or they simply set tasks and wait for the result. In general, where it is calmer. But practice shows that "as soon as possible" is quite possible to live for years, if it is common sense that this is a planning strategy, and not a sweatshirt.
Is it possible to throw a sprint and its backlog? Not. Not because these are unique notions of the same scrum, but because this is a natural planning method that everyone, in one form or another, uses. There are many variations, one principle - you need to do a certain amount of work for a certain period of time.
Is a tool like sprint a unique and key element of any technique? Not. This is the same as saying that typing code on the keyboard is a unique notion of some technique. Almost all texts are typed on the keyboard.
Formally, a board is not an artifact or a rule, but I think it's worth talking about it too, because there is a fairly obvious pattern among people: a scrum is a board with stickers.
Here, in general, you yourself understand everything. A board with stickers on which tasks are written is not unique. This is, roughly speaking, a cross-platform tool. My wife on the refrigerator sometimes sculpts stickers with to-do lists, although she knows nothing about any scrum.
Is this tool good? It depends on what you compare it to. Yes, perhaps a good one.
For example, it allows you to quickly evaluate, look around the pool of tasks. In a computer, or any other electronic device, tasks need to be flipped - everything usually does not fit on one screen. Therefore, at one glance - too.
Another important plus is the overall availability for the team. At any time, you can come and see, do not go into any system, search, make a selection, etc.
Many people like the non-virtual nature of the board. After all, everything is virtual in a computer; you don’t touch it with your hands. And here - please, at least lick. Some, in this regard, love cork boards. The difference is something like between paper and electronic books.
Specifically for a scrum board, one can note such an advantage as separation into two parts - this is done at work. Household handling of stickers involves throwing out those that are already completed - not very good, because progress is seen worse.
Are there any disadvantages of scrum boards? Of course. Like any board.
To begin with household ones - drafts, poor-quality stickers, poor handwriting, sabotage. As a result, lost tasks and confusion in management.
On the board, progress is not very visible. In general, for the sprint - yes. Today, yesterday - no. Hence the need for daily discussions.
Specifically, the status of tasks is not visible on the scrum board, if life is more complicated than “planned” - “done”. Kanban board looks preferable.
The board does not allow normal work if the team is geographically distributed. Therefore, electronic boards appear.
The electronic board, it seems to me, is a sure sign of sectarianism. She lost all the benefits of the usual, but, for some unknown reason, she continues to use it. Probably just because it's a board. Part of the Methodology.
In general, a tool is like a tool. In certain situations - good. In some it’s terrible.
Will scrum work without a board? Easy. And proven by practice. And it seems like, since the board is not an obligatory artifact, it will be possible to continue to call scrum - scrum.
Who is this miracle role? What is it like?
There are many options. For example, a scrum master is like a trainer in sports. There is, say, a football club. The owner of the products there is a manager who defines the goals of the team. A coach is one who helps a team achieve these goals.
In an ordinary, production environment, there are no coaches - if the football club worked like that, the boss would simply come to the locker room before the match and say: “go and win.” And when they lose, he would be happy with the scam. He kicked someone, threatened someone, etc. Like a factory.
And the coach, like the scrum master, serves as the provider between the team and the manager. Of course, the coach has more power - he is not a leader servant. But the result is also required from him faster and more understandable - no one will wait until he facilitates someone there. The coach, like the scrum master, understands how the team should function, i.e. he simply sets tasks, and explains how to solve them. Establishes connections, motivates, creates and maintains an atmosphere, etc.
Another analogy is the platoon commander, some special forces. This is a gaming coach. Goes on tasks together with subordinates, solves combat missions in the same way. In his free time, he supervises the preparation and improvement of skill, the development of new equipment, and physical training. Of course, he constantly works with the team in terms of psychology - it motivates, supports, helps. By peculiar methods, of course, sometimes, but the goal is one - the maximum combat effectiveness of a platoon.
Scrum master, compared with these guys, a freeloader. For the result is not particularly responsible. The lack of formal authority seems to be perceived as an advantage - he is a leader-servant, but in fact he can develop into irresponsibility. Can one endlessly facilitate, without exerting any influence on the result? And when they kick them out, look for another team to facilitate there.
Is it possible to change or remove the role of a scrum master? Of course. For example, combine this role with the product owner. I know that in the Methodology it is written that it’s better not to do this - this will prevent the master from facilitating. But, on the other hand, it will add clear goals and responsibilities. When the goal is understandable and measurable, then the facilitation turns from an optional, incomprehensible crap into a very specific, tangible duty that directly affects the result. Like a trainer or a squad.
True, then the meaning of calling him a scrum master is lost. This will probably be a team leader - do not forget that the "lead" is the leader. A leader is not only a flag in his hands, but also work with motivation, goals, the ability to carry along, introducing new methods of work, training competencies, etc. The driver of the command, in short. And in the sense of internal development, and in the sense of achieving results.
If you replace the master with timlida in scrum, what will happen? This can no longer be called scrum - one of the key roles has been thrown out. And how will it affect the result? And if at all without a scrum master? If its functions are smudged on command, how was Belbin recommended? One facilitates, the other motivates, the third monitors the implementation of the rules. It’s quite possible for yourself to live like that.
Well, everything, then the principle is clear. Scrum, like any other technique, is an algorithm woven from components, or tools. Who weaved it? Well, let's say Jeff Sutherland and Ken Schwaber.
Imagine that two guys, Jeff and Ken, created a component that brings good benefits in the development of web applications. You dug it in a github, installed it, tried it - wow, it's cool! Works! And the truth is, it has become better!
And then, at some point, something began to annoy you in this component. For example, calling his methods seems not polymorphic enough. You go into the source code and discover ...
What can you find there? Yes, anything. For example, borrowing that you do not like. Or borrowed components will be correct, but crookedly used. Or a specific version of a good component is explicitly indicated, but it is developing well and has become much cooler a long time ago, but developers do not want to adapt a higher-level component. Or you find in the algorithm a piece of a decent size that eats resources well, but does not bring any particular benefit to your project.
What will you do? Each will answer something different, of course. Someone will not even get inside. Someone will fork and correct what they don't like. Of course, it will gain some problems with updating. Although, not a fact - such things as scrum do not change for years. Someone will write to the developers. I don’t know what they will answer.
Someone just takes the original components, and rebuild them in their own way - as it should in a particular project or product.
You can do the same with any technique. I wanted to write “it is possible and necessary”, but did not impose my opinion - everyone decides after all.
I want to finish with a Goldratt quote. This is probably the only one of the luminaries who developed some methods, honestly talking about the need for their change, adaptation, layout and, most importantly, understanding of the principles of functioning.
There are engineers and programmers in the world. Sometimes all rolled into one. People who understand what an algorithm is. Moreover, people who create these algorithms. They are well aware that the created algorithm is suitable for solving one problem, but is not suitable for another. Understanding that if the algorithm is slightly changed, then it will be able to solve related problems. Do not hesitate to throw out half of someone else's algorithm so that it better solves the current problem.
Programmers create a solution for a task, or for a class of tasks. This is the essence of the profession. Where possible, use ready-made pieces of their own or someone else's code. And all is well.
But, as soon as it comes to creating algorithms outside the computer, programmers suddenly lose their heads. I'm not talking about drawing algorithm diagrams on paper, as was the case at the university exam - here any of us can handle it.
I’m talking about “implementation of techniques”, “work on the framework”, “mandatory use of all artifacts”. About sects, in short.
A bit of idiocy
Everyone knows what a conditional operator is. There is no life without him. No decent algorithm will work. Neither in the computer, nor in life.
Now imagine: a certain person appeared, for example, John, and noticed that there is a conditional statement in BASIC. I picked it up, figured it out, made sure - there is, it works, without it in any way.
Let's say John is dumb. But he decided to conquer the world. Went to sell BASIC. Not the language itself, but some kind of “coolest software development technique”, the central link of which is ... And John will not say until you complete the course.
Okay, there were course lovers, especially since the price is not high. They came, listened, gasped. The main element of the coolest software development methodology is the Conditional Operator. We listened a lot about the conditional statement. For example, how to turn it into a multiple choice operator. They gasped again - what a powerful Conditional Operator.
Half of the audience was programmers. Neighing, went home. Another quarter were managers. They became thoughtful, posed questions, someone decided to implement this cool methodology at home. The last quarter were the same as John. They persuaded the guy to create a franchise, Community, Certification Authority and Contingent University.
Programmers from the course returned to work, no longer remembering the Conditional Operator. But an hour later, managers came and announced that now software development will be conducted according to the coolest method. Yes, which is about the Conditional Operator. In general, it’s better to write in basic.
The timid, if not timid objections of the programmers were ignored. Phrases such as “damn it is a conditional operator, it is everywhere” were perceived as attempts to show off. The wheel spun.
And John quickly realized that just one Conditional Operator is not enough. There should also be a Loop, Subroutine, Variable, Array, etc. We should somehow call all this ... In a word ... Oh, let it be Artifacts! No more, no less!
The main thing remained: to add to the methodology the clause that the coolest software development methodology is holistic, holistic knowledge. So, not a single piece can be thrown out of it. And you can’t add anything to it - it will stop working. As it is written, so do it.
Thanks to the enthusiasm of John and his friends, now the whole world uses not a conditional operator, but a Conditional Operator, not a cycle, but a Cycle, etc., according to the list. Those who understood the idiocy of the situation had long retired or shut up. Those who have come recently strongly believe that the Conditional Operator is part of the coolest software development methodology created by John. And all other conditional operators are a miserable likeness, a faded copy and a piece of Knowledge torn out of context.
Anyone who dares to vote on the Internet (or, God forbid, inside the team) will be subjected to fierce condemnation and angry minusculation - you, boots, do not see the benefits of the Conditional Operator! And if the unfortunate person asks to explain what is the meaning and difference from the conditional operator in C ++, javascript or even 1C, he will get the answer “it’s impossible to explain”, “you don’t understand”, or “go read the guide”.
Tools and Algorithms
Everyone understands what a conditional operator is, and how to use it in algorithms. In the same way, everyone understands what, for example, is a sticker with a recorded task. Stickers appeared before the scrum, and live outside it. Look at the computer of the accountant, supplier, or seller. They have not yet eliminated the habit of hanging a bunch of stickers with urgent tasks on the monitor. A password will be written on one of the stickers.
Any technique is easily disassembled into tools, principles, and relationships. Just like any algorithm is disassembled into figures of different forms and purposes - the beginning and end of the algorithm, action, condition, subroutine.
Any technique has a scope. Not everything is absolutely there - there is a more suitable environment, there is less. Same as algorithms.
Any technique can be modified. Throw out pieces, add new ones, modify specific tools. Just like algorithms.
Any techniques can be mixed, in whole or in pieces. Take half of one, a quarter from the other, another quarter - invent yourself. When you create an application or service, it is obvious to you.
True, the question remains - will the methodology be a methodology, if it is changed?
Here's how to answer this question, for example, the well-known Scrum Guide:
“The roles, artifacts, rules and events of Scrum are not subject to change. Although the use of individual elements of this framework is acceptable, the result can not be called Scrum. Scrum exists only as a whole framework, but it can accommodate other techniques, methodologies and practices. ”A bit like John and his Conditional Operator, isn't it? It seems like, change if you want, only it will not be a scrum. And what the result will be - hell knows. Just in case, they noted that you can try to shove something inside. But the backbone must remain. Otherwise ... It’s even scary to imagine.
Is it really scary? What will happen if some of the artifacts are thrown out or replaced? And in general, what's the point? Where did they come from? Why is it believed that they work only in such a combination, as the authors decided?
Let's try to figure out the parts.
Sprint and Sprint Backlog
Great tool, by the way. Invented, probably, a thousand years ago. It’s always been called differently, but the most common, probably, is the “Plan”. And humanly - "to do a certain amount of work for a certain period of time."
To me, as 1Sniku, it is better known as space-calendar planning (OKP). It is widely used in production and sales planning. For example, a manager’s sales plan of 1 million rubles per month is a backlog and sprint. Sometimes a figure is enough, sometimes there is a breakdown by product group, or restrictions on the market, or there is even a specific list of items, if required by the company's strategy.
The production is even easier. Bushings - 1000 pcs., Shafts - 2000 pcs., Rotors - 500 pcs. This is, say, a weekly plan. He is the backlog of the weekly sprint of the production site. True, you can not explain to the workers that this is not a plan, but a sprint.
The tool is good in comparison with the widespread time management, when the programmer’s task pool is estimated by labor costs, sorted by some criterion, and each task has a deadline. In production, this is called shift planning, or workshop planning, from which production tasks are then created containing a list of parts and semi-finished products, technical operations, materials, inputs and outputs (where to get what and where to transfer the result).
For programmers, workshop planning does not work well, and there is nothing to discuss here. The processing time of a part on a specific model of the machine has been known for a long time and quite accurately. Frequency of service - too. Sufficiency of materials evaluated. Take and do. Variations that interfere with the implementation of the plan in mass production usually do not have a significant effect. And if they do, there are excellent methods for analyzing and eliminating them.
Programmer variations are much stronger. He is not a machine tool, just as some managers who came to IT from sales or production would not like. Therefore, workshop planning (task + deadline) is not suitable for a programmer. So sensible people came up with - you need to rise to a higher level, not to schedule the performance in minutes, but give volume for a period. Only they came up with another name - sprint and backlog.
Filling the volumetric-calendar production plan is based on principles similar to the formation of a sprint backlog. Even there is such a thing - "pick a plan." There are the needs of the same sales department (= large backlog), there is production throughput (= team capabilities in numbers), plus there are clear selection criteria - the amount of sales, profitability of each position, customer parameters (for example, payment terms). Scored a production plan - and immediately see what an approximate financial result you get. This is not an ephemeral "release."
Are there any drawbacks to this tool? Of course, like any other.
If you understand, the sprint backlog is the same workshop planning, only without a well-organized sequence of problem solving. Therefore, all tasks have one deadline - the end of the sprint. Once the tasks have one deadline, an unpleasant effect appears - at the beginning of the sprint, activity can be significantly lower than at the end.
This is how any human psychology works. One always wants to fall for the start of the execution period, whether it is one task, or a backlog. Take a break from the past period, especially - from its final part, when it was necessary to give a "huge" result. Of course, there are people who are stable and rhythmic, working all week at the same speed, but most begin to "work normally" somewhere on Wednesday.
Is it possible to do without sprint and its backlog? Easy.
For example, using the tool "as soon as possible." In general, this is not a Praporsky manners, but quite a normal strategy for the same workshop planning (As Soon As Possible, ASAP). It means that the issues will “stick” to the beginning of the time interval, i.e. By Monday, not Friday, as in the “As Last As Possible, ALAP” strategy.
Planning as such is not necessary in this case. There is a product backlog, there are priorities, there is a rule "as soon as possible." You take the first and do it. Finished - take the second. And so - from the fence to dinner. Sprint, or rather, its essence, i.e. the length of time you can leave for understanding and analyzing performance (week to week, month to month, etc.).
Are there any shortcomings in the strategy "as soon as possible"? Of course, a million. First of all, a person can get tired quickly. Secondly, he will feel like a machine tool. Thirdly, he will most likely run away - to where ordinary sprints with a backlog are used. Or they simply set tasks and wait for the result. In general, where it is calmer. But practice shows that "as soon as possible" is quite possible to live for years, if it is common sense that this is a planning strategy, and not a sweatshirt.
Is it possible to throw a sprint and its backlog? Not. Not because these are unique notions of the same scrum, but because this is a natural planning method that everyone, in one form or another, uses. There are many variations, one principle - you need to do a certain amount of work for a certain period of time.
Is a tool like sprint a unique and key element of any technique? Not. This is the same as saying that typing code on the keyboard is a unique notion of some technique. Almost all texts are typed on the keyboard.
Scrum board
Formally, a board is not an artifact or a rule, but I think it's worth talking about it too, because there is a fairly obvious pattern among people: a scrum is a board with stickers.
Here, in general, you yourself understand everything. A board with stickers on which tasks are written is not unique. This is, roughly speaking, a cross-platform tool. My wife on the refrigerator sometimes sculpts stickers with to-do lists, although she knows nothing about any scrum.
Is this tool good? It depends on what you compare it to. Yes, perhaps a good one.
For example, it allows you to quickly evaluate, look around the pool of tasks. In a computer, or any other electronic device, tasks need to be flipped - everything usually does not fit on one screen. Therefore, at one glance - too.
Another important plus is the overall availability for the team. At any time, you can come and see, do not go into any system, search, make a selection, etc.
Many people like the non-virtual nature of the board. After all, everything is virtual in a computer; you don’t touch it with your hands. And here - please, at least lick. Some, in this regard, love cork boards. The difference is something like between paper and electronic books.
Specifically for a scrum board, one can note such an advantage as separation into two parts - this is done at work. Household handling of stickers involves throwing out those that are already completed - not very good, because progress is seen worse.
Are there any disadvantages of scrum boards? Of course. Like any board.
To begin with household ones - drafts, poor-quality stickers, poor handwriting, sabotage. As a result, lost tasks and confusion in management.
On the board, progress is not very visible. In general, for the sprint - yes. Today, yesterday - no. Hence the need for daily discussions.
Specifically, the status of tasks is not visible on the scrum board, if life is more complicated than “planned” - “done”. Kanban board looks preferable.
The board does not allow normal work if the team is geographically distributed. Therefore, electronic boards appear.
The electronic board, it seems to me, is a sure sign of sectarianism. She lost all the benefits of the usual, but, for some unknown reason, she continues to use it. Probably just because it's a board. Part of the Methodology.
In general, a tool is like a tool. In certain situations - good. In some it’s terrible.
Will scrum work without a board? Easy. And proven by practice. And it seems like, since the board is not an obligatory artifact, it will be possible to continue to call scrum - scrum.
Scrum master
Who is this miracle role? What is it like?
There are many options. For example, a scrum master is like a trainer in sports. There is, say, a football club. The owner of the products there is a manager who defines the goals of the team. A coach is one who helps a team achieve these goals.
In an ordinary, production environment, there are no coaches - if the football club worked like that, the boss would simply come to the locker room before the match and say: “go and win.” And when they lose, he would be happy with the scam. He kicked someone, threatened someone, etc. Like a factory.
And the coach, like the scrum master, serves as the provider between the team and the manager. Of course, the coach has more power - he is not a leader servant. But the result is also required from him faster and more understandable - no one will wait until he facilitates someone there. The coach, like the scrum master, understands how the team should function, i.e. he simply sets tasks, and explains how to solve them. Establishes connections, motivates, creates and maintains an atmosphere, etc.
Another analogy is the platoon commander, some special forces. This is a gaming coach. Goes on tasks together with subordinates, solves combat missions in the same way. In his free time, he supervises the preparation and improvement of skill, the development of new equipment, and physical training. Of course, he constantly works with the team in terms of psychology - it motivates, supports, helps. By peculiar methods, of course, sometimes, but the goal is one - the maximum combat effectiveness of a platoon.
Scrum master, compared with these guys, a freeloader. For the result is not particularly responsible. The lack of formal authority seems to be perceived as an advantage - he is a leader-servant, but in fact he can develop into irresponsibility. Can one endlessly facilitate, without exerting any influence on the result? And when they kick them out, look for another team to facilitate there.
Is it possible to change or remove the role of a scrum master? Of course. For example, combine this role with the product owner. I know that in the Methodology it is written that it’s better not to do this - this will prevent the master from facilitating. But, on the other hand, it will add clear goals and responsibilities. When the goal is understandable and measurable, then the facilitation turns from an optional, incomprehensible crap into a very specific, tangible duty that directly affects the result. Like a trainer or a squad.
True, then the meaning of calling him a scrum master is lost. This will probably be a team leader - do not forget that the "lead" is the leader. A leader is not only a flag in his hands, but also work with motivation, goals, the ability to carry along, introducing new methods of work, training competencies, etc. The driver of the command, in short. And in the sense of internal development, and in the sense of achieving results.
If you replace the master with timlida in scrum, what will happen? This can no longer be called scrum - one of the key roles has been thrown out. And how will it affect the result? And if at all without a scrum master? If its functions are smudged on command, how was Belbin recommended? One facilitates, the other motivates, the third monitors the implementation of the rules. It’s quite possible for yourself to live like that.
Total
Well, everything, then the principle is clear. Scrum, like any other technique, is an algorithm woven from components, or tools. Who weaved it? Well, let's say Jeff Sutherland and Ken Schwaber.
Imagine that two guys, Jeff and Ken, created a component that brings good benefits in the development of web applications. You dug it in a github, installed it, tried it - wow, it's cool! Works! And the truth is, it has become better!
And then, at some point, something began to annoy you in this component. For example, calling his methods seems not polymorphic enough. You go into the source code and discover ...
What can you find there? Yes, anything. For example, borrowing that you do not like. Or borrowed components will be correct, but crookedly used. Or a specific version of a good component is explicitly indicated, but it is developing well and has become much cooler a long time ago, but developers do not want to adapt a higher-level component. Or you find in the algorithm a piece of a decent size that eats resources well, but does not bring any particular benefit to your project.
What will you do? Each will answer something different, of course. Someone will not even get inside. Someone will fork and correct what they don't like. Of course, it will gain some problems with updating. Although, not a fact - such things as scrum do not change for years. Someone will write to the developers. I don’t know what they will answer.
Someone just takes the original components, and rebuild them in their own way - as it should in a particular project or product.
You can do the same with any technique. I wanted to write “it is possible and necessary”, but did not impose my opinion - everyone decides after all.
I want to finish with a Goldratt quote. This is probably the only one of the luminaries who developed some methods, honestly talking about the need for their change, adaptation, layout and, most importantly, understanding of the principles of functioning.
There is a difference between practical methods and the fundamental concepts on which these methods are based. Concepts are general, practical methods are the adaptation of concepts to a specific environment. As we have already seen, such an adaptation is not simple, and makes it necessary to develop certain elements of the solution. What we should remember is that such a solution is based on the initial premises (sometimes hidden) about a specific environment. We should not expect this solution to work in an environment for which these initial premises are not true. We can save a lot of effort and avoid disappointment if we carefully formulate these initial premises.