SCRUM ADJUSTMENT IN THE ORGANIZATION

What are the differences between the traditional approach to project organization and Scrum? By the term “traditional”, I mean the methodology of the so-called Waterfall, that is, where the project is carefully planned at the beginning and documented in the most important details. It is only after this phase that the implementation starts. Verification follows the implementation of the entire product, and changes are implemented through further mini-projects.

The most important difference between this approach and Scrum is the relationship with the client. The basic approach is focused on the contracting relationship – the contractor in which the value is the product for the contracting party and the remuneration for the contractor. Scrum not only does not divide the project and the goal into two sides, but rather indicates the client as a team partner. Cooperation is taking place here in order to obtain the best final results. On the other hand, it allows you to refine the product, also by identifying those customer needs that he was not aware of. In practice, it can be seen that projects carried out in Scrum last shorter and with much greater satisfaction for the client than realized in the traditional way. This is due to the fact that having a common goal, the team does not waste time and energy on the proverbial “fight” with the client and uses its technical potential.

It should be mentioned that a lot depends on the team itself. Scrum carried out in the wrong way will only make the situation worse, instead of improving it.

I think that the most valuable in the scrum are: short iterations (so-called sprints), after which corrections can be made. We do not waste time if we notice that something does not work until the end of the entire project, but through short iterations we can often improve something or throw it away if we consider it unnecessary.

• We plan our work for the next iteration: for example, a week,
• After the sprint is finished, we check the results: if we have not obtained the desired satisfaction, we determine what we change during the next iteration,
• The effect of each sprint is a small, but functional part of the product that can be tested on a potential customer and apply corrections or discard what is unnecessary,
• After the sprint has finished, a retrospective with the team follows: what can we do better in the next sprint?

One of the main assumptions of Scrum is its adaptation to the needs of the organization and the team. Each activity differs from the others, just like the projects that are being implemented. The assumption that you can conduct a variety of jobs is also very risky and usually does not work. Therefore, Scrum does not impose any element, but only offers a set of practices and tools that are helpful. At the same time, however, they are independent of each other.

It often happens that the organization successfully implements only part of the processes, observing the improvement of efficiency, while maintaining other activities or tools, adapted to their business profile. Unfortunately, sometimes designers, out of pure ignorance or laziness, do not pay enough attention to the correct implementation of Scrum or adapting its elements. This results in various anti-monitors, which we will discuss in the next article.

In summary, the issue of choosing the method of project implementation should ultimately be taken in the organization. It is not a mistake not to use Scrum, but the wrong approach is certainly not taking it into account when planning a new project. Scrum is a methodology, a philosophy of project implementation by changing the way of thinking about the relationship between the recipient of the product and the team. Certainly it is not a solution for everyone, it is not a remedy for all project problems, but it is worth considering an alternative and a powerful tool for each team. If your team works in Scrum, think about whether you really use all of its instruments, if you do not have to think about what to do to change it.

– Mateusz Piekarz, Analyst