How to escape from the sect?
Our world is very strange. And the farther, the more strange it becomes. And fuck understand what's the matter.
There are engineers and programmers in the world. Sometimes in one person. People who understand what an algorithm is. Moreover, the people who create these algorithms. Well aware that the created algorithm is suitable for solving one problem, but not suitable for another. Understand that if the algorithm is slightly modified, then it will be able to solve related problems. Do not hesitate to throw out half of someone else's algorithm, so that it can better solve the current problem.
Programmers create a solution for a task, or a task class. This is the essence of the profession. Where possible, use ready-made pieces of his 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 algorithms on paper, as it was in the university exam - here any of us can handle it.
')
I'm talking about the "implementation of techniques", "work on the framework", "mandatory use of all artifacts." About sects, in short.
Everyone knows what a conditional operator is. Without it, there is no life. No decent algorithm will work. Neither the computer nor in life.
Now imagine: a certain man appeared, let's say - John, and noticed that there is a conditional operator in BASIC. I dig deeper, figured it out, made sure - it is, it works, without it in any way.
For example, John - stupid. But he decided to conquer the world. I went to sell BASIC. Not the language itself, but some kind of “coolest software development methodology”, the central element of which is ... But John will not say until he completes the course.
Well, there were lovers of courses, 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 operator. For example, how to turn it into a multiple choice operator. Once again gasped - what a mighty Conditional Operator.
Half of the audience was programmers. Naughty, went home. Another quarter were managers. They pondered, asked questions, someone decided to introduce this cool method in their own. The last quarter was the same as John. They persuaded the guy to create a franchise, a Community, a Certification Center and a University of Conditional Operator.
Programmers from the course returned to work without remembering the Conditional Operator. But an hour later, the managers came and announced that now software development will be carried out according to the coolest method. Yes, which is about the Conditional Operator. And in general, it is better to write in BASIC.
Timid, if not timid objections of programmers were ignored. Phrases like “damn, this is a conditional operator, it is everywhere” were perceived as attempts to show off. The wheel spun.
And John quickly realized that there was not enough of one Conditional Operator. There must also be a Cycle, Routine, Variable, Array, etc. We should somehow call it all ... In one word ... Oh, let it be Artifacts! No more, no less!
It remains the main thing: to introduce into the methodology a clause stating that the coolest software development technique is holistic, holistic knowledge. Hence, it is impossible to throw a single piece out of it. And nothing can be added to it - it will stop working. As written, so do.
Thanks to the enthusiasm of John and his friends, the whole world now uses not a conditional operator, but the Conditional Operator, not a cycle, but a Cycle, etc., according to the list. Those who understood the idiocy of the situation, have long retired or shut up. Those who have come recently firmly believe that the Conditional Operator is part of the coolest software development technique created by John. And all the other conditional operators are a miserable likeness, a faded copy and a piece of Knowledge torn out of context.
Anyone who dares to cast a vote on the Internet (or, God forbid, within the team), will be subjected to fierce condemnation and angry minus - you see, boots, you do not see the advantages of the Conditional Operator! And if the unfortunate asks to explain what is the meaning and difference from the conditional operator in C ++, javascript or even 1C, he will receive in reply “it’s impossible to explain”, “you don’t understand”, or “read the guide”.
Everyone understands what a conditional operator is, and how to use it in algorithms. In the same way, everyone understands what a sticker with a recorded task is, for example. Stickers appeared before the scrum, and live outside it. Look at the computer of the accountant, supplier or seller. They have not yet overcome the habit of hanging on the monitor a bunch of stickers with urgent tasks. A password will be written on one of the stickers.
Any technique is easily understood on the tools, principles and relationships. Just as any algorithm understands the figures of different forms and purposes - the beginning and end of the algorithm, action, condition, subroutine.
Any technique has scope. Not everything is absolutely there - there is a more suitable environment, there is less. Just like the algorithms.
In any method you can make changes. Throw out pieces, add new ones, modify specific tools. Just like the algorithms.
Any method can be mixed, in whole or in pieces. Take half of one, a quarter of the other, another quarter - to invent yourself. When you create an application or service, for you it is obvious.
True, the question remains - will the method be a technique if it is changed?
Here is how a widely known Scrum Guide answers this question, for example:
Is it really scary? What happens if a part of the artifacts is thrown out or replaced? And in general, what's the point? Where did they come from? Why is it considered that they work only in such a combination, as the authors decided?
Let's try to understand in parts.
Great tool, by the way. Invented, probably, a thousand years ago. It was only called always in different ways, but the most probably prevalent is “Plan”. And humanly - "to do a certain amount of work for a certain period of time."
I, as 1Sniku, he is better known as space-scheduling (GST). It is widely used in the planning of production and sales. For example, the sales plan for a manager, equal to 1 million rubles a month, is backlog and sprint. Sometimes numbers are enough, sometimes there is a breakdown by product groups, or restrictions on the sales market, or even there is a specific list of nomenclature, if required by the company's strategy.
The production is even easier. Sleeves - 1000, shafts - 2000, rotors - 500. This is, say, a weekly plan. He is the backlog of the weekly sprint of the production site. True, the workers can not explain that this is not a plan, but a sprint.
The tool is good in comparison with common time management when the programmer’s task pool is estimated by labor costs, ordered by some criterion, and each task is given a due date. In production, this is called shift or shop planning, from which production tasks are then created, containing a list of parts and semi-finished products, technical operations, materials, entrances and exits (where to take and where to transfer the result).
For programmers, workshop planning works poorly, there is nothing to discuss here. The processing time of a part on a specific machine model has been known for a long time and quite accurately. Frequency of service - too. Sufficiency of materials is estimated. Take it and do it. Variations that interfere with the implementation of the plan in mass production usually do not have a significant impact. And if they do, there are excellent methods for analyzing and eliminating them.
Programmer variations are much stronger. After all, he is not a machine tool, no matter how much some managers, who come to IT from sales or production, would like to. Therefore, shop planning (task + deadline) is not suitable for a programmer. So, smart people came up with it - you need to go up a level, not to paint the performance by the minute, but to give volume for the period. Only another name was invented - sprint and backlog.
Filling the volume-production schedule is based on principles similar to the formation of the backlog of the sprint. There is even such a thing - “to recruit a plan”. There are needs of the same sales department (= large backlog), there is production capacity (= team capabilities in numbers), plus there are clear selection criteria - the amount of sales, the profitability of each position, customer parameters (for example, payment terms). Scored a production plan - and immediately see what kind of 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, backlog sprint - the same shop planning, only without a built-in sequence of problem solving. Therefore, all tasks have one deadline - the end of the sprint. Once a task has a deadline, then an unpleasant effect appears - at the beginning of the sprint, the activity can be significantly lower than at its end.
This is how any human psychology works. You always want to get involved at the beginning of the performance period, be it one task, or backlog. Take a break from the past period, especially from its final part, when we had to give a tremendous result “on the mountain”. There are, of course, people who are stable and rhythmic, working all week at the same speed, but most of them start “working normally” somewhere on Wednesday.
Is it possible to do without a sprint and its backlog? Easy.
For example, using the tool "as soon as possible." In general, this is not a praporskaya manner, but quite a normal strategy of 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, and not by Friday, as in the “Last Last Possible, ALAP” planning strategy.
Planning, as such, is not necessary in this case. There is a backlog of product, there are priorities, there is a rule "as soon as possible." You take the first and do it. Finished - you take the second. And so - from the fence to dinner. Sprint, or rather its essence, i.e. the length of time you can leave to understand and analyze performance (week by week, month by month, etc.).
Are there any shortcomings of the strategy “as quickly as possible”? Of course, a million. First, a person can quickly get tired. Secondly, he will feel like a machine. Thirdly, he, most likely, will run away - to the place where usual sprints with backlog are used. Or just set tasks and wait for the result. In general, where quieter. But practice shows that “as quickly as possible” it is quite possible to live for years, if it is sensible to understand that this is a planning strategy, and not sweating.
Is it possible to throw out the sprint and its backlog? Not. Not because it is unique notions of the same scram, but because it is a natural planning method that everyone uses in one form or another. There are many variations, one principle - you need to do a certain amount of work for a certain period of time.
Is such a tool as a sprint a unique and key element of any methodology? Not. It is the same as to say that typing code on a keyboard is a unique notion of a certain technique. Almost all texts are typed on the keyboard.
Formally, a board is not an artifact or a rule, but I think it is also worth talking about it, because there is a fairly obvious pattern among people: Scrum is a board with stickers.
Here, in general, you yourself understand everything. The board with stickers on which tasks are written is not unique. This is, roughly speaking, a cross-platform tool. My wife on the fridge sometimes sculpts stickers with to-do lists, although she knows nothing about what kind of scrum.
Is this tool good? It depends on what you compare it to. Yes, perhaps good.
For example, it allows you to quickly evaluate, look at the pool of tasks. In a computer, or any other electronic device, tasks need to be scrolled - in one screen everything, usually, does not fit. Consequently, in one glance - as well.
Another important plus is general accessibility for the team. At any time, you can come and see, do not go into any system, search, make a sample, etc.
Many people like the non-virtuality of the board. In the computer, everything is virtual, you won't touch it with your hands. And then - please, even lick. Some, in this regard, like cork boards. The difference is something like paper and electronic books.
Specifically, for the scram-board, it is possible to note such an advantage as the separation into two parts - in work and executed. Household handling of stickers involves discarding those that have already been completed - not very good, because progress is worse.
Are there any drawbacks to the scrum board? Of course. Like any board.
Start with household - drafts, poor-quality stickers, bad handwriting, sabotage. The result - lost tasks and confusion in management.
On the board is not very visible progress. In general, for the sprint - yes. For today, yesterday - no. Hence the need for daily discussions.
Specifically, on the scrum-board, task statuses are not visible, if life is more complicated than “planned” - “done”. Preferred looks kanban board.
The board does not allow to work normally 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 enjoy. Probably just because it is a board. Part of the Method.
In general, a tool like a tool. In certain situations - good. In some - terrible.
Will scrum work without a board? Easy. And proven 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 coach in a sport. There is, say, a football club. The owner of the products there is a manager who defines the goals of the team. The coach is the one who helps the team achieve these goals.
In a normal production environment, there are no coaches - if the football club worked this way, then the head would just come to the locker room before the match and say: “go and win”. And when they lose, would arrange spacing. Someone chased, threatened someone, etc. As in the factory.
And the coach, like the scrum master, serves as a provider between the team and the manager. The power of the coach, of course, more - he is not a leader-servant. But the result is required of him to be 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 those tasks, and explains how to solve them. Forges connections, motivates, creates and maintains the atmosphere, etc.
Another analogy - the commander of a platoon, special forces of some kind. This is a playing coach. Goes to tasks together with subordinates, in the same way solves fighting tasks. In his spare time - leads the preparation and improvement of skills, the development of new technology, physical training. Of course, constantly working with the team in terms of psychology - motivates, supports, helps. Of course, with peculiar methods, sometimes, but the goal is one — maximum platoon combat capability.
Scrum master, compared with these guys, a freeloader. For the result is not particularly responsible. The absence of a formal power seems to be perceived as an advantage - it’s the leader-servant, but in fact it can turn into irresponsibility. Is it possible to facilitate to infinity, without exerting any influence on the result? And when they are kicked out - look for another team to facilitate there.
Is it possible to change or remove the role of scrum master? Of course. For example, combine this role with the owner of the product. I know, in the Methodology it is written that it is better not to do this - it will prevent the master from facilitating. But, on the other hand, it will add clear goals and responsibility. When the goal is clear and measurable, then facilitation turns from optional, incomprehensible shit into a very specific, tangible duty that directly affects the result. Like a coach or komvzvoda.
True, then the meaning of calling him a scram master will be lost. This will probably be a tmlid - do not forget that the “lead” is the leader. And a leader is not only a flag in his hands, but also work with motivation, goals, the ability to carry along, the introduction of new working methods, the training of competencies, etc. Driver commands, in short. And in the sense of internal development, and in the sense of achieving the result.
If in the scram replace the wizard with timlid, what will happen? Scramme can no longer be called - 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 his functions are spread out on command, as Belbin recommended? One facilitates, the other motivates, the third follows the execution of the rules. Quite so you can 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 value in developing web applications. You dug it in a githaba, installed it, tried it - wow, cool! Works! And indeed, it became better!
And then, at some point, something in this component became annoying to you. For example, calling his methods does not seem to be polymorphic enough. You enter the source code and discover ...
What can you find there? Yes, whatever. 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 directly indicated, but it develops well and has long been steeper at times, but the developers do not want to adapt the superior component. Or you find in the algorithm a decent-sized piece, which is not bad at eating resources, but not carrying any benefit specifically for your project.
What will you do? Everyone will answer something of course. Someone even does not climb inside. Someone will fork and correct what they don’t like. Will find, of course, some problems with the update. Although not a fact - such things as scrum, do not change over the years. Someone will write to the developers. I don’t know what they will answer.
Someone just takes the source components and rebuilds them in their own way - the way it should be in a particular project or product.
You can do the same with any technique. I wanted to write "can and should be," but did not impose their opinion - everyone, after all, decides for himself.
I want to finish the quote Goldratt. This is perhaps the only one of the luminaries who have developed some methodologies that honestly spoke of the need to change them, adapt, assemble and, most importantly, understand the principles of operation.
There are engineers and programmers in the world. Sometimes in one person. People who understand what an algorithm is. Moreover, the people who create these algorithms. Well aware that the created algorithm is suitable for solving one problem, but not suitable for another. Understand that if the algorithm is slightly modified, then it will be able to solve related problems. Do not hesitate to throw out half of someone else's algorithm, so that it can better solve the current problem.
Programmers create a solution for a task, or a task class. This is the essence of the profession. Where possible, use ready-made pieces of his 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 algorithms on paper, as it was in the university exam - here any of us can handle it.
')
I'm talking about the "implementation of techniques", "work on the framework", "mandatory use of all artifacts." About sects, in short.
A bit idiocy
Everyone knows what a conditional operator is. Without it, there is no life. No decent algorithm will work. Neither the computer nor in life.
Now imagine: a certain man appeared, let's say - John, and noticed that there is a conditional operator in BASIC. I dig deeper, figured it out, made sure - it is, it works, without it in any way.
For example, John - stupid. But he decided to conquer the world. I went to sell BASIC. Not the language itself, but some kind of “coolest software development methodology”, the central element of which is ... But John will not say until he completes the course.
Well, there were lovers of courses, 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 operator. For example, how to turn it into a multiple choice operator. Once again gasped - what a mighty Conditional Operator.
Half of the audience was programmers. Naughty, went home. Another quarter were managers. They pondered, asked questions, someone decided to introduce this cool method in their own. The last quarter was the same as John. They persuaded the guy to create a franchise, a Community, a Certification Center and a University of Conditional Operator.
Programmers from the course returned to work without remembering the Conditional Operator. But an hour later, the managers came and announced that now software development will be carried out according to the coolest method. Yes, which is about the Conditional Operator. And in general, it is better to write in BASIC.
Timid, if not timid objections of programmers were ignored. Phrases like “damn, this is a conditional operator, it is everywhere” were perceived as attempts to show off. The wheel spun.
And John quickly realized that there was not enough of one Conditional Operator. There must also be a Cycle, Routine, Variable, Array, etc. We should somehow call it all ... In one word ... Oh, let it be Artifacts! No more, no less!
It remains the main thing: to introduce into the methodology a clause stating that the coolest software development technique is holistic, holistic knowledge. Hence, it is impossible to throw a single piece out of it. And nothing can be added to it - it will stop working. As written, so do.
Thanks to the enthusiasm of John and his friends, the whole world now uses not a conditional operator, but the Conditional Operator, not a cycle, but a Cycle, etc., according to the list. Those who understood the idiocy of the situation, have long retired or shut up. Those who have come recently firmly believe that the Conditional Operator is part of the coolest software development technique created by John. And all the other conditional operators are a miserable likeness, a faded copy and a piece of Knowledge torn out of context.
Anyone who dares to cast a vote on the Internet (or, God forbid, within the team), will be subjected to fierce condemnation and angry minus - you see, boots, you do not see the advantages of the Conditional Operator! And if the unfortunate asks to explain what is the meaning and difference from the conditional operator in C ++, javascript or even 1C, he will receive in reply “it’s impossible to explain”, “you don’t understand”, or “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 a sticker with a recorded task is, for example. Stickers appeared before the scrum, and live outside it. Look at the computer of the accountant, supplier or seller. They have not yet overcome the habit of hanging on the monitor a bunch of stickers with urgent tasks. A password will be written on one of the stickers.
Any technique is easily understood on the tools, principles and relationships. Just as any algorithm understands the figures of different forms and purposes - the beginning and end of the algorithm, action, condition, subroutine.
Any technique has scope. Not everything is absolutely there - there is a more suitable environment, there is less. Just like the algorithms.
In any method you can make changes. Throw out pieces, add new ones, modify specific tools. Just like the algorithms.
Any method can be mixed, in whole or in pieces. Take half of one, a quarter of the other, another quarter - to invent yourself. When you create an application or service, for you it is obvious.
True, the question remains - will the method be a technique if it is changed?
Here is how a widely known Scrum Guide answers this question, for example:
“The roles, artifacts, rules and events of Scrum are not subject to change. Although the use of individual elements of this framework is permissible, the result obtained cannot 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 scrub. And what will be the result - hell knows. Just in case, noted that you can try to shove something inside. But the backbone should remain. Otherwise ... Even scary to imagine.
Is it really scary? What happens if a part of the artifacts is thrown out or replaced? And in general, what's the point? Where did they come from? Why is it considered that they work only in such a combination, as the authors decided?
Let's try to understand in parts.
Sprint and Backlog Sprint
Great tool, by the way. Invented, probably, a thousand years ago. It was only called always in different ways, but the most probably prevalent is “Plan”. And humanly - "to do a certain amount of work for a certain period of time."
I, as 1Sniku, he is better known as space-scheduling (GST). It is widely used in the planning of production and sales. For example, the sales plan for a manager, equal to 1 million rubles a month, is backlog and sprint. Sometimes numbers are enough, sometimes there is a breakdown by product groups, or restrictions on the sales market, or even there is a specific list of nomenclature, if required by the company's strategy.
The production is even easier. Sleeves - 1000, shafts - 2000, rotors - 500. This is, say, a weekly plan. He is the backlog of the weekly sprint of the production site. True, the workers can not explain that this is not a plan, but a sprint.
The tool is good in comparison with common time management when the programmer’s task pool is estimated by labor costs, ordered by some criterion, and each task is given a due date. In production, this is called shift or shop planning, from which production tasks are then created, containing a list of parts and semi-finished products, technical operations, materials, entrances and exits (where to take and where to transfer the result).
For programmers, workshop planning works poorly, there is nothing to discuss here. The processing time of a part on a specific machine model has been known for a long time and quite accurately. Frequency of service - too. Sufficiency of materials is estimated. Take it and do it. Variations that interfere with the implementation of the plan in mass production usually do not have a significant impact. And if they do, there are excellent methods for analyzing and eliminating them.
Programmer variations are much stronger. After all, he is not a machine tool, no matter how much some managers, who come to IT from sales or production, would like to. Therefore, shop planning (task + deadline) is not suitable for a programmer. So, smart people came up with it - you need to go up a level, not to paint the performance by the minute, but to give volume for the period. Only another name was invented - sprint and backlog.
Filling the volume-production schedule is based on principles similar to the formation of the backlog of the sprint. There is even such a thing - “to recruit a plan”. There are needs of the same sales department (= large backlog), there is production capacity (= team capabilities in numbers), plus there are clear selection criteria - the amount of sales, the profitability of each position, customer parameters (for example, payment terms). Scored a production plan - and immediately see what kind of 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, backlog sprint - the same shop planning, only without a built-in sequence of problem solving. Therefore, all tasks have one deadline - the end of the sprint. Once a task has a deadline, then an unpleasant effect appears - at the beginning of the sprint, the activity can be significantly lower than at its end.
This is how any human psychology works. You always want to get involved at the beginning of the performance period, be it one task, or backlog. Take a break from the past period, especially from its final part, when we had to give a tremendous result “on the mountain”. There are, of course, people who are stable and rhythmic, working all week at the same speed, but most of them start “working normally” somewhere on Wednesday.
Is it possible to do without a sprint and its backlog? Easy.
For example, using the tool "as soon as possible." In general, this is not a praporskaya manner, but quite a normal strategy of 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, and not by Friday, as in the “Last Last Possible, ALAP” planning strategy.
Planning, as such, is not necessary in this case. There is a backlog of product, there are priorities, there is a rule "as soon as possible." You take the first and do it. Finished - you take the second. And so - from the fence to dinner. Sprint, or rather its essence, i.e. the length of time you can leave to understand and analyze performance (week by week, month by month, etc.).
Are there any shortcomings of the strategy “as quickly as possible”? Of course, a million. First, a person can quickly get tired. Secondly, he will feel like a machine. Thirdly, he, most likely, will run away - to the place where usual sprints with backlog are used. Or just set tasks and wait for the result. In general, where quieter. But practice shows that “as quickly as possible” it is quite possible to live for years, if it is sensible to understand that this is a planning strategy, and not sweating.
Is it possible to throw out the sprint and its backlog? Not. Not because it is unique notions of the same scram, but because it is a natural planning method that everyone uses in one form or another. There are many variations, one principle - you need to do a certain amount of work for a certain period of time.
Is such a tool as a sprint a unique and key element of any methodology? Not. It is the same as to say that typing code on a keyboard is a unique notion of a certain 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 is also worth talking about it, because there is a fairly obvious pattern among people: Scrum is a board with stickers.
Here, in general, you yourself understand everything. The board with stickers on which tasks are written is not unique. This is, roughly speaking, a cross-platform tool. My wife on the fridge sometimes sculpts stickers with to-do lists, although she knows nothing about what kind of scrum.
Is this tool good? It depends on what you compare it to. Yes, perhaps good.
For example, it allows you to quickly evaluate, look at the pool of tasks. In a computer, or any other electronic device, tasks need to be scrolled - in one screen everything, usually, does not fit. Consequently, in one glance - as well.
Another important plus is general accessibility for the team. At any time, you can come and see, do not go into any system, search, make a sample, etc.
Many people like the non-virtuality of the board. In the computer, everything is virtual, you won't touch it with your hands. And then - please, even lick. Some, in this regard, like cork boards. The difference is something like paper and electronic books.
Specifically, for the scram-board, it is possible to note such an advantage as the separation into two parts - in work and executed. Household handling of stickers involves discarding those that have already been completed - not very good, because progress is worse.
Are there any drawbacks to the scrum board? Of course. Like any board.
Start with household - drafts, poor-quality stickers, bad handwriting, sabotage. The result - lost tasks and confusion in management.
On the board is not very visible progress. In general, for the sprint - yes. For today, yesterday - no. Hence the need for daily discussions.
Specifically, on the scrum-board, task statuses are not visible, if life is more complicated than “planned” - “done”. Preferred looks kanban board.
The board does not allow to work normally 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 enjoy. Probably just because it is a board. Part of the Method.
In general, a tool like a tool. In certain situations - good. In some - terrible.
Will scrum work without a board? Easy. And proven 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 coach in a sport. There is, say, a football club. The owner of the products there is a manager who defines the goals of the team. The coach is the one who helps the team achieve these goals.
In a normal production environment, there are no coaches - if the football club worked this way, then the head would just come to the locker room before the match and say: “go and win”. And when they lose, would arrange spacing. Someone chased, threatened someone, etc. As in the factory.
And the coach, like the scrum master, serves as a provider between the team and the manager. The power of the coach, of course, more - he is not a leader-servant. But the result is required of him to be 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 those tasks, and explains how to solve them. Forges connections, motivates, creates and maintains the atmosphere, etc.
Another analogy - the commander of a platoon, special forces of some kind. This is a playing coach. Goes to tasks together with subordinates, in the same way solves fighting tasks. In his spare time - leads the preparation and improvement of skills, the development of new technology, physical training. Of course, constantly working with the team in terms of psychology - motivates, supports, helps. Of course, with peculiar methods, sometimes, but the goal is one — maximum platoon combat capability.
Scrum master, compared with these guys, a freeloader. For the result is not particularly responsible. The absence of a formal power seems to be perceived as an advantage - it’s the leader-servant, but in fact it can turn into irresponsibility. Is it possible to facilitate to infinity, without exerting any influence on the result? And when they are kicked out - look for another team to facilitate there.
Is it possible to change or remove the role of scrum master? Of course. For example, combine this role with the owner of the product. I know, in the Methodology it is written that it is better not to do this - it will prevent the master from facilitating. But, on the other hand, it will add clear goals and responsibility. When the goal is clear and measurable, then facilitation turns from optional, incomprehensible shit into a very specific, tangible duty that directly affects the result. Like a coach or komvzvoda.
True, then the meaning of calling him a scram master will be lost. This will probably be a tmlid - do not forget that the “lead” is the leader. And a leader is not only a flag in his hands, but also work with motivation, goals, the ability to carry along, the introduction of new working methods, the training of competencies, etc. Driver commands, in short. And in the sense of internal development, and in the sense of achieving the result.
If in the scram replace the wizard with timlid, what will happen? Scramme can no longer be called - 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 his functions are spread out on command, as Belbin recommended? One facilitates, the other motivates, the third follows the execution of the rules. Quite so you can 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 value in developing web applications. You dug it in a githaba, installed it, tried it - wow, cool! Works! And indeed, it became better!
And then, at some point, something in this component became annoying to you. For example, calling his methods does not seem to be polymorphic enough. You enter the source code and discover ...
What can you find there? Yes, whatever. 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 directly indicated, but it develops well and has long been steeper at times, but the developers do not want to adapt the superior component. Or you find in the algorithm a decent-sized piece, which is not bad at eating resources, but not carrying any benefit specifically for your project.
What will you do? Everyone will answer something of course. Someone even does not climb inside. Someone will fork and correct what they don’t like. Will find, of course, some problems with the update. Although not a fact - such things as scrum, do not change over the years. Someone will write to the developers. I don’t know what they will answer.
Someone just takes the source components and rebuilds them in their own way - the way it should be in a particular project or product.
You can do the same with any technique. I wanted to write "can and should be," but did not impose their opinion - everyone, after all, decides for himself.
I want to finish the quote Goldratt. This is perhaps the only one of the luminaries who have developed some methodologies that honestly spoke of the need to change them, adapt, assemble and, most importantly, understand the principles of operation.
There is a difference between practical methods and the fundamental concepts on which these methods are based. Concepts are common, 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 have to remember is that such a decision is based on the underlying assumptions (sometimes hidden) about a particular environment. We should not expect this solution to work in an environment for which these initial assumptions are not correct. We can save a lot of effort and avoid disappointment if we scrupulously formulate these initial premises.
Source: https://habr.com/ru/post/451562/
All Articles