Introduction


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 the project team is to create Deliverables as defined in the Prioritized Product Backlog.

The term “Agile” generally refers to being able to move or respond quickly and easily; being nimble. In any kind of management discipline, Agile as a quality would therefore be a valid aim. Agile project management specifically, involves being adaptive during the creation of a product, service, or other results. It is important to understand that while Agile development methods are highly adaptive, it is also necessary to incorporate stability in their adaptive processes.

Rapid changes in technology, market demands, and expectations have resulted in increased challenges to developing products and services using traditional project management models. This paved the way for the conceptualization and implementation of Agile methods and values in many organizations. Agile development models addressed the shortcomings associated with traditional project management models in meeting the ever-growing environmental demands and expectations that organizations were facing. Since traditional project management models generally emphasize extensive upfront planning and conforming to the plan once it is baselined, such models were not successful in meeting the reality of frequent environmental changes.

 Agile relies on adaptive planning and iterative development and delivery. It focuses primarily on the value of people in getting the job done effectively. Though adaptive and incremental methodologies have existed since the 1950s, only methodologies that conform to The Agile Manifesto are generally regarded as truly “Agile”.

The Agile Manifesto is a document that sets out the four key values and twelve principles behind the Agile philosophy and serves to help development teams work more efficiently and sustainably.

As mentioned in the Agile Manifesto:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work, we have come to value the following:

Individuals and interactions

Over

Processes and Tools

Working software

Over

Comprehensive Documentation

Customer collaboration

Over

Contract Negotiation

Responding to change

Over

Following a Plan

That is, while there is value in the items on the right, we value the items on the left more.

The figure below summarizes the twelve Principles of the Agile Manifesto.
Text

Description automatically generated with medium confidence

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

The Scrum framework, as defined in the SBOK® Guide, is structured in such a way that it supports product and service development in all types of industries and in any type of project, irrespective of its complexity. A key strength of Scrum lies in its use of cross-functional, self-organized, and empowered teams who divide their work into short, concentrated work cycles called Sprints.

A Scrum project involves a collaborative effort to create a new product, service, or other results as defined in the Project Vision Statement. Projects are impacted by constraints of time, cost, scope, quality, resources, organizational capabilities, and other limitations that make them difficult to plan, execute, manage, and ultimately succeed. However, successful implementation of the results of a finished project provides significant business benefits to an organization. It is therefore important for organizations to select and practice an appropriate project management approach. 

Project management is described as the process of steering a project from inception to finish. The primary goal of project management is to finish a project within the time, money, and quality constraints that have been defined. Projects have life cycles because they are not meant to live forever. A project management life cycle begins when the project is launched and ends when it is completed or terminated in some way.

Traditional projects emphasize on extensive upfront planning and adherence to the project plan created by the project manager. Usually, changes are managed through a formal change management system and value is created at the end of the project when the final product is delivered.

In Scrum projects, extensive long-term planning is not done prior to project execution. Planning is done in an iterative manner before each Sprint. This allows quick and effective response to change, which results in lower costs and ultimately increased profitability and Return on Investment (ROI). Moreover, Value-Driven Delivery is a key benefit of the Scrum framework and provides significantly better prioritization and quicker realization of business value. Because of the iterative nature of Scrum development, there is always at least one release of the product with Minimum Marketable Features (MMF) available. Even if a project is terminated, there are usually some benefits or values created prior to termination.

To deliver the greatest amount of value in the shortest amount of time, Scrum promotes prioritization and Time-boxing over fixing the scope, cost, and schedule of a project. An important feature of Scrum is self-organization, which allows the individuals who are actually doing the work to estimate and take ownership of tasks.

The following table summarizes many of the differences between Scrum and traditional Project Management:

Parameters

Scrum

Traditional Project Management

Emphasis is on

People

Processes

Documentation

Minimal—only as required

Comprehensive

Process style

Iterative

Linear

Upfront planning

Low

High

Prioritization of Requirements

Based on business value and regularly updated

Fixed in the Project Plan

Quality assurance

Customer-centric

Process-centric

Organization

Self-organized

Managed

Management style

Decentralized

Centralized

Change

Updates to Productized Product Backlog

Formal Change Management System

Leadership

Collaborative Leadership

Command and control

Performance measurement

Business value

Plan conformity

Return on Investment (ROI)

Early/throughout the project life

End of project life

Customer Involvement

High throughout the project

Varies depending on the project lifecycle

 

One of the key characteristics of any project is the uncertainty of results or outcomes. It is impossible to guarantee project success at completion, irrespective of the size or complexity of a project. Considering this uncertainty of achieving success, it is therefore important to start delivering results as early in the project as possible. This early delivery of results, and thereby value, provides an opportunity for reinvestment and proves the worth of the project to interested business stakeholders. It is important to:

  1. Understand what adds value to customers and users and prioritize the high-value requirements on the top of the Prioritized Product Backlog.
  2. Decrease uncertainty and constantly address risks that can potentially decrease value if they materialize. Also work closely with business stakeholders showing them product increments at the end of each Sprint, enabling effective management of changes.
  3. Create Deliverables based on the priorities determined by producing potentially shippable product increments during each Sprint so that customers start realizing value early on in the project.

Some of the key differences with respect to Value-driven Delivery between Scrum projects and Traditional projects are given in the figure below.

          Diagram, text

Description automatically generated

In Scrum projects, User Stories are ranked in order of priority which is an effective method for determining the desired User Stories for each iteration or release of the product or service. The purpose is to create a simple, single list with the goal of prioritizing features, rather than being distracted by multiple prioritization schemes.

This simple list also provides a basis for incorporating changes and identifying risks when necessary. Each change or identified risk can be inserted in the list based on its priority relative to the other User Stories in the list. Typically, new changes will be included at the expense of features that have been assigned a lower priority. Minimum Marketable Features (MMF) are also defined, so that the first release or iteration happens as early as possible, leading to increased ROI.

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 fundamental Scrum processes and their associated inputs, tools, and outputs. Chapters 13 and 14 cover the additional inputs, tools, outputs, and processes specific to Scaling Scrum for Large Projects and Scaling Scrum for the Enterprise.

The figure below 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.

 

The Scrum cycle begins with a Stakeholder Meeting, during which the Project Vision is created. The Product Owner then develops a Prioritized Product Backlog which contains a prioritized list of business and project requirements written in the form of User Stories. Each Sprint begins with a Sprint Planning Meeting during which high-priority User Stories are considered for inclusion in the Sprint. A Sprint generally lasts between one and four weeks and involves the Scrum Team working to create potentially shippable Deliverables or product increments. During the Sprint, short, highly focused Daily Standup Meetings are conducted where team members discuss daily progress. Toward the end of the Sprint, a Sprint Review Meeting is held during which the Product Owner and relevant Business stakeholders are provided with a demonstration of the Deliverables. The Product Owner accepts the Deliverables only if they meet the predefined Acceptance Criteria. The Sprint cycle ends with a Retrospect Sprint Meeting where the team discusses ways to improve processes and performance as they move forward into the subsequent Sprint.

A key strength of Scrum lies in its use of cross-functional, self-organized, and empowered teams who divide their work into short, concentrated work cycles called Sprints. The below figure provides an overview of a Scrum project’s flow for one Sprint.

 

It is highly recommended that a Scrum Project Tool should be procured by the company to ensure distributed work, and also ensure that the Scrum Teams can work productively even when all Team Members cannot be collocated at the workplace. The tool should provide the capability to:

  • Define all Scrum roles efficiently and provide messaging/collaboration functionality for all team members to interact with each other.
  • Provide the ability to create and work through important Scrum artifacts such as Prioritized Product Backlog, Sprint Backlog, Scrumboard, etc.
  • Provide the workflow to work through different Scrum processes including Initiate, Planning, Implementing, Retrospect, and Release.
  • If it is being implemented inside a large organization/enterprise, the tool should provide the ability to scale to organization or enterprise levels.
  • Scrum teams need to attend multiple meetings such as Daily Standups, Sprint Review Meetings, etc - so the tool should provide the ability to schedule such meetings. However, the actual web meetings may be conducted in a separate Video Conferencing tool.
  • Effective Collocated Scrum teams talk with each other regularly - so the tool used for distributed Scrum teams should provide the ability for Scrum teams to chat with each other online - either one on one or through distributed groups. However, unlike a collocated team, team members need to understand that others may not be available to chat at the same time. So, the Scum tool should provide an online chat room and/or discussion forum.
  • Ability to capture lessons learnt and learn from retrospectives - preferably such processes should be automated with appropriate reports generated on the fly.
  • Provide automation so that templates and guidance through Scrum Guidance Body (SGB) are available to all Scrum teams in the company, for example, the definition of Done or the Definition of Ready as described in the SGB should be available to everyone in the project. Also, the tool should provide the SGB with the ability to determine Scrum behaviors it wants in its Scrum teams such as the maximum number of team members, duration of Sprint etc.
  • Provide the ability to clone from similar projects, Epics, and User Stories - that will allow Scrum team members to spend less time in unnecessary documentation and learn from experiences from similar work done earlier. This is especially beneficial when Scrum teams use similar implementation processes to create an identical category of products, for example, an advertising firm creating print advertisements for different clients; a construction firm creating drawings for similar road construction activities, etc.

It is important to note that if Scrum is implemented well in distributed teams by use of a proper Scrum Project Tool, it can provide significant benefits such as:

  • 24/7 working - as teams working in different time zones can speed up the delivery of Scrum projects.
  • Automation of reports, chats, calendars, workflows etc.
  • Enforcing similar guidelines across the organization by automating SGB recommendations.
  • Decreasing unnecessary and repetitive documentation through cloning from similar projects, Epics, and User Stories.
  • Working with a more diverse team (at times working from different countries) who bring in their own local perspectives and experience.
  • Lesser logistical challenges as compared to ensuring that all people work from one location. Saving time and cost on expenses related to travel, expensive work locations, etc.

It is important in distributed teams to pay special attention to the Principles of Scrum to ensure that they are followed even in Distributed teams. Emphasis should be on the ability to work collaboratively and transparently in an environment of trust.          

 

Previous
Introduction