One of the most popular management methodologies in the agile industry is called Scrum. It was developed in the mid 1990s and has its roots in production process of Toyota. As a result of mapping these principles to software development, a framework for managing iterative- incremental projects was created.
Important piece of information worthy to be kept in mind is that Scrum is not a process tailored to one's organization but rather a set of proven practices. One can apply and execute these in one's business. The whole Scrum strategy, including rules, roles, work product and vocabulary, is not changed in any way to fit a business but quite the opposite.

A given organization is changed according to the Scrum methodology. However, there are some difficulties and challenges in doing so. Those challenges will be presented below.

Scrum Challenges

The first challenging feature is the shift from the traditional project management to the Scrum methodology. That mind shift is required from all the members of a team. It is highly probable that having spent many years in management environments that handled with project in a traditional way, some workers will be having problems with adapting to a team- empowered environment. High level of motivation is needed to signing up for work and reporting daily about accomplishments. It has not been promoted in a traditional project environment. While reporting about accomplishments it needs to be kept in mind that only eight hours of work lie between two meetings. Not much work can be possible done on such a short notice. Thus, the Scrum meetings are concerned with reporting relatively small accomplishments and small goals.

Another kind of challenge is connected with the daily Scrum meetings and with all the impediments that are to be reported. It might, and probably will, be the case that the project team will encounter organizational obstacles that prevent them from doing their job. Then, it is the role of the Scrum master to remove the obstacles. In a traditional project management environments these obstacles could be hidden for a long time, whereas in the Scrum projects they become visible immediately.

Next challenge usually rises in the moment of staffing the role of the product owner. In traditional project environments business analysts are not really responsible for the outcome of the project. What they do is simply preparing the requirements for the development team.
Whereas in Scrum projects the situation is different. Business analysts take part in the project on an ongoing basis and they are responsible for the correct interpreting as well as implementing of the requirements. Thanks to that, Scrum maps the role of a product owner in a better way.

The last significant difference is that Scrum is empirical. The team not only adapts the project scope to new situation but also they adapt the process itself. For example, every team is allowed to change the time of a meeting, however they are not allowed to skip a meeting whatsoever.