To Scrum Or Not to Scrum? Pros and Cons To Consider

Scrum is a widely accepted Agile methodology for management and control of software projects; it is optimized to create product iterations on a regular basis. Scrum prospers by the well-defined user stories that can be accomplished and delivered separately, and it also leaves the decision to the team – how much to work during a sprint. Scrum applies common sense artifacts, such as the practice of daily stand-up meetings during which the team members will report on what they’ve done since the last stand-up.

Advantages

There are many pros of the Scrum method. In brief, it works well and it is efficient.  

Many successfully accomplished projects prove that this agile approach is superior over the classical waterfall methodology. Even the project team members can witness that there are very rare cases when Scrum or other agile methodology have failed.

• Easy to comprehend: The most important advantage is that Scrum is easy to comprehend. The point is to get the work accomplished via continuous collaboration with the client/product owner. The role of the product owner is to keep the big picture ahead and to be able to prioritize items. These factors can bring him successes.
• Divide and conquer approach: Divide and conquer approach of Scrum is not new, but, it defines iterations of 4 weeks or shorter sprints, thus reducing the possible risks.
• Sprint retrospective: There are several Scrum events, but the Sprint retrospective is one of the most important from the team’s and framework improvement perspective. The retrospective is a proper artifact to reflect back and recheck both the team and the framework itself.

Drawbacks

Scum has also some drawbacks, and the most obvious one is that Scrum is a strictly defined method and the team members should rigorously follow its principles, events, and deliverables.

• Additional customization: The method itself should be more improved and customized in certain projects because our environment is constantly changing. Software development process, by its nature, is agile and there is a large number of dynamic components. 
• Strictness: The strictness of the method is one of the key drawbacks. You are not allowed to hold more than one Sprint Review meeting in a sprint. The team size is limited from three up to nine members, for it to be called Scrum, and so on. The Scrum method defines the roles, responsibilities, events and artifacts.
• Limitations: The limitation for the daily scrum meetings should be 15 minutes, and the sprint planning meeting has to be 8 hours maximum.  All events in the Scrum have their purpose, but the duration and occurrence of the event are better left for the team to decide and utilize to fulfill the project requirements.

The conclusion is that you should always respect the hierarchy in the teams. The success of Scrum relies on finding a harmony between the different demands of Scrum’s cross-functional and self-organizing team rules and the established hierarchy and roles of the team members. Teams should not be kept isolated from the environment.

Bothering issues

The simplicity is both an advantage and drawback of the Scrum method. In this section, we’ll elaborate some unseemly aspects of Scrum.

• Focus on the framework and speed: Scrum only defines the methodology, but not the team members that are following it. The focus is on speed and getting things done, and it does not talk about human resource management. The agile approach also asks for individuals and interactions. There should be more attention paid to people than just attending sprint planning, daily scrums, doing their work, sprint reviews, and sprint retrospectives.
• Backlog: The product backlog is not necessarily a bad artifact; in some cases, when the team is experienced, it is mostly glared upon. If some items do not fit into a sprint, they are usually put into a backlog, in some cases, never to be looked at again. A good backlog is a sign of a living healthy product. Even the prioritization and clarification of the items in the backlog is sometimes a challenge.
• Residual work: The large portion of the sprint work does not end with the sprint. There are several reasons for that. E.g. there may be a planned backlog item that was finished on the last day of the sprint, but can not be tested within the same sprint. In many software development projects, the outcome goes through a process of revision. Not all items go into production after the end of the sprint. So the problem is how to foresee the leftover work that is needed for revision and configuration management related activities. Scrum methodology is very simple, but it does not talk about how to consider many of the real life development issues.