Retrospect Scrum Project: The Lessons to be learnt

After a project is over, it is important that the Scrum team and the stakeholders look back and discuss the lessons learnt during the course of the project. This in itself is a process, called the Retrospect project, which comes right after the deliverables are shipped.
The Release phase emphasizes delivering the Accepted Deliverables to the customer and identifying, documenting, and internalizing the lessons learned during the project. In the Retrospect Project 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.

Inputs

Scrum Core Team(s)

Chief Scrum Master

Chief Product Owner

Stakeholder(s)

Scrum Guidance Body Recommendations

In Retrospect Project process, Scrum Guidance Body Recommendations can include a repository of internal templates that support the future projects, and guidance for conducting the Retrospect Project Meeting. The guidance provided can relate to administrative procedures, audits, evaluations, and project transition criteria. Often, they also include how the organization will maintain the knowledge base of lessons learned and information from all projects.

Tools

Retrospect Project Meeting*

The Retrospect Project Meeting is a meeting to determine ways in which team collaboration and effectiveness can be improved in future projects. Positives, negatives, and potential opportunities for improvement are also discussed. This meeting is not Time-boxed and may be conducted in person or in a virtual format. Attendees include the Project Team, Chief Scrum Master, Chief Product Owner, and Stakeholder(s). During the meeting, lessons learned are documented and participants look for opportunities to improve processes and address inefficiencies.

Other Tools for Retrospect Project

Some of the tools used in the Retrospect Sprint process can also be used in this process. Examples include:

• Explorer — Shopper — Vacationer — Prisoner (ESVP) exercise
• Speed Boat
• Metrics and Measuring Techniques

Scrum Guidance Body Expertise

In Retrospect Project process, the primary responsibility of the Scrum Guidance Body is to ensure that the lessons learned in each project are not lost and are embedded in the organization. Also, there may be suggestions in the Scrum Guidance Body Recommendations concerning how the Retrospect Project meeting should be conducted.

Outputs

Agreed Actionable Improvements

Agreed Actionable Improvements are the primary output of the Retrospect Sprint process. They are the list of actionable items that the team has come up with to address problems and improve processes in order to enhance their performance in future Sprints.

Assigned Action Items and Due Dates

Once the Agreed Actionable Improvements have been elaborated and refined, action items to implement the improvements may be considered by the Scrum Team. Each action item will have a defined due date for completion.

Proposed Non-functional Items for Program Product Backlog and Prioritized Product Backlog

When the initial Prioritized Product Backlog is developed, it is based on User Stories and required functionalities. Often, non-functional requirements may not be fully defined in the early stages of the project and can surface during the Sprint Review or Retrospect Sprint Meetings. These items should be added to the Prioritized Product Backlog as they are discovered. Some examples of non-functional requirements are response times, capacity limitations, and security related issues.

Updated Scrum Guidance Body Recommendations

The self-organizing and empowered Scrum Team is expected to learn from any mistakes made during a Sprint – and these lessons learned help the teams improve their performance in future Sprints.. These lessons learned may also be documented in Scrum Governance Board Recommendations to be shared with other Scrum teams.

Scrum methodology in Projects, Programs, and Portfolios

We know that a Scrum project involves a collaborative effort to create a new product, service, or any other result. So we need to define, how the methodology works for a project, program or portfolio. But before that, we need to define these three terms.
Definition of Project, Program, and Portfolio

• Project—A project is a collaborative enterprise to either create new products or services or to deliver results as defined in the Project Vision Statement. Projects are usually impacted by constraints of time, cost, scope, quality, people and organizational capabilities. The objective of project team is to Create Deliverables as defined in Prioritized Product Backlog.

• Program—A program is a group of related projects, with the objective to deliver business outcomes as defined in the Program Vision Statement. The Prioritized Program Backlog incorporates the Prioritized Product Backlogs for all the projects in the program.

• Portfolio—A portfolio is a group of related programs, with the objective to deliver business outcomes as defined in the Portfolio Vision Statement. The Prioritized Portfolio Backlog incorporates the Prioritized Program Backlogs for all the projects in the program.

Scrum in Projects
Since Scrum favors small teams, one may think that this method can only be used on small projects, but this is not the case. Scrum can also be used effectively on large-scale projects. When more than ten people are required to carry out the work, multiple Scrum Teams may be formed. The project team consists of multiple Scrum Teams working together to Create Deliverables and Product Releases, so as to achieve outcomes desired for the overall project.
Since a project can have multiple Scrum Teams working in parallel, coordination between different teams becomes important. The Scrum Teams usually communicate and coordinate with each other in a variety of ways, but the most common approach is known as a Scrum of Scrums (SoS). Members representing each Scrum Team come together to discuss progress and issues and to coordinate activities between teams. These meetings are similar in format to the Daily Standup Meetings; however, the frequency of the Scrum of Scrums could be pre-determined intervals or they could be coordinated as required by the different Scrum Teams.

Scrum of Scrums (SoS) Meeting
A Scrum of Scrums Meeting is an important element when scaling Scrum to large projects. Typically, there is one representative in the meeting from each Scrum Team—usually the Scrum Master—but it is also common for anyone from the Scrum Team to attend the meeting if required. This meeting is usually facilitated by the Chief Scrum Master and is intended to focus on areas of coordination and integration between the different Scrum Teams. This meeting is conducted at pre-determined intervals or when required by the Scrum Teams.
In organizations that have several Scrum projects happening simultaneously, the Scrum of Scrums meeting can be scaled up another level to what is referred to as a Scrum of Scrum of Scrums meeting. In this situation, a separate Scrum of Scrums Meeting is held to coordinate each group of projects that are directly related to each other.

In this example, there are six projects taking place simultaneously. Three of the projects are directly related to each other: projects A, B, and C. The other three that are directly related to each other are projects D, E, and F. A Scrum of Scrums meeting is held to coordinate the interdependencies between the projects in each directly related group. Then a Scrum of Scrums of Scrums Meeting is conducted to coordinate and manage the activities of all projects.
Scrum in Programs and Portfolios

Programs

In programs, important roles to manage Scrum programs are:
Program Product Owner—Defines the strategic objectives and priorities for the program
Program Scrum Master—Solves problems, removes impediments, facilitates, and conducts meetings for the program
These roles are similar to those of the Product Owner and Scrum Master except they meet the needs of their program or business unit rather than those of a single Scrum Team.
Portfolios
Similarly, in portfolios, important roles to manage Scrum portfolios are:
Portfolio Product Owner—Defines the strategic objectives and priorities for the portfolio
Portfolio Scrum Master—Solves problems, removes impediments, facilitates, and conducts meetings for the portfolio
The needs and structure of each organization are different. It is the responsibility of the Scrum Guidance Body to scrutinize the organization at different levels to understand and define appropriate application of Scrum and to act as a consulting body for everyone working on a project, program, or portfolio.

Working with Program and Portfolio Team

 
 When applying Scrum to manage projects within the context of a program or portfolio, it is strongly recommended that the general principles of Scrum presented in this publication are adhered to. It is understood though, that in order to accommodate the overall program or portfolio activities and interdependencies, minor adjustments to the set of tools, as well as the organizational structure may be required.
Portfolios and programs have separate teams with different sets of objectives. Program management teams aim to deliver capabilities and realize certain goals that contribute toward the achievement of specific program objectives. In contrast, the portfolio team has to balance the objectives of various programs to achieve the strategic objectives of the organization as a whole.
Managing Communication with Program and Portfolio Teams
The problems and issues faced when using Scrum within a program or portfolio primarily involve coordination across numerous teams. This can lead to failure if not carefully managed. Tools used for communication need to be scaled to match the requirements of the many teams involved in a program or portfolio. Each Scrum Team must address not only internal communications, but also external communications with other teams and the relevant stakeholders of the program or portfolio.

Maintaining Stakeholder Involvement

Scrum requires complete support from the project stakeholders. The responsibility for keeping stakeholders engaged lies with the Product Owner. The following are actions recommended for maintaining stakeholder engagement and support:

• Ensure effective collaboration and stakeholder involvement in the project
• Continually assess business impact
• Maintain regular communication with stakeholders
• Manage stakeholders’ expectations

One key stakeholder is the sponsor—the individual who provides the funds and other resources for a project. Sponsors want to understand the financial bottom line related to a product or service and are typically more concerned with final outcomes rather than with individual tasks.
It is important that the sponsors who are funding the project have clarity on the following issues:

• Benefits of implementing Scrum
• Target deadlines and estimated costs of Scrum project
• Overall risks involved in Scrum projects and the steps to mitigate them
• Expected release dates and final Deliverables

Acknowledgement: This content is the copyright of www.scrumstudy.com
Original url: http://www.scrumstudy.com/blog/scrum-methodology-in-projects-programs-and-portfolios/ 

The Principle of Prioritization

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.
Prioritization can be defined as “Determination of the order and separation of what must be done now, from what needs to be done later”. The concept of prioritization is not new to project management. The traditional Waterfall model of project management proposes using multiple task prioritization tools. From the Project Manager’s point of view, prioritization is integral because certain tasks must be accomplished first to expedite the development process and achieve the project goals.


Some of the traditional techniques of task prioritization include setting deadlines for delegated tasks and using prioritization matrices. 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. Prioritization is done by the Product Owner when he or she prioritizes User Stories in the Prioritized Product Backlog. The Prioritized Product Backlog contains a list of all the requirements needed to bring the project to fruition.
Once the Product Owner has received the business requirements from the customer and written these down in the form of workable User Stories, he or she works with the customer and sponsor to understand which business requirements provide maximum business value.
The Product Owner must understand what the customer wants and values in order to arrange the Prioritized Product Backlog Items (User Stories) by relative importance.
Prioritization results in deliverables that satisfies the requirements of the customer with the objective of delivering the maximum business value in the least amount of time.
For interesting articles about Scrum and Agile, visit www.scrumstudy.com/blog

Is Scrum Master a full time role?

It is not uncommon in a Scrum Master training classes to encounter questions such as “Is being a Scrum Master a full time role?”, or “How much time does a Scum Master contribute towards his role?”, or “Can a person from the development team multitask as a Scrum Master?”
New Scrum Masters might be apprehensive about the role that they might play as future Scrum Masters. However, certified Scrum Masters need to truly understand the responsibilities of a Scrum Master to realize the vital role played by them. The success of a Scrum project rests equally on the shoulders of the Product Owner, the Scrum Master, and the Development team. While the Product Owner and the Development team have their clearly established roles and responsibilities, it might seem that a Scrum Master performs only support roles such as coordinating meetings, removing impediments that are plaguing the team, or shielding the team from interference from the Product Owner.  This might make the Scrum Master seem like a glorified nanny.
Even organizations too sometimes view the Scrum Master role as a part time role. There can be several reasons why Scrum Masters are part time roles. The organization might be short of human resources to have a dedicated Scrum Master or the organization does not consider the Scrum Master’s role worthy of a full time role.
There is an obvious conflict if a developer also performs the role of a Scrum Master. This takes away the objectivity that is required in a Scrum Master while dealing with issues related to the Product Owner or even internal conflicts.
So, let’s focus on the issue where the role of Scrum Master is not considered substantial enough to be a full time role. Sprints in Scrum, unlike stages in waterfall, are intensive periods of activity where development takes place. Any impediments that are not resolved immediately can have an effect on the success or failure of a sprint. The Scrum Master not only resolves impediments as and when they arrive, but also has keen foresight to spot potential issues and create an environment that can help avoid any issues to occur.
The Scrum Master undoubtedly assumes the role of a leader. He coaches and mentors team members both at an individual and a group level to get the best out of the team. He also ensures the team collaborates smoothly and the team delivers what they committed to.
It might seem that a Scrum Master’s responsibilities are vague and general. However, most of the Scrum Master’s responsibilities are performed behind the scenes that require a strong understanding of multiple dimensions such as people, domain, and business requirements.

This content is borrowed from www.scrumstudy.com (Original URL: http://www.scrumstudy.com/blog/is-scrum-master-a-full-time-role/ )

Ways To SCRUM

 Ways To SCRUM

Scrum is flexible, transparent and iterative, making it very different from complex traditional project management methodologies. In this article, we will look at the various areas in which Scrum differs from other methods.

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.

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 managers or 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/she takes decisions on various aspects of the project, including initiating, planning, estimating, executing, monitoring and controlling and closing.

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. 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. And 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.

 Acknowledgement: The content is borrowed from www.SCRUMstudy.comwww.SCRUMstudy.com (original blog url: http://www.scrumstudy.com/blog/scrumstudy-scrumvideo-on-the-differences-between-scrum-and-traditional-project-management/)