SCRUM methodology or agile project management - from the kitchen

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?

The SCRUM 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:

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 Product Owner, 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 Scrum Master, 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 Development Team, 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:

When we have the entire team we have to specify the work timetable. The entire project process is split into sprints. The Sprint 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.

At the beginning of sprint the whole team meets and plans the range of tasks to pursue. The speciffied tasks create the Sprint Backlog. The meeting when team plans their future work is called Sprint Planning. 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 (Sprint Review). 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 Sprint Planning and so it spins as in the scrum. The good practice is to do another meeting called Sprint Retrospective 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.

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 SCRUM METHODOLOGY.