![scrum_en.png](https://res.cloudinary.com/hpiynhbhq/image/upload/v1519584623/ievem8zlcml0xycyr1rs.png)

<div class="text-justify">
Today, we often hear the following term: "the X company generates its software in the SCRUM". Probabbly, many people wonder what the SCRUM is and what does it mean?
</div>
<br>
<div class="text-justify">
The <b>SCRUM</b> is nothing more than a set of good practice rules and actions, causing the generation of final working product. For instance, the programming company gets an order to build the cryptocurrency exchange, something like Bittrex. If the company doesn't use the SCRUM, the generation process is accomplished in the way where someone gathers the requirements and lists them as a tasks. The list of tasks to accomplish is named the board. Next, the programmers take each task from the board and pursue it. Sometimes, the tasks are assigned to the particular programmers by their supervisors, who don't know that the task A is more complex than task B and assign them to people who may have more difficulties with them. In most cases, this approach can make a certain risk. We can split the risk into the following:
</div>
<br>
<b>1) The elongation of the project production time.<br>
2) The bad code quality.<br>
3) Wrong functionality interpretation by the uninformed programmers.<br></b>
<br>
<div class="text-justify">
These above three points mean the certain failure for the company, but the SCRUM methodology comes for the rescue. In practice, we create the competent team (3 to 10 people) responsible for the software production process. The team is the most important. We split the team to the three following roles:

* The <b>Product Owner</b>, the person who lucidly communicates the goal to achieve by the team and who represents the customer and his requirements. His task is to create the project registry and to inform the development team about all clue decisions.
* The <b>Scrum Master</b>, the person who cares of the knowledge of SCRUM methodology and usage of its rules. The duty of Scrum Master is to support the Product Owner with the backlog management and to estimate the stories with the development team (story points). It is a kind of care taker, responsible for the "spinning of scrum". The Scrum Master can be part of the development team only then, when his position doesn't make any conflicts with Scrum Master's tasks.
* The <b>Development Team</b>, the team composed of programmers, analysts, testers and architects. The duty of development team is to accomplish the assigned stories in the sprint. People of the development team can take the following positions:
</div>
<br><b>the Programmer</b> - the source code implementation,<br>
<b>the Tester</b> - testing generated code,<br>
<b>the Analyst</b> - the business requirements analysis, the stories' creation,<br>
<b>the Architect</b> - assistance with choice of technology, solution design, solving the efficiency problems.
<br>
<br><div class="text-justify">
When we have the entire team we have to specify the work timetable. The entire project process is split into sprints. <b>The Sprint</b> is the short time cycle which has to deliver a new version of product. These cycles can last from one to four weeks. I work in the two-week sprints and in my opinion, it is good compromise between a week and month. ;) The timetable is helpful for the product owner in particular. When something goes wrong, the product owner knows that he wasted two weeks instead of five months. Beside, it lets to react very fast if any problem will occur. For example, a new programmer can join the development team if there are some problem with tasks accomplishment.
</div>
<br>
<div class="text-justify">
At the beginning of sprint the whole team meets and plans the range of tasks to pursue. The speciffied tasks create the <b>Sprint Backlog</b>. The meeting when team plans their future work is called <b>Sprint Planning</b>. The Scrum Master determines the time of daily meetings called Daily SCRUM. Usually, these meetings shouldn't last longer than 15 minutes. During these meetings the members of development team tell what they did during the previous day and what plans do they have for the current day. During the "Daily" the Product Owner may participate but it isn't necessary. When the sprint ends the summing up meeting occurs (<b>Sprint Review</b>). During this meeting the whole team tells what is accomplished and what business thinks about it if it''s invited. The Sprint Review is followed by the <b>Sprint Planning</b> and so it spins as in the scrum. The good practice is to do another meeting called <b>Sprint Retrospective</b> where the team can determine what went wrong and what to do to avoid similar situations. The clue of this meeting is to write positive and negative events occured during the sprint. Next, the team disputes what to do to eliminate the problems and improve the future sprints.
</div>
<br>
<div class="text-justify">
Personally, I am both - the programmer and the Scrum Master. In my job I experienced that many small companies are unabled to pursue the project in this way. Unfortunately, it is worth to change the approach and try tu use this methodology. There are often arguments that the software production process was too long about few months and was developped by the incompetent team. Sometimes, the product were released and was working without any further problems. There were much worse situations when the application was badly built at the very beginning. It led to situations when any change seemed to be very simple required to reconstruct whole modules or complete redesign the database. Costs of doing such changes and trying to make application workable will be much grater than costs of using <b>SCRUM METHODOLOGY</b>.
</div>
<br>
Below is a graphic presentation of the SCRUM operation, the graphics are taken from https://commons.wikimedia.org/wiki/

![Scrum_diagram_(labelled).png](https://res.cloudinary.com/hpiynhbhq/image/upload/v1519586655/b4yupkrkh72uqtf8ogo6.png)


<br>
*Writing this article I was trying to make a topic clear in order to to be understood by the people who aren't in the IT brand.*
<br>Regards @mastek