How Does Scrum Ensure Teams are Self-Organized?

An essential aspect of the Scrum framework is the Scrum Team. The Scrum Team is a group or team of people who are responsible for understanding the business requirements specified by the Product Owner, estimating User Stories, and final creation of the project Deliverables. Scrum believes that Scrum Team members are self-motivated and seek to accept greater responsibility. So, they deliver much greater value when self-organized.

Self-organization as an essential principle in Scrum leads to the following:

·         Team buy-in and shared ownership

·         Motivation, which leads to an enhanced performance level of the team

·         Innovative and creative environment conducive to growth

Self-organization does not mean that team members are allowed to act in any manner that they want to. It just means that once the Product Vision is defined in the Create Project Vision process, the Product Owner, Scrum Master, and Scrum Team get identified. Also the Scrum Core Team itself works very closely with relevant Stakeholder(s) for refining requirements better as they go through the Develop Epic(s) and Create User Stories process. Team expertise is used to assess the inputs needed to execute the planned work of the project. This judgment and expertise are applied to all technical and management aspects of the project during the Create Deliverables process.

Here is a video on self-organization in Scrum: http://www.scrumstudy.com/watch.asp?vid=447

Although prioritization is primarily done by the Product Owner who represents the Voice of Customer, the self-organized Scrum Team is involved in task breakdown and estimation during the Create Tasks and Estimate Tasks processes. During these processes, each team member is responsible for determining what work he or she will be doing. During the execution of a Sprint, if team members need any help with completing their tasks, Scrum addresses this through the regular interaction mandatory with the Daily Standup Meetings. The Scrum Team itself interacts with other teams through the Scrum of Scrums (SoS) Meetings and can look for additional guidance as required from the Scrum Guidance Body.

Finally, the Scrum Team and Scrum Master work closely to demonstrate the product increment created during the Sprint in the Demonstrate and Validate Sprint process where properly completed deliverables are accepted. Since the Deliverables are potentially shippable, (and the Prioritized Product Backlog is prioritized by User Stories in the order of value created by them), the Product Owner and the customer can clearly visualize and articulate the value being created after every Sprint; and Scrum Teams in turn have the satisfaction of seeing their hard work being accepted by the customer and other stakeholders.

How do Organization Structures in Scrum and Traditional Project Management Differ?

Organization structure and definition of roles and associated responsibilities are some of the areas where Scrum differs in a major way from traditional project management methods.

Scrum roles fall into two broad categories:

1.            Core Roles—Core roles are those roles which are mandatorily required for producing the product of the project, are committed to the project, and ultimately are responsible for the success of each Sprint of the project and of the project as a whole.

2.            Non-core Roles—Non-core roles are those roles which are not mandatorily required for the Scrum project, and may include team members who are interested in the project, have no formal role on the project team, may interface with the team, but may not be responsible for the success of the project. The non-core roles should also be taken into account in any Scrum project.

Here is a video on the differences between the organization structures of Scrum and Traditional project management and delivery methods: 

In traditional project management methods, the organization structure is hierarchical and authority for all aspects of the project is delegated from higher level to lower (e.g., project sponsor delegates authority to project manager and the project manager delegates authority to team members). Traditional project management methods emphasize on individual accountability for project responsibilities rather than group ownership or accountability. Any deviation from the delegated authority is looked at as a sign of issues and may be escalated to the higher level in the organization hierarchy. It is usually the project manager who is responsible for successful completion of the project and he or she takes decisions on various aspects of the project, including initiating, planning, estimating, executing, monitoring and controlling, and closing. The following diagram gives an overview of the Scrum roles:

The emphasis in Scrum is on self-organization and self-motivation where the team assumes greater responsibility in making a project successful. This also ensures that there is team buy-in and shared ownership. This, in turn, results in team motivation leading to an optimization of team efficiencies. The Product Owner, Scrum Master, and the Scrum Team work very closely with relevant Stakeholder(s) for refining requirements as they go through the Develop Epic(s), Create Prioritized Product Backlog, and Create User Stories processes. This ensures that there is no scope for isolated planning in Scrum. Team experience and expertise in product development are used to assess the inputs needed to plan, estimate and execute project work. Collaboration among Scrum Core Team members ensures that the project is carried out in an innovative and creative environment that is conducive to growth and team harmony.

How Does Scrum Ensure Empirical Process Control in Project Delivery?

In Scrum, decisions are made based on observation and experimentation rather than on detailed upfront planning. Empirical process control relies on the three main ideas of transparency, inspection, and adaptation.

Here is a video on empirical process control in Scrum: 

Transparency allows all facets of any Scrum process to be observed by anyone. This promotes an easy and transparent flow of information throughout the organization and creates an open work culture. In Scrum, transparency is depicted through the following:

·         Project Vision Statement which can be viewed by all stakeholders and the Scrum Team

·         An open Prioritized Product Backlog with prioritized User Stories that can be viewed by everyone, both within and outside the Scrum Team

·         A Release Planning Schedule which may be coordinated across multiple Scrum Teams

·         Clear visibility into the team’s progress through the use of a Scrumboard, Burndown Chart, and other information radiators

·         Daily Standup Meetings conducted during the Conduct Daily Standup process, in which all team members report what they have done the previous day, what they plan to do today, and any problems preventing them from completing their tasks in the current Sprint

·         Sprint Review Meetings conducted during the Demonstrate and Validate Sprint process, in which the Scrum Team demonstrates the potentially shippable Sprint Deliverables to the Product Owner and Stakeholders

The following diagram summarizes transparency in Scrum:

Inspection in Scrum is depicted through the following:

·         Use of a common Scrumboard and other information radiators which show the progress of the Scrum Team on completing the tasks in the current Sprint.

·         Collection of feedback from the customer and other stakeholders during the Develop Epic(s), Create Prioritized Product Backlog, and Conduct Release Planning processes.

·         Inspection and approval of the Deliverables by the Product Owner and the customer in the Demonstrate and Validate Sprint process.

The following diagram summarizes the concept of inspection in Scrum: 

Adaptation happens as the Scrum Core Team and Stakeholders learn through transparency and inspection and then adapt by making improvements in the work they are doing. Some examples of adaptation include:

·         In Daily Standup Meetings, Scrum Team members openly discuss impediments to completing their tasks and seek help from other team members. More experienced members in the Scrum Team also mentor those with relatively less experience in knowledge of the project or technology.

·         Risk identification is performed and iterated throughout the project. Identified risks become inputs to several Scrum processes including Create Prioritized Product Backlog, Groom Prioritized Product Backlog, and Demonstrate and Validate Sprint.

·         Improvements can also result in Change Requests, which are discussed and approved during the Develop Epic(s), Create Prioritized Product Backlog, and Groom Prioritized Product Backlog processes.

·         The Scrum Guidance Body interacts with Scrum Team members during the Create User Stories, Estimate Tasks, Create Deliverables, and Groom Prioritized Product Backlog processes to offer guidance and also provide expertise as required.

·         In the Retrospect Sprint process, Agreed Actionable Improvements are determined based on the outputs from the Demonstrate and Validate Sprint process.

·        In Retrospect Project Meeting, participants document lessons learned and perform reviews looking for opportunities to improve processes and address inefficiencies.

The following diagram summarizes the concept of adaptation in Scrum:

With other methods, like the traditional Waterfall model, considerable planning needs to be done in advance and the customer generally does not review product components until near the end of a phase, or the end of the entire project. This method often presents huge risks to the project’s success because it may have more potential for significantly impacting project delivery and customer acceptance. The customer’s interpretation and understanding of the finished product may be very different from what was actually understood and produced by the team and this may not be known until very late in the project’s development.

The Need for Scrum Body of Knowledge (SBOK)

In recent years, it has become evident that organizations which use Scrum as their preferred project delivery framework consistently deliver high Returns on Investment. Scrum’s focus on value-driven delivery helps Scrum Teams deliver results as early in the project as possible.

The SBOK™ Guide was developed as a means to create a necessary guide for organizations and project management practitioners who want to implement Scrum, as well as those already doing so who want to make needed improvements to their processes. It is based on experience drawn from thousands of projects across a variety of organizations and industries. The contributions of many Scrum experts and project management practitioners have been considered in its development.

You can view a video on this here: http://www.scrumstudy.com/watch.asp?vid=438

The SBOK™ Guide is especially valuable:

·         to Scrum Core Team members including:

°      Product Owners who want to fully understand the Scrum framework and particularly the customer or stakeholder-related concerns involving business justification, quality, change, and risk aspects associated with Scrum projects.

°      Scrum Masters who want to learn their specific role in overseeing the application of Scrum framework to Scrum projects.

°      Scrum Team members who want to better understand Scrum processes and the associated tools that may be used to create the project’s product or service.

·         as a comprehensive guide for all Scrum practitioners working on Scrum projects in any organization or industry.

·         as a reference source for anyone interacting with the Scrum Core Team, including but not limited to the Portfolio Product Owner, Portfolio Scrum Master, Program Product Owner, Program Scrum Master, Scrum Guidance Body, and Stakeholders (i.e., sponsor, customer, and users).

·         as a handbook for any person who has no prior experience or knowledge of Scrum framework but wants to learn more about the subject.

The SBOK™ Guide is broadly divided into the following three areas:

1.    Principles covered in chapter 2, expand on the six principles which form the foundation on which Scrum is based.

2.    Aspects covered in chapters 3 through 7 describe the five aspects that are important considerations for all Scrum projects.

3.    Processes covered in chapters 8 through 12 include the nineteen Scrum processes and their associated inputs, tools, and outputs.

The following diagram illustrates the SBOK™ Guide framework, which shows that principles, aspects, and processes interact with each other and are equally important in getting a better understanding of the Scrum framework.

To summarize, it can be said that The SBOK™ Guide can be used as a reference and knowledge guide by both experienced Scrum and other product and service development practitioners, as well as by persons with no prior experience or knowledge of Scrum or project management methodology.

Important Processes in Scrum

Scrum processes address the specific activities and flow of a Scrum project. In total there are nineteen processes which are grouped into five phases, namely, Initiate, Plan and Estimate, Implement, Review and Retrospect, and Release.

Here is a video on Scrum processes:

The Initiate phase includes the following processes:

Create Project Vision—in this process, the Project Business Case is reviewed to create a Project Vision Statement that will serve as the inspiration and provide focus for the entire project. The Product Owner is identified in this process.

Identify Scrum Master and Stakeholder(s)—in this process, the Scrum Master is identified using specific Selection Criteria.

Form Scrum Team—in this process, Scrum Team members are identified. Normally the Product Owner has the primary responsibility of selecting team members, but often does so in collaboration with the Scrum Master.

Develop Epic(s)—in this process, the Project Vision Statement serves as the basis for developing Epic(s). User Group Meetings may be held to develop Epic(s).

Create Prioritized Product Backlog —in this process, Epic(s) are refined, elaborated, and then prioritized to create a Prioritized Product Backlog for the project. The Done Criteria is also established at this point.

Conduct Release Planning—in this process, the Scrum Core Team reviews the User Stories in the Prioritized Product Backlog to develop a Release Planning Schedule, which is essentially a phased deployment schedule that can be shared with the project stakeholders. Length of Sprint is also determined in this process.

The Plan and Estimate phase includes the following processes:

Create User Stories—In this process User Stories and their related User Story Acceptance Criteria are created. User Stories are usually written by the Product Owner and are designed to ensure that the customer’s requirements are clearly depicted and can be fully understood by all stakeholders. User Story Writing Exercises may be held which involves Scrum Team members creating the User Stories. User Stories are incorporated into the Prioritized Product Backlog.

Approve, Estimate, and Commit User Stories—In this process the Product Owner approves User Stories for a Sprint. Then, the Scrum Master and Scrum Team estimate the effort required to develop the functionality described in each User Story, and the Scrum Team commits to deliver the customer requirements in the form of Approved, Estimated, and Committed User Stories.

Create Tasks—In this process the Approved, Estimated, and Committed User Stories are broken down into specific tasks and compiled into a Task List. Often a Task Planning Meeting is held for this purpose.

Estimate Tasks—In this process the Scrum Core Team, in Task Estimation Meetings, estimate the effort required to accomplish each task in the Task List. The result of this process is an Effort Estimated Task List.

Create Sprint Backlog—In this process the Scrum Core Team holds Sprint Planning Meetings where the group creates a Sprint Backlog containing all tasks to be completed in the Sprint.

The Implement phase includes the following processes:

Create Deliverables—In this process, the Scrum Team works on the tasks in the Sprint Backlog to create Sprint Deliverables. A Scrumboard is often used to track the work and activities being carried out. Issues or problems being faced by the Scrum Team could be updated in an Impediment Log.

Conduct Daily Standup—In this process, everyday a highly focused, Time-boxed meeting is conducted referred to as the Daily Standup meeting. This is the forum for the Scrum Team to update each other on their progress and any impediments they may be facing.

Groom Prioritized Product Backlog—In this process, the Prioritized Product Backlog is continuously updated and maintained. A Prioritized Product Backlog Review Meeting may be held, in which any changes or updates to the backlog are discussed and incorporated into the Prioritized Product Backlog as appropriate.

The Review and Retrospect phase includes the following processes:

Convene Scrum of Scrums—In this process Scrum Team representatives convene for Scrum of Scrums Meetings in predetermined intervals or whenever required to collaborate and track their respective progress, impediments, and dependencies across teams. This is relevant only for large projects where multiple Scrum Teams are involved.

Demonstrate and Validate Sprint—In this process, the Scrum Team demonstrates the Sprint Deliverables to the Product Owner and relevant stakeholders in a Sprint Review Meeting. The purpose of this meeting is to secure approval and acceptance from the Product Owner for the Deliverables created in the Sprint.

Retrospect Sprint—In this process, the Scrum Master and Scrum Team meet to discuss the lessons learned throughout the Sprint. This information is documented as lessons learned which can be applied to future Sprints. Often, as a result of this discussion, there may be Agreed Actionable Improvements or Updated Scrum Guidance Body Recommendations.

The Release phase includes the following processes:

Ship Deliverables—In this process, Accepted Deliverables are delivered or transitioned to the relevant stakeholders. A formal Working Deliverables Agreement documents the successful completion of the Sprint.

Retrospect Project—In this process, which completes the project, organizational stakeholders and Scrum Core Team members assemble to retrospect the project and identify, document, and internalize the lessons learned. Often, these lessons lead to the documentation of Agreed Actionable Improvements, to be implemented in future projects.

How can I start My Scrum Certification Journey? Do I need any training?

Organizations around the globe have accepted Scrum as a primary project management framework for their projects, especially when they operate in a dynamic business environment. Growing popularity and acceptability of Scrum has created a great demand for Scrum and Agile certified professionals in the job market.

SCRUMstudy, the global accreditation body for Scrum and Agile certifications, offers a comprehensive certification program with several popular Scrum/Agile credentials.

Though there is no mandatory prerequisite for most of the SCRUMstudy certifications, it is always better to understand the hierarchy structure. The diagram below shows you the preferred as well as optional certification to move to the next level.

You can start your certification journey, by taking the free certification on 'Scrum Fundamentals Certified’. The online course is tailored to help anyone interested to know more about Scrum, learn about key concepts in Scrum as defined in the SBOK™ Guide, and to get a basic understanding of how Scrum framework works in delivering successful projects. Once you complete the course and pass the exam at the end of the course, you will be accredited as "Scrum Fundamentals Certified". For more details, visit: http://www.scrumstudy.com/Scrum-Fundamentals-Certified.asp

Many delegates undergo formal training to prepare for advanced certification exams offered by SCRUMstudy to get hands-on experience of implementing Scrum in real life projects. More than 140 SCRUMstudy Authorized Training Partners conduct certification training and classes globally. All the certification exams are based on the Scrum Body of Knowledge (SBOK Guide) which can be downloaded for free in SCRUMstudy website: http://www.scrumstudy.com/download-free-buy-SBOK.asp

What are the Key Principles of Scrum?

Scrum principles are the foundation on which the Scrum framework is based. The principles of Scrum can be applied to any type of project or organization, and they must be adhered to in order to ensure appropriate application of Scrum.

Here is a video on Scrum principles:

http://www.scrumstudy.com/watch.asp?vid=441

The Principles of Scrum are:

Empirical Process Control: This is the first principle of Scrum and the three important ideas of transparency, inspection and adaptation. In Scrum, decisions are made based on observation and experimentation rather than on detailed upfront planning. Empirical process control relies on the three main ideas of transparency, inspection, and adaptation.

Self-organization: This principle of Scrum highlights the staff members who can offer higher productivity in services when they are properly organized by means of team spirit and self-ownership of a project. Scrum believes that employees are self-motivated and seek to accept greater responsibility. So, they deliver much greater value when self-organized. The preferred leadership style in Scrum is “servant leadership”, which emphasizes achieving results by focusing on the needs of the Scrum Team.  

Self-organization as an essential principle in Scrum leads to the following:

·         Team buy-in and shared ownership

·         Motivation, which leads to an enhanced performance level of the team

·         Innovative and creative environment conducive to growth

Collaboration

Collaboration in Scrum refers to the Scrum Core Team working together and interfacing with the stakeholders to create and validate the deliverables of the project to meet the goals outlined in the Project Vision. It is important to note the difference between cooperation and collaboration here. Cooperation occurs when the work product consists of the sum of the work efforts of various people on a team. Collaboration occurs when a team works together to play off each other’s inputs to produce something greater.

The core dimensions of collaborative work are as follows:

·         Awareness—Individuals working together need to be aware of each other’s work.

·         Articulation—Collaborating individuals must partition work into units, divide the units among team members, and then after the work is done, reintegrate it.

·         Appropriation—Adapting technology to one’s own situation; the technology may be used in a manner completely different than expected by the designers.

Value-based Prioritization: This principle mainly concentrates on the framework of SCRUM in order to provide the optimum business value in the least possible time. The Scrum framework is driven by the goal of delivering maximum business value in a minimum time span. One of the most effective tools for delivering the greatest value in the shortest amount of time is prioritization. Scrum uses Value-based Prioritization as one of the core principles that drives the structure and functionality of the entire Scrum framework—it helps projects benefit through adaptability and iterative development of the product or service. More significantly, Scrum aims at delivering a valuable product or service to the customer on an early and continuous basis.

Time-Boxing: Scrum treats time as one of the most important constraints in managing a project. To address the constraint of time, Scrum introduces a concept called ‘Time-boxing’ which proposes fixing a certain amount of time for each process and activity in a Scrum project. This ensures that Scrum Team members do not take up too much or too little work for a particular period of time and do not expend their time and energy on work for which they have little clarity.

Some of the advantages of Time-boxing are as follows:

·         Efficient development process

·         Less overheads

·         High velocity for teams

Iterative Development: The Scrum framework is driven by the goal of delivering maximum business value in a minimum time span. To achieve this practically, Scrum believes in Iterative Development of Deliverables.

In most complex projects, the customer may not be able to define very concrete requirements or is not confident of what the end product may look like. The iterative model is more flexible in ensuring that any change requested by the customer can be included as part of the project. User Stories may have to be written constantly throughout the duration of the project. In the initial stages of writing, most User Stories are high-level functionalities.