Agile Project Management with Scrum

Methodology

Scaling Method Comparison

PGMT 570

Submitted by: Pratik Baheti

Date – 6/10/2023

1
CONTENTS

Introduction.................................................................................................................................................................3
LeSS (Large Scale Scrum)..............................................................................................................................................3
Nexus........................................................................................................................................................................... 5
SAFe (Scaled Agile Framework)....................................................................................................................................7
References................................................................................................................................................................. 10

2
INTRODUCTION

Various scaling frameworks are available for the enterprises to use. However, the most widely

used frameworks are Scaled Agile Framework (SAFe), Scrum@Scale (SaS), Scrum of Scrums

(SoS), Large Scale Scrum (LeSS), Nexus, Disciplined Agile (DA), Enterprise Kanban. While

most of the features in these frameworks are similar, they differ on Roles, processes and artifacts.

LESS (LARGE SCALE SCRUM)

LeSS extends the fundamentals of scrum to larger enterprises. It is an agile scaling framework

that focuses on a simple, centralized cohesive product development team.

Roles in LeSS – LeSS retains the core Scrum roles of Product Owner, Scrum Master, and

Development Team. Furthermore, in LeSS, there is typically one Product Owner for the entire

group of teams, and each team has its own Development Team and Scrum Master.

1. Product Owner: In LeSS framework, Product owner’s role is maximizing the value of

product(s) being developed by the teams. PO should cross-collaborate with different

stakeholders and manage the product backlog to nurture priorities and share product

vision.

2. Scrum Master: Like traditional Scrum framework in LeSS, Scrum Master serves as

servant-leader for the teams. There can be one or more scrum masters shared between

teams. Scrum Master role is to remove any obstacles, facilitate the adoption of scrum

and coach the teams on self- organization and ensure that there is continuous

improvement.

3
 3. Development Teams: In LeSS, the Development team consists of individuals who

coordinate with each other with an aim to deliver the potentially shippable product

increments. These individuals are self-organizing and are responsible for all aspects of

product development like design, testing, coding, analysis, and documentation.

Processes – LeSS follows the Scrum framework, including Sprint Planning, Daily Scrum, Sprint

Review, and Sprint Retrospective. The only difference is that LeSS extends these processes to

accommodate multiple teams. They do this by introducing the Overall Retrospective, where

representatives from different teams come together to identify systemic improvements.

1. Sprint: In LeSS, work is broken into time-boxed iterations like the traditional scrum

called Sprints. These are 2-4 weeks long.

2. Sprint Planning – In LeSS, Sprint planning focuses on the collaboration between the

development team and product owner to identify what work needs to be done and

determine the goal. Teams as a result have shared a sprint backlog.

3. Daily Scrum - The Daily Scrum in LeSS is where development teams meet daily to discuss

progress and any challenges they have on the way.

4. Sprint Review: This is a feedback session where teams present work to the stakeholders

and inspect increment and modify product backlog based on the inputs.

5. Sprint Retrospective: The Sprint retrospective is a dedicated time to reflect on how to

improve working style.

4
Artifacts – LeSS maintains the core Scrum artifacts, such as the Product Backlog, Sprint Backlog,

and Increment. However, it emphasizes the importance of a single Product Backlog for all

teams, ensuring transparency and shared understanding of the product vision and priorities.

1. Product Backlog: In LeSS, The Product Backlog backlog is centralized list of prioritized

requirements for the entire product and teams. This includes features, user stories etc.

that deliver value to the customers. Product Owner is responsible for prioritizing and

managing product backlog.

2. Sprint Backlog: Teams in LeSS have their own sprint backlog which is the subset of

product backlog. Development teams work together on tasks in sprint backlog.

3. Increment: The sum of all the tasks completed from sprint is called increments. Each

sprint should be a value addition to the shippable product.

NEXUS

Nexus extends the Scrum framework to various teams that are working on a single product or

project. Nexus is the framework for integration, collaboration, and scaling agile practices

effectively. This also means removing impediments and promoting collaboration.

Roles in Nexus –

1. Product Owner – The only difference between the Product Owner role of LeSS and

Nexus is that product owners from different teams can collaborate representing

different teams.

5
 2. Scrum Master – Apart from managing all the roles and responsibility of the Scrum

Master role in LeSS and SAFe. The only difference here is that Scrum master also

collaborates with the Nexus integration team. In Nexus, there is a designated role of the

Nexus Scrum Master, who works closely with the individual Scrum Masters to address

cross-team dependencies and facilitate collaboration. LeSS, however, does not

introduce any new role specifically for scaling purposes, and individual Scrum Masters

handle coordination within the organization.

3. Development Team: Dev teams work closely with others to align and collaborate to

deliver the product increments.

4. Nexus Integration Teams: The nexus integration team has representatives from each

development team. Their focus is to understand the dependencies between teams and

resolve them. They remove any obstacles that hinder team collaboration and

communication.

Processes – Nexus builds upon the Scrum framework and introduces specific processes to

facilitate integration and collaboration across multiple teams. It includes events such as Nexus

Sprint Planning, Nexus Daily Scrum, and Nexus Sprint Review. These events aim to synchronize

the work of different teams, manage dependencies, and ensure integration of increments.

1. Nexus Sprint Planning: Meeting organized to discuss Nexus Goal, determine

dependencies, select, and commit to the product backlog items and integration points is

called nexus sprint planning.

6
 2. Nexus Daily Scrum: This is a coordinated meeting by the representatives from each

development team. Like LeSS, objective is to share information and address any

challenges or concerns.

3. Nexus Sprint Review: In Nexus Sprint review the only difference apart from LeSS and

SAFe is that the review session is conducted by all the teams to gather feedback.

4. Nexus Sprint Retrospective: This is the improvement session for the Nexus where

teams discuss Nexus-wide process and prepare improvement plan.

Artifacts – Nexus maintains the core Scrum artifacts, including the Product Backlog, Sprint

Backlog, and Increment. However, it introduces the Nexus Sprint Backlog, which represents the

combined work of multiple teams. The Nexus Sprint Backlog is used to track dependencies,

synchronize efforts, and ensure the delivery of an integrated increment.

Nexus places a strong emphasis on addressing integration and dependencies among multiple

teams, while LeSS focuses more broadly on scaling Scrum principles to large-scale product

development.

LeSS encourages a single-team mindset, advocating for fewer, larger, and more self-organizing

teams whereas in Nexus teams work within a single Nexus integration Team.

SAFE (SCALED AGILE FRAMEWORK)

SAFe has additional roles to support scaling Agile practices. It includes roles such as Release

Train Engineer (RTE), Solution Architect, Product Manager, and System Team. SAFe also

7
incorporates various levels of management, including Agile Teams, Agile Release Trains (ARTs),

and the portfolio level.

Roles in SAFe

1. Program Level:

Release Train Engineer (RTE): The RTE role is to enable Agile Release Train (ART), by

simplifying, aligning, and cross-collaborating among agile teams.

System Architect: System engineer role is to define technical standards, provide

architectural guidance and support development teams in developing scalable and

shippable solutions that can be delivered.

Product Manager: Product owner defines vision, prioritize features to maximize

business value. They are responsible for communicating the requirements from

customers and stakeholders to the development teams.

2. Team Level:

Agile Team – Agile teams consist of 5-9 members and follow agile practices. These are

cross-functional, Self-organizing teams responsible for delivering value.

3. Portfolio Level:

Portfolio Manager: Their responsibility is to align the business strategy with portfolio

execution of services and products.

Lean Portfolio Management: Their job is to provide strategic guidance, budgeting and

aligning organization with the strategic goals.

4. Large Solution Level:

8
 Solution Train Engineer (STE) : They facilitate the coordination between multiple ARTs,

manage risks and align dependencies at the level of large organizations.

Solution Architect: Their job is to ensure technical integrity of the solution by defining

and communicating architectural vision.

Processes – SAFe introduces additional processes to coordinate work across teams and levels. It

includes the Program Increment (PI) Planning, where teams collaboratively plan their work for a

fixed timebox (PI). SAFe also includes processes like System Demo, Inspect and Adapt, and

Scrum of Scrums, which facilitate alignment and coordination at the program and portfolio

levels.

1. Agile Release Train (ART): ART typically runs for 8-12 weeks in a cadence known as

Program increments (PI). Agile teams that plan and deliver value together in the form of

ART as primary value delivery in SAFe

2. Program Increment Planning: Like Scrum and Nexus planning in LeSS and Nexus

respectively, PI planning is the main planning event in SAFe. Teams come together to

discuss the next PI and align on the goals, features and create a whole plan.

3. Inspect & Adapt (I&A): In I&A as name suggest teams come together to review, give

demo, solve problems, and identify and resolve cross team dependencies.

4. Scrum of Scrums (SoS): Representatives from different agile teams coordinate their

work and ensure alignment between the requirements and the final deliverables.

5. Portfolio Kanban: To manage the flow of PI and epics, SAFe incorporates Kanban

Principle at the portfolio level. This helps in visualizing and optimizing work stream.

9
Artifacts – SAFe extends the traditional Scrum artifacts by introducing additional artifacts for

higher-level planning and coordination. These include the Program Backlog, Solution Backlog,

and Portfolio Backlog. SAFe also emphasizes the use of the Program Increment (PI) Objectives

and the PI Roadmap to align teams and communicate business goals.

1. Program Backlog: Product backlog contains user stories, work items and features that

are prioritized by the product owner. This has all the requirements for ART and has

guidelines for the teams.

2. Solution Backlog: This represents non-functional requirements, enablers and features

that are required to deliver solutions and meet requirements for large and complex

projects. Solution backlog is managed by the STE and Solution Architect.

3. Portfolio Backlog: It is managed by Lean Portfolio Management and Portfolio Manager

whose role is to align the organizational objectives with the strategic initiatives and

epics

4. PI Objectives: PI objectives have clear goals and focus for the teams. ARTs should follow

it as target within program increment.

10
REFERENCES

Project Management Institute. (2017). A guide to the Project Management Body of Knowledge
(PMBOK guide) (6th ed.). Project Management Institute.

H. Edison, X. Wang, and K. Conboy, (2022) "Comparing Methods for Large-Scale Agile
Software Development: A Systematic Literature Review," in IEEE Transactions on Software
Engineering, vol. 48, no. 8, pp. 2709-2731, 1 Aug. 2022, doi: 10.1109/TSE.2021.3069039.

Schwaber K (2018) Nexus guide. The definitive guide to scaling scrum with Nexus: the rules of
the game. Scrum.org

Philipp Diebold, Anna Schmitt, and Sven Theobald. 2018. Scaling agile: how to select the most
appropriate framework. In Proceedings of the 19th International Conference on Agile Software
Development: Companion (XP '18). Association for Computing Machinery, New York, NY,
USA, Article 7, 1–4. https://doi.org/10.1145/3234152.3234177

Alqudah, M. (2017). A Review of Scaling Agile Methods in Large Software Development.

ResearchGate. Retrieved from
https://www.researchgate.net/profile/Mashal-Alqudah/publication/311916796_A_Review_of_Sc
aling_Agile_Methods_in_Large_Software_Development/links/58bc5de692851c471d5638f3/A-
Review-of-Scaling-Agile-Methods-in-Large-Software-Development.pdf

11