Scrum - Agile project delivery approach

Latest revision as of 19:19, 20 March 2022

Developed by Mateusz Onyszkiewicz

The article provides useful guidelines and information helpful to better understand the implementation of Scrum methodology – one of the most popular Agile product development and project delivery approach. Scrum is a framework that may be applicable to projects, programs, or portfolios of different complexity and size. It is worth noting that it can be used to create a service, product, or another purpose in any industry. These can be small projects on which several people work or large, complex projects. ^[1]

[edit] Introduction

Figure 1: Scrum Principles Own study based on ^[1]

A Scrum project requires joint involvement in creating a new service, product, or different result. Projects are affected by several major constraints such as time, cost, quality, resources, scope, and organizational capabilities. In addition, there are also other limitations that interfere with proper execution, planning, and management which has an impact on the final success of the project. Agile has several methods, however, Scrum is one of the most popular. The main features of this framework are iteration, adaptation, flexibility, and efficiency with the main focus on the rapid delivery of value throughout the project. Scrum provides clear communication and makes an environment of collective responsibility and continuous improvement. ^[1] In order for Scrum projects to be successful, its principles must be strictly followed. The six Scrum principles are as follows:

• Empirical Process Control - Inspection, transparency, and adaptation are the three main ideas on which Scrum is based.
• Self-organization - Today's employees deliver much better value when they are self-organized, which in turn results in better team involvement and co-ownership.
• Collaboration - Articulation, awareness, and assimilation are the three fundamental dimensions of collaborative work and this principle focuses on them. The idea is to see project management as a collaborative process of creating value. Teams should work together and interact to deliver the best value.
• Value-based Prioritization - This principle focuses on delivering the highest possible business value from the very beginning of the project and throughout its entire cycle
• Time-boxing - Time is the crucial constraint in Scrum. Properly managed, it will help to plan and execute projects successfully. Sprints, Sprint Planning Meetings, Daily Standup Meetings, and Sprint Review Meetings are Time-boxed elements in Scrum.
• Iterative Development - Customer satisfaction is one of the most important factors in a successful project. Iterative development is helpful in building projects and managing changes to meet the needs of customers. It also identifies the organization's and the Product Owner's responsibility in regards to iterative development. ^[1]

[edit] History

The story of Scrum began with an article published in 1986 by Hirotaka Takeuchi and Ikujiro Nonaka. The article is titled "The New New Product Development Game" and describes how companies such as Canon, Honda, and Fuji-Xerox have delivered the highest quality results using a team-based and scalable approach to all-inclusive product development strategy. The article highlights the importance of an independent, organized team and outlines the role of management in the development process. This work had a great impact on combining concepts into one whole, which initiated the present-day Scrum. ^[2]

To describe product development Nonaka and Takeuchi used the trope of rugby and Scrum: "The traditional sequential or “relay race” approach to product development ... may conflict with the goals of maximum speed and flexibility. Instead, a holistic or “rugby” approach—where a team tries to go the distance as a unit, passing the ball back and forth—may better serve today’s competitive requirements." ^[3]

The Scrum process for use in software development was created by Jeff Sutherland and his team in 1993 by combining the principles and concepts from the above-mentioned article with the empirical process control, iterative, object-oriented development, and incremental concepts. ^[2]

[edit] The difference between Scrum and Traditional Project Management

Nowadays organizations need to be flexible to meet the customer's demands and be competitive in the marketplace. Agile Project Management comes in handy here, helping to meet challenges and a rapidly changing business environment. There are several key differences between an Agile and a traditional approach to project management. ^[4]

The first clear difference is that Scrum Methodology pays more attention to people than to processes as in the case of Traditional Project Management (TPM). Comprehensive documentation, which is necessary for the traditional approach to project management for Scrum, is minimized only to the required. The linear process style is replaced by iterative. Traditional Project Management focuses on high-level upfront planning, on the other hand, upfront planning in Scrum is low. When it comes to Prioritization of Requirements it is not fixed in the project plan as for TPM, however, based on business value and is regularly updated. Quality assurance for Scrum is customer-oriented, while for TPM it is process-oriented. In terms of organization, Scrum is self-organized with a decentralized management style and Traditional Project Management is managed with a centralized management style. Another difference is the approach to change where the Formal Change Management System has been replaced with Updates to Productized Product Backlog (Product Backlog is basically an ordered list of business as well as project requirements represented by User Stories). Leadership for Scrum is about collaboration, servant leadership while for TPM it is command and control. Performance measurements are done using business value not plan conformity as for TPM. Last but not least, return on investment for Scrum is early, throughout the project life. Customer involvement is also high from the beginning to the end of the project. On the other hand for Traditional Project Management return on investment is the end of project life and customer involvement varies depending on the project lifecycle.^[1]

[edit] Why use Scrum?

Using Scrum has several key benefits in projects. Some of them are presented below:

• Adaptability - Projects are open to change and adaptable thanks to iterative delivery and empirical process control.
• Continuous Feedback - Conducting Daily Standup and Demonstrating and Validating Sprint processes ensure continuous feedback.
• Transparency - Tools for exchanging information and controlling progress such as Sprint Burndown Chart and Scrumboard are shared, which creates an open work environment and has an impact on productivity.
• Continuous Improvement - With each successive Sprint, the results delivered are improved.
• Sustainable Pace - People are able to work at a sustainable pace thanks to the way in which Scrum processes are designed.
• Early Delivery of High Value - The Create Prioritized Product Backlog process is responsible for ensuring customer critical requirements first.
• Continuous Delivery of Value - According to the customer's request, further values ​​are delivered through the Ship Deliverables thanks to iterative processes.
• Efficient Development Process - The high level of efficiency is ensured by time constraints and minimizing activities that do not add value.
• Faster Problem Resolution - Cross-functional teams work together to provide faster problem resolution.
• Motivation - Retrospect Sprint processes and The Conducting Daily Standup have an impact on the increased motivation of employees.
• Effective Deliverables - Satisfying deliverables for the customer are ensured by regular reviews and The Priority Product Backlog creation.
• Customer-Centric - A customer-oriented framework is ensured by an appropriate stakeholder approach and focus on business value.
• Collective Ownership - Team members are able to take the project's ownership thanks to The Commit User Stories which ultimately results in better quality.
• High Trust Environment - Team members have a high trust work environment based on transparency and collaboration which are promoted by Retrospect Sprint and Conducting Daily Standup.
• Innovative Environment - Nowadays creative work and an innovative environment are crucial. Such conditions are created thanks to The Retrospect Project and Retrospect Sprint processes.
• High Velocity - High velocity and the full potential of cross-functional teams might be achieved by a collaborative framework.^[1]

[edit] Scrum Roles

Figure 2: Benefits of Collaboration in Scrum Projects Own study based on ^[1]

Scrum has several important roles. Core roles include Product Owner, Scrum Master, Scrum Team. Profitable implementation of Scrum projects requires understanding defined responsibilities and roles. There are also non-core roles such as, among others, Stakeholder (s), Vendors, Users, and Sponsors. Non-core roles are not necessarily required for a Scrum project and may not be constantly involved in the process. Nevertheless, it is important to know as much as possible about them as they can be an essential part of Scrum projects.

[edit] Product Owner

The Product Owner's task is to maximize the value of the product that is created through the work of the Scrum Team. The way it is done depends on the organization, individuality, or Scrum Team. Effective Product Backlog management is one of the Product Owner's accountability and includes:

• Development and clear communication of the Product Goal.
• Ordering Product Backlog items.
• Creation and clear communication of Product Backlog items.
• Assurance of the transparency, comprehensibility, and visibility of the Product Backlog.

The Product Owner may commission the work to other people or do it on his own, however, it is the Product Owner's accountability to make sure that work is done properly. Product Owners need the respect of the entire organization in terms of their decisions to be successful. The important point is that the Product Owner is one person which represents many stakeholders' needs in the Product Backlog. If someone wants to change the Product Backlog it is possible only by convincing the Product Owner. ^[5]

[edit] Scrum Master

The role of the Scrum Master is to follow the rules as defined in the Scrum guide. They help others in the organization and Scrum Team to better understand Scrum theory and practice. One of the most important tasks of the Scrum Master is to ensure the effectiveness of the Scrum Team. It is possible by improving Scrum Team practices within the Scrum framework. The Scrum Master should be a true leader who works for the benefit of both the Scrum Team and the larger organization. Below are presented the most important ways in which Scrum Master serves the Scrum Team:

• As cross-functionality and self-management are key factors in Scrum, the role of the Scrum Master is to coach team members in this area.
• The Scrum Team receives Scrum Master's support to better focus on developing high-value increments that fulfill the Definition of Done.
• The Scrum Master takes care that obstacles to the progress of the Scrum Team are removed.
• The Scrum Master ensures that all Scrum events are productive, in a positive atmosphere, and take place within the Time-box.

Below are presented the most important ways in which Scrum Master serves the Product Owner:

• The Scrum Master helps with finding appropriate techniques for efficient Product Backlog management and Product Goal definition.
• The Scrum Master makes Scrum Team aware of the necessity of clear concise Product Backlog items.
• The Scrum Master helps with setting up empirical product planning for different environments.
• The Scrum Master facilitates the needed and desired stakeholder collaboration.

Finally, the most important ways in which the Scrum Master serves the organization are presented:

• The Scrum Master Conducts, trains, and coaches organizations in the implementation of Scrum.
• The Scrum Master advises on the adaptation of Scrum in the organization.
• The Scrum Master helps both stakeholders and employees understand an empirical approach to work.
• The Scrum Master is accountable for clear contact between Scrum Teams and stakeholders.^[5]

[edit] Scrum Team

The Scrum Team is also called the Development Team because it is responsible for service, development of a product, or another result. In the Scrum Team, a group of people work on the User Stories in the Sprint Backlog and their goal is to create the Deliverables for the project purposes. The Scrum Team responsibilities are, among others, providing inputs for the Team Building Plan and the Collaboration Plan, Understanding the User Stories in the Prioritized Product Backlog, Discussing with other Scrum Core Team the Sprint Length, Committing User Stories to be done in a Sprint, Estimating workload for tasks identified and when it is needed, updating the Task List, Creating Deliverables, Identifying improvement opportunities, Participating in Prioritized Product Backlog Review Meetings and Retrospect Project Meetings. A Scrum Team should have all the necessary skills to conduct project work. Moreover, good cooperation is important so that the performance is at a high level. Typically, the most optimal size for a Scrum Team is from six to ten members.^[1]

[edit] Scrum Events

The main goal of Scrum Events is to achieve the required transparency. Artifacts can be inspected and adapted in each event. Inadequate handling of events results in the loss of the possibility of adaptation and inspection. To reduce complexity, events should be held at the same place and at the same time. The Product Backlog can be refined if necessary. ^[5]

[edit] The Sprint

Figure 3: Scrum Flow for One Sprint Own study based on ^[1]

Sprints are a key event in Scrum. It is during them that added value is created in the projects. These events are of equal length and should not last more than one month for consistency reasons. At the end of the previous Sprint, the next Sprint starts immediately. Daily Scrums, Product Goal, Sprint Planning, Sprint Review, and Sprint Retrospective are achieved through the work done during the Sprint. It is worth noting that during the Sprint no changes that could negatively affect the Sprint Goal should be taken and the quality does not decrease. When there is more information about the project, its scope may be renegotiated and clarified with the Product Owner. By adapting and inspecting the progress of a Product Goal at least once a month, Sprints facilitate predictability. Sprint horizons that are too long can affect the quality of the Sprint Goal, resulting in increased risk and complexity. To reduce the risk of workload and costs, shorter Sprints can be used, moreover, more learning cycles will be generated. Each Sprint is actually a smaller project. There are many practices to forecast progress, among others, burn-ups, burn-downs, and cumulative flows. However, in complex projects, there is a high probability that something unknown will happen. Nevertheless, it is worth remembering that what has happened so far can be used in making subsequent decisions. The Product Owner is the only person who has the authority to cancel the Sprint. It may happen, for example, when Sprint Goal became obsolete.^[5]

[edit] Sprint Planning

Sprint Planning initiates the Sprint by planning the work to be done during the Sprint. The plan is the result of the work of the entire Scrum Team. The following questions should be raised during Sprint Planning:

• Why is this Sprint valuable? - The Product Owner's role is to propose a way to increase the value of the current Sprint. In the next step, the entire Scrum Team works together to define a Sprint Goal that will be valuable to stakeholders. Before Sprint Planning is completed, it is essential to establish the Sprint Goal.
• What can be done this Sprint? - After in-depth discussions with the Product Owner, the Scrum Team selects items from the Product Backlog to be included in the Sprint,
• How will the chosen work get done? - Product Backlog items are selected by the Scrum Team, which then plans out the work that needs to be done to meet the Definition of Done. This can be done by splitting the Product Backlog items into smaller tasks.

Sprint planning should not exceed eight hours for a one-month Sprint. However, for shorter Sprints, it usually takes less time.^[5]

[edit] Daily Scrum

Daily Scrum is a short meeting of the project team, the purpose of which is to update the news and progress from the last days of work. It also includes a section in which everyone declares what they intend to work on, on a given day and highlights what obstacles they have experienced or expect to experience.^[6]

[edit] Sprint Review

The Sprint Review is performed to check the Sprint result and determine the next adaptations. The work of the Scrum Team is presented to stakeholders and progress is discussed. Stakeholders and The Scrum Team at this event are reviewing what has been achieved during the Sprint and if there have been any changes. Using the collected information, event participants discuss the next steps. The Product Backlog should be adapted to the new situation. The Sprint Review should not take more than four hours. If the Sprint is shorter, this event usually takes less time.^[5]

[edit] Sprint Retrospective

The aim of the Sprint Retrospective is to identify ways to improve efficiency and quality. The Scrum Team investigate the last Sprint in terms of interactions, individuals, tools, processes, and Definition of Done. If something went wrong, the origin of the problem is checked. The Scrum Team looks at the pros and cons of the last Sprint and discusses them. Then The Scrum Team indicates changes that improve efficiency. The best of them are rolled out as quickly as possible, and sometimes even added to the Sprint Backlog for the next Sprint. The Sprint Retrospective is the closing event of Sprint. It shouldn't take more than three hours on the Sprint once a month. If the Sprint is shorter, this event usually takes less time.^[5]

[edit] Conclusion

There is no doubt that Scrum is a useful approach to project management. It has some major advantages, among others flexibility, which makes the methodology adjustable even in environments with high uncertainty. It is also based on creativity and innovation, which are invaluable in today's market. Other strong points of this methodology are high quality and customer satisfaction. Of course, it also has its disadvantages and limitations such as requirements for adequate training and skills, organizational transformation if needed, and sometimes Scrum approach may not be the best choice for projects that require a plan-driven approach.

[edit] Annotated Bibliography

[1] SCRUMstudy™, a brand of VMEdu, A Guide to the SCRUM BODY OF KNOWLEDGE (SBOK™ GUIDE) Third Edition (2017)

[2] Ken Schwaber and Jeff Sutherland, The Scrum Guide™, The Definitive Guide to Scrum: The Rules of the Game, November 2020

[3] Agile!: The Good, the Hype and the Ugly 2014th Edition by Bertrand Meyer

[edit] References

1. ↑ ^{1.0 1.1 1.2 1.3 1.4 1.5 1.6 1.7 1.8} SCRUMstudy™, a brand of VMEdu, A Guide to the SCRUM BODY OF KNOWLEDGE (SBOK™ GUIDE) Third Edition (2017)
2. ↑ ^{2.0 2.1} Kenneth S. Rubin, Essential Scrum: A Practical Guide to the Most Popular Agile Process, July 2012
3. ↑ Hirotaka Takeuchi and Ikujiro Nonaka, The New New Product Development Game, January 1986
4. ↑ Danijela Ciric, Bojan Lalic, Danijela Gracanin, Nemanja Tasic, Agile vs. Traditional Approach in Project Management: Strategies, Challenges, and Reasons to Introduce Agile, January 2019
5. ↑ ^{5.0 5.1 5.2 5.3 5.4 5.5 5.6} Ken Schwaber and Jeff Sutherland, The Scrum Guide™, The Definitive Guide to Scrum: The Rules of the Game, November 2020
6. ↑ A guide to the Project Management Body of Knowledge (PMBOK guide), 7th Edition (2021)