What Is Scrum Methodology?

In 2015 I would like to continue my analysis on project management. Previously, I touched upon the question of comparison of software development methodologies. Today, we briefly examine Scrum methodology, and have a look at typical mistakes that can lead to problems. This post does not claim to be exhaustive, it is a survey and is addressed to those, who are partially acquainted with it (for example, work in the modified Scrum) or not familiar with the methodology.

Currently, Scrum is one of the most popular software development methodologies. According to the definition, Scrum – is an Agile framework with a help of which people can solve emerging problems, as well as create high-quality products with high efficiency (from the point of customers’ view).

Of course it’s impossible to solve all of the issues with the framework's help in each situation. Framework is about to estimate the time for sprints which are about dividing project periods into sprints.

When SCRUM methodology is mentioned, Agile software development with the specific rules and practices of Scrum process is always in our mind.

Scrum authors defined the following features:

• Easy (or lightweight)
• Clear, accessible
• Complicated to learn (almost mutually exclusive paragraphs)

Scrum lifecycle. Image Source: www.software-development-resource.com

Roles in Scrum

Scrum requires 3 roles:

• Product Owner (responsible for product and its priorities)
• Team (responsible for product implementation)
• Scrum Master (guide Scrum process and remove any obstacles during his work)

Product Owner is a link between the development team and the customer. Product owner's task is to maximize value of developed product and team work.

One of the main Product owner's tools is product backlog. Product backlog contains required tasks (such as Story, Bug, Task, and etc.), filtered in order of priority (urgency).

Scrum Master is a "servant leader". The main task for him is to maximize its efficiency, remove the obstacles, assist and motivate team and Product Owner.

Development Team (DT), which consists of experts, who are working on project/product. According to the Scrum Guide (the official description of Scrum), the development team must have the following qualities and characteristics:

• Be self-organized. No one (even Scrum Master and Product Owner) can assign who is able to convert Product Backlog into a working product.
• Be multifunctional and have all necessary skills to use product release.
• The whole team is responsible for active job, not an individual team member.

Recommended team size is 7 members (plus-minus 2). According to the Scrum ideologist, large teams require too many resources on communication, while smaller teams can increase the risks (due to a possible lack of required skills) and reduce the amount of work the team can perform per unit of time.

Scrum process

Sprint is the basis of Scrum, during the period of work on product. At the end of Sprint a new working product version should be produced. Sprint is always time-limited (1-4 weeks), and has the same duration during product life.

It is necessary to run Sprint Planning before every Sprint, to estimate the content and to form Sprint Backlog. This backlog contains different items (i.e. Story, Bugs, Tasks) to be executed in the current sprint. Each sprint should have a goal, which is a motivating factor and it’s achieved by performing tasks from the Sprint Backlog.

Each day you should run Daily Scrum, where each team member answers the question: "What did I do yesterday?", "What do I plan to do today?", "What obstacles have I met?".

The main meaning of Daily Scrum is a status report and work progress during Sprint, early detection of encountered obstacles, developing solutions to change the strategy in achieving the goals of Sprint.

You need to carry out Review and Retrospective at the end of the Sprint to evaluate the effectiveness (performance) of team in the past Sprint, to predict the expected performance (productivity) in the next sprint, identify the existing problems, and predict the completion of all necessary work on the product and etc.

Schematic representation of the Scrum process is shown in the following picture:

Image Source: www.agileforall.com

Important often overlooked features

You can often hear that Scrum is not working, or working less than expected. It should be noted that it more often occurs because of the following reasons:

Scrum is used incorrectly or incomplete

According to the Scrum authors, empirical experience is the main source of reliable information. Full and accurate Scrum compliance is listed in The Scrum Guide and is associated with non-typical process organization, lack of formal leader and head.

Underestimated importance of work on team motivation

One of the basic principles of Scrum is self-organization and multifunctional team. According to the research by sociologists, the number of self-motivated employees who are capable of self-organization doesn’t exceed 15% of working age population.

Thus, only a small number of employees are able to work effectively in Scrum without significant roles changes of Scrum Master and Product Owner. This contradicts to Scrum ideology and potentially leads to incorrect or incomplete methodology use.

Scrum is used for product, which requirements contradict to the Scrum ideology

Scrum is related to Agile family, so it welcomes changes in requirements at any time (Product backlog can be changed at any time). That’s why it’s difficult to use Scrum in fixed-price projects. According to Scrum ideology it’s not possible to foresee all changes. There is no sense to plan the entire project in advance, using only just-in-time planning. You need to plan the work for the current Sprint.

Do not limit yourself to one tool!

Select and combine tools as you wish! For example, I can hardly imagine a successful Scrum team, which is not using the majority of XP practices. Many team members prefer to use daily short meetings, but it’s a Scrum-practice. Some Scrum teams describe backlog problems in the way of Use Case scenarios (RUP practice), or limit the size of tasks queue (Kanban practice). Anything as long as it works!

That is beautifully said by Miyamoto Musashi (legendary samurai of the 17th century with famous technique of fencing with two swords):

‘You should not have any special fondness for a particular weapon, or anything else, for that matter. Too much is the same as not enough. Without imitating anyone else, you should have as much weaponry as suits you.’

Pay close attention to each instruments limitations. For example, if you use Scrum and decided to refuse the use of time-limited iterations (or any other major Scrum practice), then do not say that you are using Scrum. Scrum itself is already quite minimized and if you remove something and still continue to call it Scrum, this word will be meaningless and confusing. Call it as "based on Scrum" or "Scrum subset" and etc.

Belitsoft is a custom software development company (offshore software development). We provide custom application development services (PHP Development Services, NET Development Services, Java Development Services, Nodejs Development Services etc.)