Waterfall, DAD, SAFe, LeSS, and Scrum@Scale: A Comprehensive Comparison

Overview

When it comes to software development in more traditional business settings, project managers usually turn to the waterfall methodology as their go-to framework. However, there are several frameworks available for implementing agile principles on a larger scale, such as Disciplined Agile Delivery (DAD), Scaled Agile Framework (SAFe), Large Scale Scrum (LeSS), and Scrum@Scale. These frameworks cater to diverse organisational objectives, providing a variety of techniques and resources that can enhance efficient and agile performance.

Waterfall

The Software Development Life Cycle Model (SDLC), commonly referred to as the Waterfall Methodology, is a conventional software development approach where the development process progresses sequentially from one phase to the next. This methodology prohibits any overlap between the phases, necessitating the fulfilment of all entry criteria for the subsequent phase and the satisfaction of all exit criteria for the previous phase before it can begin.

The six life cycle stages of the initial waterfall model are:

1. Requirements:

   In this phase, the project’s objectives and expectations are thoroughly defined, and the requirements associated with them are meticulously scrutinized and documented. A business analyst typically carries out this task. The requirements are reviewed and validated before proceeding to the next phase.

2. Design:

   After obtaining approval for the requirements, the product is designed and constructed to meet the specified criteria. A software architect or designer is responsible for documenting the physical and component architecture, database functionalities, and detailed design aspects of each component and module. Once the design is complete, it must undergo review and approval before the implementation phase can commence.

3. Implementation:

   Following the design approval, software developers implement or code the software in accordance with the requirements and design.

4. Verification:

   After the software has been implemented, the Quality Assurance (QA) team conducts comprehensive tests to ensure that it meets the approved requirements and design guidelines while maintaining a high level of quality. During the testing phase, any identified defects are documented and closely examined to determine the required corrective measures.

5. Release and maintenance:

   After thoroughly testing and debugging the software, it is released to the client and installed. To guarantee a successful installation, the product undergoes additional rounds of testing. Once it has been deployed, regular maintenance and support are provided to ensure that it remains operational and fully functional.

Advantages of the Waterfall Model

The Waterfall methodology, although beneficial in specific scenarios, may not be appropriate for longer and more intricate projects due to its inherent limitations. It is best suited for short-term projects with relatively stable and predetermined requirements and technology that is unlikely to undergo significant modifications. Although it offers advantages such as improved predictability and documentation, it is not appropriate for projects with volatile or continuously changing requirements or those with rapidly evolving technology.

The use of the waterfall model for suitable projects offers several benefits, including:

• Simplicity:

  The Waterfall model is easy to implement because it defines the project scope upfront and follows a structured series of phases with a distinct transition from one to the next.

• Visibility:

  With the Waterfall model, stakeholders can accurately anticipate and evaluate the project’s requirements from start to finish and monitor the progress of each stage as it is completed.

• Documentation:

  The Waterfall model allows for thorough documentation and planning of the project scope and requirements, which can facilitate the involvement of less experienced teams in the project.

• Work in stages:

  With clearly defined roles and distinct phases, resources can be allocated to other projects during periods when a given project phase is not being actively worked on.

Disadvantages of the Waterfall Model

The Waterfall methodology is unsuitable for longer projects, especially in cases where the requirements are unclear or prone to change frequently, and/or where there is a significant level of technical ambiguity. This is especially true in the rapidly evolving field of software development, where market conditions are always in flux and time-to-market is critical.

The Waterfall model has several drawbacks, with its most significant limitation being its incapacity to accommodate change.

• Monolithic scope:

  The Waterfall model encourages stakeholders to contemplate every potential aspect when defining the project’s scope, resulting in an all-encompassing scope.

• Late client feedback:

  It can be difficult for stakeholders, particularly clients, to have a complete and detailed comprehension of a project’s scope. With the Waterfall methodology, project outcomes are primarily revealed to clients at the end, making it challenging to incorporate client feedback at such a late stage of the project.

• Changes in Requirements:

  In longer projects, market conditions often change, leading to shifts in project goals and requirements during the project lifecycle.

• Added value at the end:

  The Waterfall model necessitates significant upfront work, resulting in delayed value creation until later stages of the project.

• Interdependence of phases:

  Incorporating changes regularly can necessitate modifications to the requirements or design, which, in turn, can have an impact on other project components. It’s important to remember that later phases of the project depend on the accuracy of earlier ones, and even minor adjustments can be challenging to implement.

Disciplined Agile Delivery: DAD

IBM’s Scott Ambler and Mark Lines created Disciplined Agile Delivery (DAD) as an expansion of agile and Scrum methodologies. DAD acknowledges that, when delivering software projects, non-agile organisational components are frequently involved in some capacity. The framework incorporates IT operations, enterprise architecture, portfolio management, finance, and procurement activities throughout the entire delivery process. The primary goal of DAD is to establish a more practical and effective agile business environment.

Principles and Components of DAD

ROLES

Disciplined Agile Delivery (DAD) has a more comprehensive approach to team roles than Scrum, and these roles are divided into two categories. Primary roles are filled by personnel who are actively engaged in ongoing project work, while secondary roles are brought in as required to provide additional support and scalability when necessary. DAD’s inclusive approach to team roles reflects the reality of most projects, in which some team members provide ongoing support and guidance, as well as temporary and supporting roles that are critical to successful project delivery.

Main Responsibilities:

1. Stakeholder:

   An individual who depends on your team to complete the project, such as a client, end-user, or internal colleague.

2. Team Members:

   Individuals on the project team who perform the planned work, such as developers, designers, testers, and others.

3. Team Lead:

   The team lead acts as a servant-leader, functioning as a scrum master and proactively dealing with any impediments that could prevent the team from meeting their objectives. Additionally, they seek to strengthen the team’s cohesiveness and emphasise the importance of agile values.

4. Product Creator:

   The product owner, also known as the “voice of the customer,” represents stakeholders and maintains a prioritised list of work that must be completed.

5. Architecture Owner:

   This position is held by a senior developer who is responsible for mitigating large-scale architecture risks. It necessitates a solid technical foundation as well as a thorough understanding of the business domain.

Additional Responsibilities:

1. Specialist:

   Individuals who join the project team temporarily to contribute their specialized skillset to a particular project are referred to as temporary staff. For instance, a data analyst may be recruited in the initial stages of the project to provide research support, ensuring that the project is launched with the most precise and up-to-date information available.

2. Domain Authority:

   Tax consultants, legal counsel, and other subject-matter experts who assist the team with domain-specific issues.

3. Field Expert:

   As an organisation expands and its requirements become more intricate, specialized roles become critical to ensuring optimal software development and deployment. Database Administrators, Security Specialists, and Build Masters, to name a few, are essential in providing invaluable assistance to the more generalised team members across the software’s life cycle, from design and development to deployment and maintenance. These professionals have a wealth of knowledge and experience in their respective fields, and as such, are crucial to the successful execution of software projects.

4. Independent Examiner:

   Although testers are typically integrated into the main team, there are situations where independent testers are employed in parallel to verify and deliver work. This additional level of validation is sometimes necessary for intricate systems or strict regulations.

5. Integrator:

   When working on different components of a larger system, teams are responsible for integrating their work with the overall system. An integrator is a crucial figure who assists the team in integrating their component with the entire system and managing any dependencies that may arise during the process.

Supporting the Software Lifecycle

The Disciplined Agile Delivery (DAD) framework proposes a complete delivery lifecycle that includes all phases of a project from initiation to retirement. The lifecycle is bolstered by six distinct models that cover the programming and release phases addressed by agile/scrum, as well as the inception phase where the project vision is established and approved. Furthermore, DAD also supports the support and retirement phases after the project has been released.

• Agile Lifecycle: A Project Lifecycle Based on Scrum
• Lean Lifecycle: A Project Lifecycle Based on Kanban
• Continuous Delivery: An Agile Lifecycle
• Continuous Delivery: A Lean Lifecycle
• Exploratory (Lean Startup) Lifecycle
(no need to rephrase as it has only the term in brackets)
• Program Lifecycle for a Group of Teams

The disciplined agile delivery (DAD) framework acknowledges that various teams may encounter different work styles, levels of organisational agility, and other circumstances. Consequently, it provides a set of suggested lifecycles that can be customised to meet the needs of specific teams or organisations. Even though the DAD framework emphasises the significance of being pragmatic rather than entirely adhering to an existing process, it is critical to recognise that each situation is distinct and should be handled accordingly.

Objectives of the Process

The Development and Adaptation Division (DAD) utilises an agile, goal-oriented methodology that involves identifying the 21 most frequently encountered processes by teams during their lifecycles. This approach enables them to efficiently develop and personalise processes that meet the requirements of the specific project.

To properly organise the process, the team must make documented decisions at every stage. For instance, the image below demonstrates the “Develop Common Vision” process, which necessitates six decisions. To aid in the decision-making process, there are two to five suggested actions for each decision, which are listed in order of best practice to worst practice. The authors have highlighted the best practices in bold italic font to provide guidance to new teams starting with DAD.

DAD Scaling

Disciplined Agile Delivery approaches scaling from two perspectives:

• Operational Agility at Scale
• Strategic Agility at Scale

Tactically agile practices seek to address the various scaling factors that individual teams may encounter, such as team size, geographical distribution, and project complexity. This can be accomplished by applying the appropriate processes, goals, and suggested practices to each situation.

Strategic agility is an approach that seeks to address scaling challenges by employing agile and lean strategies throughout the entire organisation. This approach expands the framework to cover various components of the organisation, allowing for increased flexibility and responsiveness to changing conditions. By adopting a comprehensive approach to agile and lean strategies, organisations can more effectively adapt to changing markets, customer demands, and technological advancements.

• Disciplined DevOps: focuses on employing DevOps to deliver more efficient outcomes to an organisation
• Disciplined Agile IT (DAIT): focuses on applying agile and lean strategies to all areas of IT
• Disciplined Agile Enterprise: focuses on implementing lean and agile principles across an organisation

SAFe

The Scaled Agile Framework (SAFe) is presently the most extensively utilised framework for scaling Agile processes, and is widely regarded as the most comprehensive and intricate. According to the Annual State of Agile Report, 29% of respondents stated the use of this framework in their organisations. As a result, there is a considerable demand for project managers who are knowledgeable about SAFe methodology.

In 2007, Dean Leffingwell authored the book “Scaling Software Agility: Best Practices for Large Enterprises,” which served as the inspiration for the creation of the Scaled Agile Framework (SAFe). Leffingwell presently serves as SAFe’s Chief Methodologist, though the framework’s development and upkeep are the result of a cooperative effort from numerous individuals. Presently, SAFe has advanced into a comprehensive software product, with a version of 4.6, and designed with retroactive compatibility and modular components.

Core Principles and Components

The Scaled Agile Framework (SAFe) aims to foster the formation and progression of a Lean Enterprise. This is necessary because many businesses, to some extent, rely on software solutions to fulfil their goals and require the ability to provide value effectively and durably. SAFe’s mission is to empower organisations to realise this objective as swiftly and reliably as possible.

SAFe for Lean Enterprises aspires to create a Lean Enterprise by providing a repository of established principles, competencies, and best practices.

Scaled Agile Framework (SAFe) 4.6 defines five primary competencies that, when united, equip organisations with the means to attain excellence. These competencies consist of pertinent information, abilities, and behaviours that are essential for organisational success. By acknowledging and enhancing these core competencies, organisations can enhance their general efficiency and performance.

1. Agile-Lean leadership

   details how leaders encourage and maintain organisational change by comprehending, teaching, and implementing the Lean-Agile mindset as instructed by SAFe.

2. Technical agility and teamwork:

   Outlines the skills, values, and methodologies necessary to form high-performing Agile teams.

3. DevOps and on-demand release

   elaborates on how incorporating DevOps and a continuous delivery pipeline allows organisations to issue product increments promptly to fulfil demand.

4. Lean systems engineering and business solutions

   highlights how to implement lean-agile principles and practices to define, create, implement, and enhance large, complex software applications.

5. Lean portfolio management

   Through the application of Lean and Systems Thinking approaches to strategy, investment funding, and agile portfolio operations, as well as the implementation of governance, we can ensure that our strategy and execution are appropriately aligned.

Aside from Lean-Agile Leadership, which encompasses the entire process, each core competency can be easily identified and linked to its corresponding level in the SAFe process diagram.

LEAN-AGILE LEADERSHIP COMPETENCE

The key aim of the Lean-Agile Leadership Competency is to facilitate the organisation’s evolution into a lean-agile enterprise. This is accomplished by examining, executing, and disseminating SAFe’s Lean-Agile mindset, fundamental principles, methodologies, and practices. In doing so, the organisation can reap the rewards of enhanced efficiency, better performance, and heightened enterprise agility that come with the adoption of a lean-agile approach.

The Core Values of Scaled Agile Framework (SAFe) are crucial in advancing successful Lean Enterprise transformations. It is crucial for leaders to actively advocate for these values at every chance to guarantee their success. Here are the Core Values of SAFe:

1. Alignment

   Convey the mission’s objective, the portfolio’s strategy, and the solution’s vision to the appropriate stakeholders. Contribute to program increment (PI) planning and backlog upkeep, as well as any relevant briefings.

2. Transparency

   Represent all relevant work visually.

3. Integral quality

   Integrating quality-delivery practices throughout the entire project life cycle is vital. We must not accept any substandard work but instead should encourage investing in maintenance and decreasing technical debt.

4. Execution of the program

   As a business owner, taking an active role in executing Performance Improvement (PI) plans is crucial to maximize the organisation’s potential benefits. It is essential to ensure that the plan’s scope aligns well with the organisation’s current demand and capacity, and to address obstacles and dishearteners promptly and resolutely.

Embracing the Lean-Agile Mindset and implementing SAFe Principles reinforce the SAFe core values:

1. Take the economic situation into account.
2. Apply systems thinking.
3. Anticipate variability and maintain flexibility.
4. Build incrementally through rapid, integrated learning cycles.
5. Milestones must rely on an objective assessment of functioning systems.
6. Visualize and limit work in progress (WIP), decrease batch sizes, and manage queue lengths.
7. Establish a cadence and synchronize with cross-domain planning.
8. Unleash the intrinsic motivation of knowledge workers.
9. Decentralize decision-making.

These principles are akin to those of Lean and Agile methodologies, and implementing the SAFe Implementation Roadmap ultimately transforms the organization.

COMPETENCE IN TEAM AND TECHNICAL AGILITY AT THE TEAM LEVEL

The Team and Technical Agility Competency defines the knowledge, principles, and methods necessary to establish effective and efficient agile teams that deliver high-quality, dependable outputs. This competency emphasizes two crucial elements: promoting collaboration and communication among team members, and utilizing adequate tools and techniques to ensure successful task execution. Additionally, the competency involves the ability to track progress, offer feedback, and make modifications to plans as needed to accomplish the team’s aims and objectives.

• Team adaptability:

  Agile practices and principles are consistently used by teams to work, learn, and adapt.

• Technical dexterity:

  Agile technical teams emphasize code quality and maintainability. To ensure such quality is achieved, teams utilize Agile engineering techniques such as Behaviour Driven Development (BDD) and Test-driven Development (TDD). Implementing such techniques enhances workflow, but it is crucial to maintain system quality to achieve a rapid and efficient flow. Failure to do so may result in setbacks and production delays.

The Team Level of the Scaled Agile Framework (SAFe) outlines the functioning of individual Agile teams. A group of collaborating teams that deliver a Product Increment make up an Agile Release Train. Typically, the conventional Agile/Scrum methodology is followed, and teams carry out iterations to create functional systems. SAFe utilizes the roles of scrum master, product owner, and team member, along with most of the scrum activities and artifacts. Program-level positions such as Product Management, System Architect, and other shared services provide support to the teams. Kanban is utilized to visualize the flow of features throughout the delivery lifecycle and the interactions and handoffs between teams.

COMPETENCY/PROGRAM LEVEL OF DEVOPS AND ON-DEMAND RELEASE

The DevOps and On-Demand Release Competency highlights that companies that adopt DevOps and continuous delivery strategies can leverage the ability to provide value to their target customers whenever needed. This adaptability enables them to meet and surpass customer expectations, resulting in a competitive edge in the market.

DevOps aims to bring together development, operations, business, and other components to achieve concrete business results. Although not all organizations may require the same frequency of releases as some of the most established companies in the DevOps industry, such as Amazon, who releases every few seconds, all organizations must be capable of releasing their products or services as required.

• DevOps is a Culture, Automation, Lean-flow, Measurement, and Recovery (CALMR) approach that facilitates on-demand release and continuous delivery.
• Agile Release Trains (ARTs) are clusters of agile teams that collaborate to deliver value on demand using a continuous delivery pipeline.

The Program Level of the framework illustrates the roles and activities required to achieve continuous delivery through an Agile Release Train (ART). This level follows an iterative approach that is similar to the team level, but involves more iterations and numerous agile teams. An ART consists of 5 to 12 teams (50 to 125 individuals) that include both traditional agile roles and key program roles, such as a Release Train Engineer (RTE) and a Product Manager. ARTs are delivered through 8-12 week Program Increments (PIs) that are planned and driven by a Product Manager.

To monitor and oversee the progress of Program Increment (PI) features, epics, and other items, a Program Kanban board is utilized. In the Agile Release Train (ART), the Release Train Engineer (RTE) serves as the Scrum Master. Regular coordination meetings include Daily Standups, Scrum-of-Scrums (RTE and Scrum Master) meetings, Product Owner (PO) Synchronization (Product Management and PO), and ART Synchronization. Each PI is responsible for a System Demonstration and a Retrospective.

COMPETENCY IN BUSINESS SOLUTIONS AND LEAN SYSTEMS ENGINEERING/LARGE SOLUTIONS LEVEL

The Business Solutions and Lean Systems Engineering Competency suggests that Lean-Agile principles and practices can be implemented throughout the entire lifecycle of large, intricate software applications and cyber-physical systems, from specification to development, deployment, and evolution. By adopting such practices, organizations can enhance their efficiency, effectiveness, and customer satisfaction.

Apart from adhering to the SAFe principles, the following eight principles are crucial to this competency when working on large solutions:

At the Large Solutions Level, the roles, artifacts, and processes required to build significant and complex solutions can be determined. The collaborative efforts of multiple Agile Release Trains (ARTs) are essential to ensure the successful delivery of solutions. The primary objectives of this undertaking include:

• Manage frequent integration
• Continuously deal with compliance concerns
• When designing, consider scalability, modularity, releasability, and serviceability.

The Solution Train Engineer (STE) offers leadership and guidance to the work of Solution Management, responsible for ensuring that the Solution content meets the applicable standards. The Solution Architect ensures that all Agile Release Trains (ARTs) are properly architected. Successive Program Increment (PI) planning, both pre and post, is employed to facilitate the delivery of Solutions. The progress of Capabilities and Solution Epics is tracked using a Solution Kanban board, which constitutes the Solution Backlog.

COMPETENCY IN PORTFOLIO LEVEL / LEAN PORTFOLIO MANAGEMENT

The Lean Portfolio Management Competency is intended to align strategies with execution effectively. By adopting a Lean and systems thinking approach to strategy, investment funding, agile portfolio operations, and governance, this goal is achieved. With this competency, organizations can guarantee the proper execution of their strategies, and investments are maximized for utmost return.

The following are the primary focuses of Lean Portfolio Management:

1. Strategy and Investment Funding: creates a connection between the portfolio and enterprise strategies, funds value streams, and establishes portfolio flow.
2. Agile Portfolio Operations: coordinates value streams, aids in program execution, and seeks to achieve operational excellence.
3. Forecasting budgets, measuring portfolio performance, and enforcing compliance are key aspects of lean governance.

The Portfolio Level covers the principles, practices, and obligations necessary to initiate and oversee a set of development Value Streams. Business Epics and Enabler Epics are used to create a Portfolio Backlog, which is tracked via a Portfolio Kanban* board. Lean Portfolio Management (LPM), which involves the most influential individuals in an organization, is employed to determine which Value Streams are included in a portfolio. The work performed across all Value Streams is supervised and coordinated by an Enterprise Architect.

LeSS

Large-Scale Scrum (LeSS) was developed by Craig Larman and Bas Vodde, who have extensive experience in the financial and telecommunications sectors. This framework is founded on the idea that the successful expansion of Scrum teams necessitates minimal processes and procedures to promote collaboration, making the scaling process simple. Often, involving people can make this process overly complicated.

Essential Principles and Components

Large-Scale Scrum (LeSS) is an application of Scrum principles to multiple teams working on a single product. It is based on the ten fundamental principles of Lean-Agile, which are widely recognized within the Lean-Agile methodology. These principles include a focus on customer value, continuous improvement, leadership at all levels, and team self-organization. Collaboration, team-level planning and learning, and the creation of cross-functional teams are all emphasized in the implementation of LeSS. By leveraging agility at scale, organizations can speed up the delivery of high-quality products.

1. LeSS is fundamentally Scrum
2. Empirical process control
3. Transparency
4. Doing more with fewer resources
5. Product focus
6. Customer-centric
7. Continuous improvement leads to perfection.
8. Systems thinking
9. Adopt a lean mindset.
10. Queuing theory

LeSS, like Scrum, has only two primary roles:

1. Product Owner

   – a role filled by a group of 2-8 people at Works

2. Scrum Master

   – a role held by a group of 1-3 individuals at Works

In LeSS, teams work in 1-4 week sprints and share the same product backlog. This collaborative approach ensures synchronization between the start and end of each sprint. At the end of each sprint, the teams join forces to deliver a product increment. Although managing 8 teams may seem overwhelming for a single Product Owner, LeSS tackles this by empowering teams to take responsibility for clarifying product backlog items. This is achieved by fostering cross-functional teams with the ability to code, design, test and understand the business domain. Teams are also given the authority to communicate with customers in order to succeed.

Sprint Planning

Planning is separated into two parts:

1. Sprint Planning 1

   – During this session, representatives from each team meet with the Product Owner to prioritize backlog items for the upcoming sprint and identify opportunities for inter-team collaboration.

2. Sprint Planning 2

   – Each team follows the traditional Scrum approach of meeting separately to devise a strategy for completing backlog items.

Product Backlog Refinement

Product Backlog Refinement (PBR) can be conducted during a Sprint to prepare Product Backlog Items for Sprint Planning. The LeSS framework does not provide any fixed rules for PBR, but encourages organizations to identify a process that suits their needs. Typically, PBR involves three pivotal activities:

1. Breaking down large items into smaller ones.
2. Elaborating on items until they are ready.
3. Estimating.

Sprint End

At the end of each Sprint, three things take place:

1. Sprint Review

   – Teams and customers come together for a Sprint demo to discuss what was achieved during the Sprint and identify the next steps.

2. Retrospective

   – Each team conducts a retrospective to identify areas for process improvement.

3. Overall Assessment

   – Teams, Product Owners, and Scrum Masters collaborate to examine and enhance organizational practices.

Scrum@Scale™

Scrum@Scale and Scrum at Scale are interchangeable terms coined in 2014 by Jeff Sutherland, the originator of the Scrum methodology and a signatory of the Agile Manifesto. This methodology has gained widespread recognition since its introduction and continues to be effectively employed as an approach to project management in numerous organizations.

Scrum@Scale is a meta-framework that expands upon the core principles of Scrum and presents a simple, agile structure for scaling Scrum with minimal overhead. It offers an approach to tackle scaling issues and related areas while limiting bureaucracy. This framework is less prescriptive than other well-known scaled Agile methodologies, and instead emphasises a mental model to assist practitioners in scaling effectively.

Key Principles and Components

Scrum@Scale is a framework that utilises the fundamental concepts of Scrum to enable organizations to scale their implementation of the methodology. By distinctly outlining the responsibilities of the Product Owner and the Scrum Master, Scrum@Scale guarantees that roles and responsibilities are clearly defined, thereby reducing inefficiencies and preventing conflicts.

Scrum@Scale employs two separate cycles to differentiate roles and responsibilities: the Scrum Master cycle and the Product Owner cycle. Both cycles have two points of interaction – Team Level Process and Product Release Feedback. These two processes help all individuals involved in the Scrum@Scale initiative work together effectively and accomplish necessary tasks to achieve the desired outcomes.

Scrum Master Cycle

The Scrum Master Cycle determines the most efficient way to construct the items established by the Product Owner Cycle. Each Scrum Team in the Scrum@Scale framework has the same roles, artifacts, activities, and ceremonies as in a typical Scrum environment.

Scrum Teams may be arranged into Scrum of Scrums (SoS) to create a unified product increment. In this process, they attend combined backlog grooming and prioritization meetings, hold retrospectives, and keep impediment backlogs updated. Additionally, they conduct a Scaled Daily Scrum (SDS) (similar to the regular daily scrum) to coordinate between teams and eliminate any roadblocks. To ensure the process’s success, each participating team must send at least one representative (usually the team’s Scrum Master) to the SDS, supervised by the Scrum of Scrums Master (SoSM). The SoSM is responsible for coordinating with the Scrum Teams and the Product Owners.

If additional scaling is required, a Scrum of Scrums (SoS), comprised of several SoS, may convene daily. The Executive Action Team (EAT) is the principal entity responsible for promoting agility throughout the organization and arranging Scrum teams as necessary. Furthermore, the EAT functions as the final authority for removing any and all impediments.

Product Owner Cycle

The Product Owner Cycle determines which products and services will be developed and all the tasks necessary to support them. Product Owners are assigned to Scrum teams and fulfil their allocated responsibilities in the Scrum framework. Product Owners are organised into Product Owner Teams and aligned with SoS teams. Product Owner Teams hold daily Meta Scrums to review the teams’ overall strategy and collaborate with the corresponding SoSMs, other Product Owners, and stakeholders as necessary. Meta Scrums are led by a Chief Product Owner.

Product Owners are in charge of scaling their activities based on the organisation’s size. This process ultimately results in the creation of an Executive Meta Scrum (EMT). The EMT is responsible for determining the most important company-wide objectives.

Implementation of Scrum@Scale

The first step in implementing Scrum@Scale is to create a scalable reference model with a limited number of teams utilising Scrum on a smaller scale. This is necessary to address any organisational policies and development processes that may impede agile development. It is advisable to resolve these issues at this stage since similar difficulties are likely to exist across the organisation, and the resulting discontent could impede agile adoption. The reference model may be used as a blueprint for scaling Scrum to other teams and departments.

To begin implementing the reference model, it is crucial to establish an Executive Action Team (EAT). This team should consist of individuals with political and financial influence in the organisation and the ability to make changes to organisational policies.

Summary

In the second section of the project management blueprint, we have examined some of the most commonly used frameworks for complex projects and programs. While Waterfall is still widely used in many organisations, its inflexible rules and procedures make it less appropriate for small projects with a clear scope that are unlikely to change.

As companies face increasingly complex projects that entail continually changing requirements and objectives, many are turning to Agile approaches as a viable solution. Although Agile was initially designed for use by small teams of 5-9 individuals, various Agile practitioners have adapted it for use in larger, more extensive settings. This article explored several of these solutions, including Disciplined Agile Delivery (DAD), Scaled Agile Framework (SAFe), Large Scale Scrum (LeSS), and Scrum@Scale.

In the final section of the project management blueprint, we will discuss various project management frameworks, such as Project Management Professional (PMP) and PRINCE2. We will also investigate innovative frameworks and processes, such as “jobs to be done” (JTBD) and “design thinking,” to gain a thorough understanding of how they can be applied in project management.