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


Project managers often rely on the waterfall methodology as the most widely used framework for software development in more traditional business settings. In contrast, there are various frameworks 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. Each of these approaches offers different methods and tools to help organisations achieve their objectives in an agile and efficient manner.


The Waterfall Methodology (also referred to as the Software Development Life Cycle Model (SDLC)) is a traditional approach to software development, in which the development process flows sequentially from one phase to the next. This approach does not allow for any overlap between phases, meaning that before entering the next phase, all the entry criteria for that phase must have been fulfilled and all the exit criteria for the previous phase must have been met.

The original waterfall model’s six life cycle stages are as follows:

  1. Requirements During this phase, the project’s expectations and objectives are clearly outlined and the associated requirements are carefully examined and documented. This task is typically undertaken by a business analyst. Before transitioning to the next phase, the requirements are reviewed and validated.
  2. Design Once the requirements have been approved, the process of architecting and designing the product to meet the established specifications can commence. A software architect or designer is responsible for documenting the physical architecture, component architecture, database design, detailed component and module designs, and any other relevant aspects of the design. Once this is complete, it must be reviewed and approved before the implementation process can begin.
  3. Implementation After the design is approved, software developers implement or code the software according to the requirements and design.
  4. Verification Upon the completion of the implementation process, the Quality Assurance (QA) team conducts comprehensive tests to guarantee that the software adheres to the established requirements and design specifications and maintains the expected level of quality. During the testing process, any detected defects are documented and further scrutinised to determine the necessary corrective actions.
  5. Release and maintenance Upon successful completion of testing and debugging, the product is released to the client and installed. To guarantee the successful installation of the product, a further round of testing is conducted. Once the product has been delivered, ongoing maintenance and support are provided to ensure that it remains in a functional and satisfactory state.

Waterfall Advantages

Waterfall methodology, while advantageous in certain situations, may not be suitable for longer, more complex projects due to its inherent limitations. This approach is best suited for short-term projects with clear and static requirements and technology that is unlikely to change significantly. Despite its advantages, such as greater predictability and ease of documentation, it is not well-suited for projects with ever-changing requirements or for those with rapidly evolving technology.

Some of the benefits of using the waterfall model for the right type of project include:

  • Simplicity Waterfall is simple to implement because it identifies the scope up front, has rigid phases, and a clear transition from one phase to the next.
  • Visibility As stakeholders are able to accurately anticipate the entirety of the project’s requirements before it begins and observe the development of each stage as it is completed, they can more effectively assess and evaluate the progress of the project.
  • Documentation The scope, requirements, and plans can be thoroughly thought out and documented, making it easier for less experienced teams to work on the project.
  • Work in stages: Due to the clearly defined roles and the transition between phases of the project, it is possible for project resources to be allocated to other projects during times when the primary phase is not being actively worked on.

Waterfall Disadvantages

Waterfall methodology is not suitable for longer projects, especially when the requirements are unclear and/or likely to change, and/or when there is a high level of technical uncertainty. This is especially true in today’s world of software development, where market conditions are constantly evolving and time-to-market is of paramount importance.

The waterfall model has several drawbacks, the most significant of which is its inability to adapt to change.

  • Monolithic scope: It encourages stakeholders to consider EVERYTHING when defining the project’s scope, resulting in a monolithic scope.
  • Late client feedback: It can be challenging for stakeholders, particularly clients, to have a comprehensive and detailed understanding of a project’s scope. The waterfall methodology of project execution reveals the outcomes of a project to clients mainly at the end of the project, making it difficult to incorporate client feedback into the project at that late stage.
  • Changes in requirements: In longer projects, market conditions, and thus project goals and requirements, are very likely to change during the project.
  • Added value at the end: Waterfall requires a significant amount of work up front, which means that value is not produced until late in the project.
  • Interdependence of phases: The regular incorporation of changes can often lead to a need for modifications to the requirements and/or design, which can then have a knock-on effect for other components of the project. It is important to bear in mind that later stages of the project are reliant on the accuracy of earlier stages, and even minor adjustments can be disproportionately hard to implement.

Disciplined Agile Delivery (DAD)

Scott Ambler of IBM and Mark Lines developed Disciplined Agile Delivery (DAD) as an extension of the agile and scrum methodologies. DAD recognises that when delivering a software project, non-agile components of the organisation are often involved in some capacity. This framework takes into account IT operations, enterprise architecture, portfolio management, finance and procurement activities across the entire delivery process. The main aim of DAD is to create a more agile business environment that is practical and effective.

Principals and Components


The Disciplined Agile Delivery (DAD) framework has a more comprehensive approach to team roles than Scrum, and these roles can be divided into two categories. Primary roles are those filled by personnel who are actively engaged in the project on an ongoing basis. Secondary roles, on the other hand, are brought in as needed to provide additional support and scalability to the team when needed. This comprehensive approach to team roles in DAD is designed to reflect the reality of the situation; while some team members provide on-going support and guidance, there are also many temporary and supporting roles that are necessary in order to ensure the successful delivery of a solution.

Primary responsibilities:

  1. Stakeholder: Someone who relies on your team to complete the project, such as a client, end-user, or internal colleague.
  2. Team members: Individuals on the team who carry out the planned work: developers, designers, testers, and so on.
  3. Team lead: The team lead serves as a servant-leader to the team, taking on the role of a scrum master and actively working to remove any impediments that may prevent the team from achieving their goals. In addition, they strive to enhance the team’s cohesion and emphasise the importance of agile values.
  4. Product creator: The product owner, also known as the “voice of the customer,” represents the stakeholders and keeps a prioritised list of work that needs to be done.
  5. Owner of the architecture: In this role, a senior developer is responsible for reducing architecture risks at a large scale. It requires a strong technical foundation as well as a deep understanding of the business domain.

Secondary responsibilities:

  1. SpecialistPeople who join the team on a temporary basis to contribute their unique skillset to a particular project are known as temporary staff. In the early stages of a project, for example, a data analyst may be brought on board to provide research support. This can help to ensure that the project is launched with the most accurate and up-to-date information available.
  2. Domain authority: Tax consultants, legal counsel, and other domain experts who assist the team with related challenges.
  3. Expert in the fieldAs an organisation grows and its needs become increasingly complex, specialised roles become essential in order to ensure the optimal development and deployment of software. Database Administrators, Security Specialists, and Build Masters are just a few examples of positions that provide invaluable support to the more generalised team members at points throughout the software’s life cycle, from design and development to deployment and maintenance. These professionals possess a wealth of knowledge and experience in their respective areas, and as such, help to ensure the successful completion of software projects.
  4. Independent examinerWhile testers are typically incorporated into the primary team, there are occasions when independent testers are utilised in parallel to confirm and deliver work. This is sometimes necessary due to stringent regulations or intricate systems that require an extra layer of validation.
  5. IntegratorAt larger scales, teams are responsible for working on separate components of the entire system. An integrator is an important figure who is responsible for helping the team to integrate the component with the entirety of the system and managing any dependencies that come up during the process.


The Disciplined Agile Delivery (DAD) framework advocates for a comprehensive delivery lifecycle that encompasses all stages of a project from inception to retirement. The lifecycle is supported by six distinct models that cover the programming and release phases that are addressed by agile/scrum, as well as the inception phase where the project vision is established and given approval. Additionally, DAD also supports the support and retirement phases after the release of the project.

  • Agile Lifecycle: A Scrum-based Project Lifecycle
  • Lean Lifecycle: A Kanban-based Project Lifecycle
  • Continuous Delivery: Agile Lifecycle
  • Continuous Delivery: Lean Lifecycle
  • Exploratory (Lean Startup) Lifecycle
  • Program Lifecycle for a Team of Teams

The disciplined agile delivery (DAD) framework recognises that different teams may encounter different work styles, levels of company agility, and other situations. As such, it offers a set of recommended lifecycles that can be tailored to the needs of a specific team or organisation. While the DAD framework emphasises the importance of being pragmatic over being purely adherent to an existing process, it is important to recognise that every situation is unique and should be handled accordingly.


The Development and Adaptation Division (DAD) employs an agile, goal-oriented methodology that entails the recognition of the 21 most commonly encountered processes by teams in the course of their life cycles. This approach allows them to effectively create and customise processes that meet the demands of the given project.

The team must make documented decisions at each stage of the process in order to effectively structure it. For illustration, the image below demonstrates the “Develop Common Vision” process, which requires six decisions. To assist with the decision-making process, there are two to five recommended actions for each decision, which are listed in order of best practice to worst practice. To provide guidance to new teams just beginning with DAD, the authors have highlighted the best practices in bold italic font.


Scaling is approached from two perspectives by Disciplined Agile Delivery:

  • Tactical agility at scale
  • Strategic agility at scale

Tactically agile practices aim to manage the different scaling factors that individual teams may face, such as team size, geographic distribution, and the complexity of the project. This can be achieved by applying the appropriate processes, goals, and recommended practices to each situation.

Strategic agility is an approach that aims to address the challenges of scaling by utilising agile and lean strategies throughout the entire organisation. This approach extends the framework to encompass different components of the organisation, allowing for greater flexibility and responsiveness to changing conditions. By taking a holistic approach to agile and lean strategies, organisations can more easily adapt to changing markets, customer demands, and technological advances.

  • Disciplined DevOps: covers the use of DevOps to provide more effective results to an organisation
  • Disciplined Agile IT (DAIT): covers the application of agile and lean strategies to all aspects of IT
  • Disciplined Agile Enterprise: covers how to apply lean and agile principles throughout an organisation


The Scaled Agile Framework (SAFe) is currently the most widely used framework for scaling Agile processes, and is widely recognised as the most comprehensive and complex. According to the Annual State of Agile Report, 29% of respondents reported the use of this framework within their organisations. Consequently, there is a high demand for project managers who are familiar with SAFe methodology.

In 2007, Dean Leffingwell published the book “Scaling Software Agility: Best Practices for Large Enterprises,” which served as the impetus for the inception of the Scaled Agile Framework (SAFe). Leffingwell currently serves as SAFe’s Chief Methodologist, however, the framework’s development and maintenance is the result of a collaborative effort from many individuals. Today, SAFe has evolved into a comprehensive software product, versioned at 4.6, and designed with backward compatibility and modular components.

Key principles and Components

The Scaled Agile Framework (SAFe) seeks to support the development and evolution of a Lean Enterprise. This is because many businesses, to varying degrees, rely on software solutions to meet their objectives and need to be able to deliver value efficiently and sustainably. SAFe’s mission is to enable organisations to achieve this goal in the most rapid and reliable manner.

SAFe for Lean Enterprises aims to build a Lean Enterprise by supplying a knowledge base of proven principles, competencies, and best practices.

The Scaled Agile Framework (SAFe) 4.6 outlines five core competencies that, when taken together, provide organisations with the tools to achieve excellence. These competencies are composed of relevant knowledge, skills, and behaviours that are necessary for organisational success. By recognising and developing these core competencies, organisations can increase their overall efficiency and performance.

  1. Agile-Lean leadership Describes how leaders drive and sustain organisational change by learning, teaching, and implementing the Lean-Agile mindset as taught by SAFe.
  2. Technical agility and teamwork: Describes the abilities, principles, and practices required to build high-performing Agile teams.
  3. DevOps and on-demand release Describes how implementing DevOps and a continuous delivery pipeline enables organisations to release product increments as needed to meet demand.
  4. Lean systems engineering and business solutions Describes how to use lean-agile principles and practices to specify, develop, deploy, and evolve large, complex software applications.
  5. Portfolio management that is lean By applying 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 properly aligned.

With the exception of Lean-Agile Leadership, which covers the whole process, each of the core competencies can be clearly identified and linked to its corresponding level in the SAFe process diagram.


The primary objective of the Lean-Agile Leadership Competency is to support the organisation in its transition to a lean-agile enterprise. This is achieved through the exploration, implementation, and propagation of SAFe’s Lean-Agile thought process, core values, guidelines, and techniques. By doing so, the organisation can benefit from the increased efficiency, improved performance, and greater enterprise agility that come with the adoption of a lean-agile approach.

The Core Values of the Scaled Agile Framework (SAFe) are essential for driving successful Lean Enterprise transformations. It is paramount for leaders to actively promote these values at every opportunity in order to ensure their success. The following are the Core Values of SAFe:

  1. Alignment Communicate the purpose of the mission, the portfolio strategy, and the vision for the solution to the relevant stakeholders. Participate in program increment (PI) planning and backlog maintenance, as well as in any briefings related to the topic.
  2. Transparency Visualise all pertinent work.
  3. Integral quality It is essential that quality-delivery practices are incorporated throughout the entire life cycle of a project. We must not tolerate any work that is below standard, and instead, should strive to encourage investments in maintenance and the reduction of technical debt.
  4. Execution of the program As a business owner, it is essential to actively take part in the execution of the Performance Improvement (PI) plans in order to ensure that the organisation is able to reap the maximum potential benefit from them. It is important to ensure that the scope of the plan is well-aligned with both the current demand and capacity of the organisation, and any impediments and demotivators should be addressed promptly and decisively.

Adopting the Lean-Agile Mindset and applying SAFe Principles support SAFe core values:

  1. Consider the economic situation.
  2. Use systems thinking.
  3. Assume variability; keep options open.
  4. Construct incrementally using rapid, integrated learning cycles.
  5. Milestones should be based on an objective evaluation of working systems.
  6. WIP can be visualised and limited, batch sizes can be reduced, and queue lengths can be managed.
  7. Implement a cadence and synchronise with cross-domain planning.
  8. Unlock knowledge workers’ intrinsic motivation
  9. Decision-making should be decentralised.

These principles are similar to those of Lean and Agile. Finally, the organisation is transformed by adhering to the SAFe Implementation Roadmap.


The Team and Technical Agility Competency outlines the knowledge, principles, and methods required to create efficient and successful agile teams that produce reliable and quality outputs. These two key features are essential components of this competency: firstly, the ability to foster collaboration and communication between team members; and secondly, the capacity to use appropriate tools and techniques to ensure the successful execution of tasks. Furthermore, this competency also encompasses the capacity to monitor progress, provide feedback, and adjust plans as required to meet the team’s goals and objectives.

  • Team adaptability Teams use Agile practices and principles to work, learn, and adapt on a consistent basis.
  • Technical dexterity Teams utilising Agile technical practices place a large emphasis on ensuring the quality and maintainability of the code they create. To ensure that quality is maintained, the team deploys Agile engineering techniques such as Behaviour Driven Development (BDD) and Test-driven Development (TDD). The implementation of these techniques contributes to increased flow, however it is essential to maintain system quality in order to achieve a rapid and efficient flow. Should any errors arise, it could potentially impede progress and result in a delay of releases.

The Team Level of the Scaled Agile Framework (SAFe) outlines how individual Agile teams operate. An Agile Release Train is comprised of all teams that collaborate to deliver a Product Increment. Generally, the traditional agile/scrum methodology is followed, with teams executing iterations to develop working systems. SAFe utilises the roles of scrum master, product owner, and team member, in addition to the majority of scrum activities and artefacts. Program-level roles such as Product Management, System Architect, and other shared services provide assistance to the teams. Kanban is employed to visualise the flow of features throughout the delivery lifecycle as well as the interactions and handoffs between teams.


According to the DevOps and Release on Demand Competency, organisations that embrace DevOps and the continuous delivery pipeline are able to capitalise on the ability to deliver value to their target markets and customers whenever necessary. This flexibility allows them to both meet and exceed customer expectations, providing a competitive advantage in the marketplace.

DevOps seeks to unite development, operations, the business, and other components to obtain tangible business outcomes. While some organisations may not require the same frequency of releases as some of the most reputable companies in the DevOps industry, such as Amazon, which releases every few seconds, all organisations must be capable of releasing their products or services as necessary.

The Program Level of the diagram outlines the roles and activities that are necessary to achieve continuous delivery via an Agile Release Train (ART). This level functions in an iterative fashion that is comparable to the team level, however it includes more cycles and multiple agile teams. An ART is composed of 5 to 12 teams (50 to 125 individuals) that involve traditional agile roles as well as key program roles, such as a Release Train Engineer (RTE) and Product Manager. ARTs are delivered in 8-12 week Program Increments (PIs) that are planned and driven by a Product Manager.

A Program Kanban board is utilised to monitor and oversee the advancement of Program Increment (PI) features, epics, and so on. Within the Agile Release Train (ART), the Release Train Engineer (RTE) serves as the Scrum Master. Daily Standups, Scrum-of-Scrums (RTE and Scrum Master) meetings, Product Owner (PO) Synchronisation (Product Management and PO) and ART Synchronisation are all examples of regular coordination meetings (Scrum-of-Scrums and PO Synchronisation combined). Every PI is accountable for a System Demonstration and a Retrospective.


According to the Business Solutions and Lean Systems Engineering Competency, Lean-Agile principles and practices can be applied to the entire lifecycle of large, complex software applications and cyber-physical systems, from specification to development, deployment, and evolution. By doing so, organisations can achieve improved effectiveness, efficiency, and customer satisfaction.

In addition to the SAFe principles, applying the eight principles listed below when working on large solutions is critical to this competency:

At the Large Solution Level, the necessary roles, artefacts, and processes for constructing sizable and intricate solutions can be identified. To ensure successful delivery of solutions, multiple Agile Release Trains (ARTs) must work together in unison. The primary objectives of this endeavour include:

  • Control frequent integration
  • Constantly address compliance issues
  • Scale, modularity, releasability, and serviceability should all be considered when designing.

The Solution Train Engineer (STE) provides leadership and direction to the work of the Solution Management, who are responsible for ensuring that the content of the Solution meets the necessary standards. The Solution Architect is tasked with guaranteeing that all Agile Release Trains (ARTs) are properly architected. Pre and post-Program Increment (PI) planning is used to facilitate the delivery of Solutions through successive PIs. A Solution Backlog is composed of Capabilities and Solution Epics, and a Solution Kanban board is used to track their progress.


The Lean Portfolio Management Competency is designed to ensure that strategies are properly aligned with execution. This is achieved by taking a Lean and systems thinking approach to strategy, investment funding, agile portfolio operations, and governance. Through this competency, organisations can ensure that their strategies are properly implemented and investments are optimised for maximum return.

Lean Portfolio Management is primarily concerned with the following:

  1. Strategy and investment funding: ties the portfolio to the enterprise strategy, funds value streams, and establishes portfolio flow.
  2. Agile portfolio operations: coordinates value streams, assists with program execution and strives for operational excellence.
  3. Budgets are forecasted, portfolio performance is measured, and compliance is enforced under lean governance.

The Portfolio Level encompasses the principles, practices, and responsibilities needed to begin and oversee a collection of development Value Streams. A Portfolio Backlog is created using Business Epics and Enabler Epics, and is monitored using a Portfolio Kanban* board. Lean Portfolio Management (LPM) is used to decide which Value Streams are incorporated into a portfolio and includes the most influential figures in an organisation. An Enterprise Architect oversees and coordinates the work undertaken across all Value Streams.


Craig Larman and Bas Vodde, two experienced professionals from the financial and telecommunications industries, developed the Large-Scale Scrum (LeSS) framework. This framework is based on the premise that successful scaling of Scrum teams requires minimal processes and procedures in order to foster collaboration. By doing so, LeSS seeks to simplify the process of scaling, which can be made overly complex when people become involved.

Key principles and Components

LeSS (Large-Scale Scrum) is an approach to applying the principles of Scrum to multiple teams working on a single product. It is based on the ten core principles of Lean-Agile which are well-known to those familiar with the Lean-Agile methodology. These principles include focus on customer value, continuous improvement, leadership at all levels, and self-organisation of teams. The implementation of LeSS emphasises collaboration, team-level planning and learning, and the development of cross-functional teams. With LeSS, organisations can take advantage of agility at scale, allowing for faster delivery of high-quality products.

  1. Large-Scale Scrum is Scrum
  2. Controlling a process empirically
  3. Transparency
  4. More with fewer resources
  5. Product concentration
  6. Customer-centric
  7. Perfection is attained through continuous improvement.
  8. Consideration of systems
  9. Think lean.
  10. Theory of Queuing

LeSS only has two main roles, both of which are taken from Scrum:

  1. Product creator Works in groups of 2-8 people
  2. Scrum Master Works in groups of 1-3

Working in 1-4 week sprints, all teams collaborate on the same product backlog. This approach of working in parallel means that the beginning and end of the sprints are synchronised. At the culmination of each sprint, the teams come together to deliver a product increment. It may seem daunting for a single product owner to manage eight teams, but LeSS encourages delegating the responsibility of product backlog item clarification to the teams themselves. To achieve this, it is necessary for teams to be cross-functional and have the skills to code, design, test, and understand the business domain. Additionally, teams must be given the authority to communicate with customers.


Planning is divided into two sections:

  1. Sprint planning 1 The representatives from each team will convene with the product owner in order to determine which items from the backlog should be addressed during the sprint, as well as to explore any potential requirements for inter-team collaboration.
  2. Sprint planning 2 As in traditional scrum, each team meets separately to devise a strategy for completing backlog items.


During a Sprint, Product Backlog Refinement (PBR) can be carried out in order to ensure that Product Backlog Items are ready for Sprint Planning. The Large-Scale Scrum (LeSS) framework does not provide any specific rules for PBR and instead encourages organisations to find a process that works best for them. Generally speaking, PBR involves three major activities:

  1. Breaking up large items.
  2. Detailing items until they are ready.
  3. Estimating.


Three things happen at the end of each sprint:

  1. Sprint Evaluation A Sprint demo in which teams and customers discuss what was accomplished during the Sprint and what should be done next.
  2. Retrospective Each team conducts its own retrospective in order to improve its process.
  3. Overall assessment Teams, product owners, and scrum masters collaborate to inspect and improve organisational practices.


Scrum at Scale and Scrum@Scale are interchangeable terms that were introduced in 2014 by Jeff Sutherland, the creator of the Scrum methodology and a signatory to the Agile Manifesto. Sutherland’s introduction of this methodology has gained widespread recognition and continues to be implemented as a successful approach to project management in many organisations.

Scrum@Scale is a meta-framework that builds upon the fundamentals of Scrum and offers a straightforward, lightweight structure for scaling Scrum with minimal overhead. It provides an approach to addressing scaling issues and associated areas, while keeping bureaucracy to a minimum. The framework is designed to be less prescriptive than other popular scaled agile methodologies, and instead focuses on providing a mental model to help guide practitioners through the scaling process.

Key principles and Components

Scrum@Scale is a framework that leverages the core concepts of Scrum to enable organisations to scale their implementation of the methodology. By clearly differentiating between the responsibilities of the Product Owner and the Scrum Master, Scrum@Scale helps to ensure that roles and responsibilities are clearly established, thereby minimising inefficiencies and preventing conflicts.

Scrum@Scale utilises two distinct cycles to differentiate roles and responsibilities. The Scrum Master cycle and Product Owner cycle both have two distinct points of interaction – Team Level Process, and Product Release Feedback. Through these two processes, all individuals involved in the Scrum@Scale initiative will be able to effectively coordinate and complete the necessary tasks to reach the desired outcomes.


The Scrum Master Cycle is responsible for ascertaining the most effective way to construct the items determined by the Product Owner Cycle. Each Scrum Team within the Scrum@Scale framework is structured with the same roles, artefacts, activities, and ceremonies as in a standard Scrum environment.

Scrum teams can be organised into Scrum of Scrums (SoS) to create a single product increment. During this process, they will attend joint backlog grooming and prioritisation meetings, hold retrospectives and keep impediment backlogs up to date. Additionally, they will also hold a Scaled Daily Scrum (SDS) (which is similar to the regular daily scrum) to coordinate between the teams and remove any roadblocks. To ensure the success of this process, each participating team must send at least one representative (usually the team’s scrum master) to the SDS, who will be supervised by the Scrum of Scrums Master (SoSM). The SoSM will be responsible for coordinating with the scrum teams and the product owners.

If further scaling is necessary, a Scrum of Scrums (SoS), composed of multiple SoS, can be established to meet on a daily basis. The Executive Action Team (EAT) is the chief entity and is responsible for advancing Agile across the organisation, and for organising Scrum teams if and when needed. Additionally, the EAT acts as the ultimate authority for the removal of any and all impediments.


The Product Owner Cycle is responsible for determining which products and services will be developed, as well as all the tasks that are necessary to support them. Product Owners are assigned to Scrum teams and they fulfill the responsibilities that have been allocated to them in the Scrum framework. Product Owners are organised into Product Owner Teams, which are aligned to SoS teams. Product Owner Teams convene for daily Meta Scrums in order to go over the teams’ overall strategy and to collaborate with the corresponding SoSMs, other Product Owners, and other stakeholders as needed. A Chief Product Owner leads the Meta Scrums.

Product Owners are responsible for scaling their activities in accordance with the size of the organisation. Ultimately, this process culminates in the establishment of an Executive Meta Scrum (EMT). The EMT is responsible for determining the highest-priority objectives on a company-wide basis.


The initial stage of implementing Scrum@Scale is the formulation of a scalable reference model, consisting of a limited number of teams employing Scrum on a smaller scale. This step is necessary in order to address any organisational policies and development processes that could potentially obstruct agile development. It is strongly recommended to resolve these problems at this stage, since similar difficulties are likely to be present across the entire organisation and the resulting discontent could potentially hamper agile adoption. The reference model can then be utilised as a template for scaling Scrum to other teams and departments.

In order to initiate the application of the reference model, it is essential to form an Executive Action Team (EAT). This team should comprise of individuals with both political and financial clout in the organisation, and they should have the capacity to carry out modifications in organisational policies.


In the second section of the project management blueprint, we have explored some of the most commonly used frameworks for more complex projects and programs. Although Waterfall is still highly utilised in many organisations, its rigid rules and procedures make it less suitable for projects that are small in size, have a clear scope, and are unlikely to undergo changes.

As companies are presented with ever-growing, complex projects that involve constantly fluctuating requirements and objectives, many are turning to Agile approaches as a viable solution. Although Agile was originally intended to be utilised by small teams of 5-9 people, several Agile practitioners have adapted it for use in larger, more expansive settings. This article discussed several of those solutions, including Disciplined Agile Delivery (DAD), Scaled Agile Framework (SAFe), Large Scale Scrum (LeSS), and Scrum@Scale.

In the concluding section of the project management blueprint, we will examine various project management frameworks, such as the Project Management Professional (PMP) and PRINCE2. Additionally, we will explore innovative frameworks and processes, including “jobs to be done” (JTBD) and “design thinking”, to gain a comprehensive understanding of their application in project management.

Join the Top 1% of Remote Developers and Designers

Works connects the top 1% of remote developers and designers with the leading brands and startups around the world. We focus on sophisticated, challenging tier-one projects which require highly skilled talent and problem solvers.
seasoned project manager reviewing remote software engineer's progress on software development project, hired from Works blog.join_marketplace.your_wayexperienced remote UI / UX designer working remotely at home while working on UI / UX & product design projects on Works blog.join_marketplace.freelance_jobs