Flexible Scrum development methodology
I continue to work on a thesis on project management. Today we will briefly look at Scrum, look at common mistakes that lead to problems. This post does not claim to be complete, it is a review and is addressed to those who are not yet familiar with Scrum, or only partially familiar (for example, it works in a modified Scrum).
Currently, Scrum is one of the most popular software development methodologies. According to the definition, Scrum is a development framework with which people can solve emerging problems, while productively and producing products of the highest importance (from the point of view of the client - author's note) [1].
This suggests that in Scrum it is impossible to find answers to all the questions and instructions for action in all situations (for example, the official description of Scrum only indicates the need to estimate the time required to complete the work, but does not specify the type of assessment. That is, this may be planning poker and another way to evaluate it). Thus, the very name of the topic is not true :)
')
When they talk about the Scrum methodology, they most often mean a flexible software development methodology built on the basis of Scrum rules and practices, so it may well be that your Scrum is cooler than my Scrum, and also be as far from it as a VAZ 7 from BMW 7th series :)
The authors of Scrum declared the following features:
-Easy (lightweight)
-Comprehensible, affordable
- Difficult to learn
(almost mutually exclusive paragraphs)
Scrum Roles
In the classic Scrum, there are 3 basic roles:
- Product owner
- Scrum master
- Development team
The product owner (PO) is the link between the development team and the customer. The objective of the PO is to maximize the value of the product being developed and the work of the team.
One of the main PO tools is the Product Backlog. Product Backlog contains the necessary work tasks (such as Story, Bug, Task, etc.), sorted in order of priority (urgency).
Scrum master (SM) is the “servant leader”. The goal of Scrum Master is to help the team maximize its effectiveness by eliminating obstacles, helping, teaching and motivating the team, helping PO
The development team (Development team, DT) consists of specialists who perform direct work on the product being produced. According to The Scrum Guide (a document that is the official description of Scrum from its authors), DT should have the following qualities and characteristics:
-Be self-organizing. No one (including SM and PO) can tell the team how to convert the Product Backlog into a working product.
-Be multi-functional, have all the necessary skills for the release of a working product
- The whole team is responsible for the work done, not the individual team members.
The recommended team size is 7 (plus or minus 2) people. According to Scrum ideologues, larger teams require too much resources for communication, while smaller teams increase risks (due to the possible lack of required skills) and reduce the amount of work that a team can perform per unit of time. [one]
Scrum process
The basis of Scrum is Sprint, during which work on the product is performed. At the end of Sprint, a new working version of the product should be obtained. Sprint is always limited in time (1-4 weeks) and has the same duration throughout the life of the product.
Before the start of each Sprint, Sprint Planning is performed, which evaluates the contents of the Product Backlog and forms the Sprint Backlog, which contains tasks (Story, Bugs, Tasks) to be performed in the current sprint. Each sprint should have a goal that is a motivating factor and is achieved by performing tasks from the Sprint Backlog.
Daily Scrum is produced every day, in which each team member answers the questions “what did I do yesterday?”, “What do I plan to do today?”, “What obstacles in my work have I met?”. The task of Daily Scrum is to determine the status and progress of work on Sprint, the early detection of obstacles that have arisen, and the development of solutions for changing the strategy necessary to achieve the goals of Sprint.
At the end of Sprint, Sprint Review and Sprint Retrospective are made, the task of which is to evaluate the effectiveness (performance) of the team in the last Sprint, predict the expected effectiveness (performance) in the next sprint, identify existing problems, estimate the likelihood of completion of all necessary work on the product and other .
A schematic representation of the process is shown in the following figure:
Important, often forgotten features
You can often hear that Scrum is not working, or is working worse than expected. It should be noted that most often this happens for one of the following reasons:
1. Scrum is used incorrectly or incompletely.
According to the authors Scrum, empirical experience is the main source of reliable information. The need for full and accurate implementation of Scrum is indicated in The Scrum Guide and is due to the atypical organization of the process, the lack of a formal leader and leader.
2. The importance of the work on motivation of the team is underestimated.
One of the main principles of Scrum are self-organizing, multi-functional teams. According to research by sociologists, the number of self-motivated employees capable of self-organization does not exceed 15% of the working-age population [2].
Thus, only a small part of employees is able to work effectively in Scrum without significant changes in the roles of the Scrum master and Product Owner, which contradicts the Scrum ideology, and potentially leads to incorrect or incomplete use of Scrum.
3. Scrum is applied to a product, the requirements for which contradict the ideology of Scrum.
Scrum belongs to the Agile family, so Scrum welcomes changes in requirements at any time (Product backlog can be changed at any time). This makes it difficult to use Scrum in fixed-cost / fixed-time projects. The ideology of Scrum argues that it is impossible to foresee all changes in advance, so it makes no sense to plan the entire project beforehand, limiting itself to just-in-time planning, i.e., only plan the work that needs to be done in the current Sprint. [3] There are other restrictions.
Advantages and disadvantages
Scrum has quite attractive advantages. Scrum is customer oriented, adaptive. Scrum gives the customer the opportunity to make changes to the requirements at any time (but does not guarantee that these changes will be implemented). The ability to change requirements is attractive to many software customers.
Scrum is quite simple to learn, it saves time by eliminating non-critical activities. Scrum allows you to get a potentially working product at the end of each Sprint.
Scrum focuses on a self-organizing, multi-functional team that can solve the necessary tasks with minimal coordination. This is especially attractive for small companies and start-ups, as it eliminates the need for hiring or training specialized personnel managers.
Of course, Scrum has some important disadvantages. Due to its simplicity and minimalism, Scrum sets a small number of fairly rigid rules. However, this conflicts with the idea of ​​customer focus in principle, since the internal rules of the development team are not important for the client, especially if they limit the client. For example, if necessary, according to the decision of the Sprint client, the backlog can be changed, despite the apparent contradiction with the rules of Scrum.
The problem is bigger than it seems. Since Scrum belongs to the Agile family, Scrum does not accept, for example, the creation of a communication and risk response plan. [3] Thus, making it difficult or impossible to formally (legally or administratively) oppose violations of the Scrum rules.
Another weak feature of Scrum is the emphasis on a self-organizing, multi-functional team. With an apparent decrease in the cost of coordinating the team, this leads to an increase in the cost of personnel selection, motivation and training. Under certain conditions of the labor market, the formation of a full-fledged, effective Scrum team may be impossible.
List of used sources
[1] The Scrum Guide. Scrum: The Rules of the Game. (Ken Schwaber, Jeff Sutherland)
[2] Management Psychology, study guide. (A. A. Trous)
[3] How a Traditional Project Manager Transforms to Scrum: PMBOK vs. Scrum (Jeff Sutherland, Nafis Ahmad)
Thank you in advance for these errors and inaccuracies!
Currently, Scrum is one of the most popular software development methodologies. According to the definition, Scrum is a development framework with which people can solve emerging problems, while productively and producing products of the highest importance (from the point of view of the client - author's note) [1].
This suggests that in Scrum it is impossible to find answers to all the questions and instructions for action in all situations (for example, the official description of Scrum only indicates the need to estimate the time required to complete the work, but does not specify the type of assessment. That is, this may be planning poker and another way to evaluate it). Thus, the very name of the topic is not true :)
')
When they talk about the Scrum methodology, they most often mean a flexible software development methodology built on the basis of Scrum rules and practices, so it may well be that your Scrum is cooler than my Scrum, and also be as far from it as a VAZ 7 from BMW 7th series :)
The authors of Scrum declared the following features:
-Easy (lightweight)
-Comprehensible, affordable
- Difficult to learn
(almost mutually exclusive paragraphs)
Scrum Roles
In the classic Scrum, there are 3 basic roles:
- Product owner
- Scrum master
- Development team
The product owner (PO) is the link between the development team and the customer. The objective of the PO is to maximize the value of the product being developed and the work of the team.
One of the main PO tools is the Product Backlog. Product Backlog contains the necessary work tasks (such as Story, Bug, Task, etc.), sorted in order of priority (urgency).
Scrum master (SM) is the “servant leader”. The goal of Scrum Master is to help the team maximize its effectiveness by eliminating obstacles, helping, teaching and motivating the team, helping PO
The development team (Development team, DT) consists of specialists who perform direct work on the product being produced. According to The Scrum Guide (a document that is the official description of Scrum from its authors), DT should have the following qualities and characteristics:
-Be self-organizing. No one (including SM and PO) can tell the team how to convert the Product Backlog into a working product.
-Be multi-functional, have all the necessary skills for the release of a working product
- The whole team is responsible for the work done, not the individual team members.
The recommended team size is 7 (plus or minus 2) people. According to Scrum ideologues, larger teams require too much resources for communication, while smaller teams increase risks (due to the possible lack of required skills) and reduce the amount of work that a team can perform per unit of time. [one]
Scrum process
The basis of Scrum is Sprint, during which work on the product is performed. At the end of Sprint, a new working version of the product should be obtained. Sprint is always limited in time (1-4 weeks) and has the same duration throughout the life of the product.
Before the start of each Sprint, Sprint Planning is performed, which evaluates the contents of the Product Backlog and forms the Sprint Backlog, which contains tasks (Story, Bugs, Tasks) to be performed in the current sprint. Each sprint should have a goal that is a motivating factor and is achieved by performing tasks from the Sprint Backlog.
Daily Scrum is produced every day, in which each team member answers the questions “what did I do yesterday?”, “What do I plan to do today?”, “What obstacles in my work have I met?”. The task of Daily Scrum is to determine the status and progress of work on Sprint, the early detection of obstacles that have arisen, and the development of solutions for changing the strategy necessary to achieve the goals of Sprint.
At the end of Sprint, Sprint Review and Sprint Retrospective are made, the task of which is to evaluate the effectiveness (performance) of the team in the last Sprint, predict the expected effectiveness (performance) in the next sprint, identify existing problems, estimate the likelihood of completion of all necessary work on the product and other .
A schematic representation of the process is shown in the following figure:
Important, often forgotten features
You can often hear that Scrum is not working, or is working worse than expected. It should be noted that most often this happens for one of the following reasons:
1. Scrum is used incorrectly or incompletely.
According to the authors Scrum, empirical experience is the main source of reliable information. The need for full and accurate implementation of Scrum is indicated in The Scrum Guide and is due to the atypical organization of the process, the lack of a formal leader and leader.
2. The importance of the work on motivation of the team is underestimated.
One of the main principles of Scrum are self-organizing, multi-functional teams. According to research by sociologists, the number of self-motivated employees capable of self-organization does not exceed 15% of the working-age population [2].
Thus, only a small part of employees is able to work effectively in Scrum without significant changes in the roles of the Scrum master and Product Owner, which contradicts the Scrum ideology, and potentially leads to incorrect or incomplete use of Scrum.
3. Scrum is applied to a product, the requirements for which contradict the ideology of Scrum.
Scrum belongs to the Agile family, so Scrum welcomes changes in requirements at any time (Product backlog can be changed at any time). This makes it difficult to use Scrum in fixed-cost / fixed-time projects. The ideology of Scrum argues that it is impossible to foresee all changes in advance, so it makes no sense to plan the entire project beforehand, limiting itself to just-in-time planning, i.e., only plan the work that needs to be done in the current Sprint. [3] There are other restrictions.
Advantages and disadvantages
Scrum has quite attractive advantages. Scrum is customer oriented, adaptive. Scrum gives the customer the opportunity to make changes to the requirements at any time (but does not guarantee that these changes will be implemented). The ability to change requirements is attractive to many software customers.
Scrum is quite simple to learn, it saves time by eliminating non-critical activities. Scrum allows you to get a potentially working product at the end of each Sprint.
Scrum focuses on a self-organizing, multi-functional team that can solve the necessary tasks with minimal coordination. This is especially attractive for small companies and start-ups, as it eliminates the need for hiring or training specialized personnel managers.
Of course, Scrum has some important disadvantages. Due to its simplicity and minimalism, Scrum sets a small number of fairly rigid rules. However, this conflicts with the idea of ​​customer focus in principle, since the internal rules of the development team are not important for the client, especially if they limit the client. For example, if necessary, according to the decision of the Sprint client, the backlog can be changed, despite the apparent contradiction with the rules of Scrum.
The problem is bigger than it seems. Since Scrum belongs to the Agile family, Scrum does not accept, for example, the creation of a communication and risk response plan. [3] Thus, making it difficult or impossible to formally (legally or administratively) oppose violations of the Scrum rules.
Another weak feature of Scrum is the emphasis on a self-organizing, multi-functional team. With an apparent decrease in the cost of coordinating the team, this leads to an increase in the cost of personnel selection, motivation and training. Under certain conditions of the labor market, the formation of a full-fledged, effective Scrum team may be impossible.
List of used sources
[1] The Scrum Guide. Scrum: The Rules of the Game. (Ken Schwaber, Jeff Sutherland)
[2] Management Psychology, study guide. (A. A. Trous)
[3] How a Traditional Project Manager Transforms to Scrum: PMBOK vs. Scrum (Jeff Sutherland, Nafis Ahmad)
Thank you in advance for these errors and inaccuracies!
Source: https://habr.com/ru/post/247319/
All Articles