#sbok

One of the major misconceptions or criticisms about Scrum is that it cannot be used to deliver large scale projects that have multiple large teams which are not collocated. And for Scrum to be effective, the teams should ideally be collocated and have six to ten members. However, this is not valid as Scrum can easily be scaled for effective use in large projects. In situations where the Scrum Team size exceeds ten people, multiple Scrum Teams can be formed to work on the project.

Complex projects with numerous large teams working in parallel make it necessary to synchronize and facilitate the flow of information and enhance communication for the project to be successful. Scrum uses one of its events or ceremonies to overcome this barrier, i.e., Scrum of Scrums (SoS) meeting. 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.

SoS is a review meeting for all the Scrum teams involved in the project. The main purpose of this meeting is to communicate progress among multiple teams. Scrum Master from all teams attend this meet. The meeting is most effective when the Chief Scrum Master announces the agenda prior to the meeting. This prepares the participants to gather appropriate information and issues to be discussed.

Any impediments being faced by a team which may also affect other teams are brought up in this meeting. Teams get an overall view of the development of the project and redirect their efforts meaningfully. This review meeting plays a crucial role in identifying risks and change requirements of each team which in turn affects other teams’ line of work. This also brings to the forefront any production duplications that may occur because of the scale of the project. An impediment log is created stating internal and external impediments. This log helps in resolving issues systematically.

The Chief Scrum Master (or another Scrum Master who facilitates the Scrum of Scrum Meetings) is responsible for ensuring that all representatives have an environment conducive to openly and honestly sharing information, including feedback to other team representatives. This conducive environment plays a vital role in better communication and identification of important issues. It contributes greatly to the success of the project as a whole. The Chief Scrum Master should take care that all representatives speak their minds and do not reserve their issues and concerns which may later turn out to be costly. Updates are provided in the form of answers to four specific questions:

What has my team been working on since the last meeting?

What will my team do until the next meeting?

What were other teams counting on our team to finish that remains undone?

What is our team planning on doing that might affect other teams?

When these four questions are answered, following outcomes are achieved leading to successful project delivery: reduction in non-detection of risks, enhanced coordination among teams, continuous improvement, maintaining of team’s focus on achievement of project objectives, and reduction in need for redesign and rework.

Scrum developers, also referred to as the development team or Scrum team, are responsible for developing the product and they possess all the essential skills required to carry out the work of the project. They have a high level of collaboration to maximize productivity, so that minimal coordination is required to get things done. To minimize dependency, team members are experts in chosen domain, but also possess basic knowledge and skills about other domains.

Some of the key responsibilities of Scrum developers which they are required to fulfill in any Scrum project are:

Provides inputs for creation of the Collaboration Plan and the Team Building Plan

Ensures a clear understanding of Epic(s) and Personas

Understands the User Stories in the Prioritized Product Backlog

Agrees with other Scrum Core Team members on the Length of Sprint

Seeks clarification on new products or changes in the existing products, if any, in the Refined Prioritized Product Backlog

Provides inputs to the Product Owner on creation of User Stories

Estimates User Stories approved by the Product Owner

Commit User Stories to be done in a Sprint

Develops Task List based on agreed User Stories and dependencies

Estimates effort for tasks identified and if necessary, updates the Task List

Develops the Sprint Backlog and the Sprint Burndown Chart

Creates Deliverables

Identifies risks and implements risk mitigation actions, if any

Updates Impediment Log and dependencies

Updates Burndown Chart, Scrumboard, and Impediment Log

Discusses issues faced by individual members and seeks solutions to motivate the team

Identifies risks, if any

Submits Change Requests, if required

Participates in Prioritized Product Backlog Review Meetings

Provides inputs to Scrum Master for Scrum of Scrums Meetings

Demonstrates completed deliverables to the Product Owner for approval

Identifies improvement opportunities, if any, from the current Sprint and agrees on any actionable improvements for the next Sprint

The first thing that we need to figure out while dealing with Scrum master is whether they are full time Scrum masters, and the second question tends to what exactly their task is.

We usually don’t find a full time scrum master.  Scrum master, as described by scrum guide is the one who teaches, facilitates and removes impediments. When the team is relatively new it takes time and the team follows scrum religiously. This is when the team needs a scrum master who can teach scrum full time.

Facilitating is necessary, though it takes only 20 to 30 % of the time. The issues tend to lessen as the team learns to resolve them.

If a person puts 100% of his efforts being a scrum master, i.e. if he is training, facilitating that takes up only 20 to 25% of his time. Henec, he has to devote himself in helping the team with their work.

The first step is to train the project managers in Agile which is trying to get them to be certified scrum masters, and agile project managers, preferably from Project Management Institute.

Thus the project managers become the first scrum masters.  At first the scrum master shouldn’t be assigned to one team.

Probably assign two to three teams to one project managers. Their role is to train the team in Scrum.

This has to be followed for the initial six months, until the team gets used to the concept of Scrum.

Then once you are past the first 6 to 9 months have one of the team members to be a scrum master, it would be ideal if the team was allowed to select the scrum master from their team.

Then elevate the project manager to the level of program manager. This would enable them to become accountable for cross team initiatives,

Rearrange management structure, now as the roles have been altered. Instead of a functional manager we have a delivery manager.

The delivery manager is now accountable for training agile.

Thus Scrum Masters was underway as a position and evolved to be a role as the team becomes more mature in adapting Agile.

Ken Schwaber and Jeff Sutherland elaborated on the Scrum concept and its applicability to software development in a presentation at the Object-Oriented Programming Systems Languages & Applications (OOPSLA) conference held in 1995 in Austin, Texas. Since then, several Scrum practitioners, experts and authors have continued to refine the Scrum conceptualization and framework. In recent years, Scrum has increased in popularity and is now the preferred project development framework for many organizations globally.

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

The SBOK™ 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.

The SBOK™ is especially valuable:

to Scrum Core Team members including:

°      Product Owners who want to fully understand the Scrum framework and particularly the customer/business 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 Business Stakeholders (i.e., sponsor, customer, and users).

as a knowledge source for any persons who have no prior experience or knowledge of Scrum framework but wants to learn detail about the subject.

The content of the SBOK™ is also helpful for individuals preparing to write the following Scrumstudy™ Agile and Scrum certification exams:

Scrum Developer Certified (SDC™)

Scrum Master Certified (SMC™)

Agile Expert Certified (AEC™)

Scrum Product Owner Certified (SPOC™)

There is a common misconception that the Scrum framework can only be used for small projects. However, it can easily be scaled for effective use in large projects. Large or complex projects are often implemented as part of a program or portfolio. The Scrum framework can easily be applied to manage even programs and portfolios. The logical approach of the guidelines and principles in this framework can be used to manage projects of any size, spanning geographies and organizations. Large projects may have multiple Scrum Teams working in parallel making it necessary to synchronize and facilitate the flow of information and enhance communication. The Convene Scrum of Scrums is the process ensuring this synchronization. The various Scrum Teams are represented in this meeting and the objectives are to provide updates about progress, discuss challenges faced during the project, and coordinate activities. There are no set rules regarding the frequency of these meetings. The factors determining the frequency are the amount of inter-team dependency, size of the project, Scrum Guidance Body recommendations and the level of complexity.

In programs, important roles to manage Scrum programs are:

1. Program Product Owner—Defines the strategic objectives and priorities for the program

2. 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 that they meet the needs of their program or business unit rather than those of a single Scrum Team.

Similarly, in portfolios, important roles to manage Scrum portfolios are:

1. Portfolio Product Owner—Defines the strategic objectives and priorities for the portfolio

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

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 the SBOK™ 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 to 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 to 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.

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 business stakeholders of the program or portfolio.

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.

Many organizations all over the world are finding it hard to keep up with the fast-changing business scenarios, using the traditional project management methods. These scenarios may include periodic customer demands, fast-changing project requirements, and issues relating to support activities and so on. Increasingly, project managers and software developers have started to prefer Agile software development methods. Even the US Department of Defense, in a recent update to its procurement rules has made known its non-preference for ‘Waterfall model’-based project management solutions. Some of the most popular methods include Rational Unified Process, Scrum, Extreme Programming and Dynamic Systems Development Method.

An overview of the Agile methodology

The year 2001 saw the ‘Agile Manifesto’ being formulated by seventeen software programmers at Snowbird Resort in Utah, USA. The Agile Manifesto gives us twelve important principles, which include customer satisfaction, communication, co-operation, the importance of working software, and welcoming change.

Agile methods break-up complex tasks into small increments with nominal planning. Iterations are short time frames that may last between one to four weeks. The iteration involves a team with cross-functional skills. Planning, requirements analysis, designing, coding, unit testing, and acceptance testing are all taken care of by the same team. At the end of the iteration, a working product is presented to business stakeholders. This reduces overall risk and allows the project to adapt to changes swiftly.

An overview of the Scrum Framework

Scrum is one of the most popular Agile methodologies. As per the Scrum Book of Knowledge, Scrum is an adaptive, iterative, fast and flexible framework designed to quickly deliver significant value during a project. It ensures transparency in communication and creates an environment of collective accountability and continuous progress.

The typical Scrum project will include the below-mentioned steps:

The Project Vision is created during Business Stakeholder Meeting, following which the Product Owner develops a Prioritized Product Backlog. This includes a ranked list of business requirements written in the form of User Stories).

The Product Owner consents about the Deliverables only if they meet the previously agreed Acceptance Criteria.The Sprint comes to an end with a Retrospect Sprint Meeting where the Scrum team deliberates ways to develop processes as they move ahead into succeeding Sprints.

A Sprint Planning Meeting is the first activity within a Sprint, during which high priority User Stories in the Prioritized Product Backlog are considered to be included within the Sprint.

A Sprint usually lasts between one and six weeks, where the Scrum Team works to create theoretically shippable Deliverables or product increments.

During the Sprint, short yet extremely focused Daily Standup Meetings are coordinated by the Scrum Master where the Scrum Team discusses progress.

In the field of organization behaviour, the notion of the high-performing team has been discussed. Many of today’s Customers need rapidly adapting development services. High-performing teams are the key to providing that service. A mature high-performing team is a united unit, not merely a throng of individuals. While such teams usually emerge by chance; a high-performing team can also be deliberately molded with an understanding of team member requirements in mind. Scrum framework which brings out the truly necessary essentials, can help with achieving this. While Scrum Framework increases the chances of such a team forming, it is not a necessary or sufficient condition for high-performing teams.

Certain enablers can herald formation of high-performing teams: Some of them come in the form of Human resource practices for the organization. However, they regularly get over-complicated or misapplied. Scrum team is often encumbered with overwhelming info, which cripples the ability to think clearly. The Scrum Core team members become burdened by esoteric language, process, principles or practices that clutter their minds and focus. Great Scrum Masters don’t strictly enforce working hours. What they do enforce is presence on the Daily Standups- everyone on a given team has to be there and there are penalties for being late. Daily Standups” instil discipline by requiring a fifteen-minute daily meeting.

Classic environmental enablers in Scrum include collocated teams, team rooms/war rooms, visible charts, and white boards. By being responsible for this environment, a great Scrum Master can help in creating high-performing teams that effectively address business’ needs. The product backlog is A Great Scrum Master’s best source of reality to give feedback as to whether they are making the right decisions and having the right conversations. With conversations a Great Scrum Masters can help the Scrum Team detect if understanding is there. Scrum advocates that the teams should have the freedom to decide how they will deliver the User Stories they committed to during the sprint planning.

High performing teams collaborate by visibility. With visible product backlog or a Scrumboard, Business Stakeholders see where effort is being applied. When a Product Owner can see where to apply effort, the Scrum Team members work together and do not flounder. In projects, much of the work is not easily visible and therefore self-organization is necessary. With visible work efforts Great Scrum Masters improve the odds that each conversation will be the right one and make reporting on team progress easy.

Leadership styles vary depending on the organization, the situation, and even the specific individuals and objectives of the Scrum project. The leadership style will determine the work culture of the team and also the behaviour of the Scrum Team members. Some common leadership styles are as follows:

Autocratic: Autocratic leaders do not delegate the powers to others and decision making powers are rested with the leader. They do not take the suggestions from others and compel others to follow their decision or orders. In this style of leadership, employees do not have any freedom to put forth their views.

Democratic: This leadership style is completely opposite of the autocratic style. Here, the leader is the representative of employees and is selected with the consent of all the team members. He takes suggestions, inputs and discuss with the team members before he takes the decision. However, the power remains with the leader and responsibility is delegated to the team members.

Laissez Faire: The leader in this style of leadership is hardly interested in supervising the scrum team’s activity and their performance. The team members are left at large to perform and achieve the goals. In such style of leadership, the impediments faced by the team are not removed and this may lead to failure of the projects.

Supporting Leadership—Supporting leaders employ listening, empathy, commitment, and insight while sharing power and authority with team members. Supporting leaders are stewards who achieve results by focusing on the needs of the team. This style is the embodiment of the Scrum Master role.

Delegating: These leaders delegate the authority and responsibility to the team members. Team members can make the decisions and take the responsibility of their activities. This is done, when the leader feels that the members are competent enough to the decisions. Leader is invited to involve in the decision making if it is demanded by the situation.

Directing: Directing leaders in scrum team provide instructions to team members on each and every task need to be performed. This some time may reduce the confidence of the team members and they always expect the leader to guide them.

Assertive: Assertive leaders confront issues and display confidence to establish authority with respect.