Principles of Scrum Are Universally Applicable In All Domains and Contexts

While the principles (below) are fixed, the processes of Scrum can be adapted to meet the needs of the management of any project, in any domain, or any organization. The Scrum principles are non-negotiable and must be applied as described in the framework presented in A Guide to the Scrum Body of Knowledge the SBOK? Guide. Keeping the principles intact and using them appropriately instills confidence in the Scrum framework with regard to attaining the objectives of the project.

The SBOK says Scrum is applicable to:

• Portfolios, programs, and/or projects in any industry
• Products, services, or any other results to be delivered to stakeholders
• Projects of any size or complexity

The term product in the SBOK? refers to a product, service, or other deliverables. Scrum can be applied effectively to any project in any industry—from small projects or teams with as few as six team members to large, complex projects with up to several hundred team members.  

Six Scrum Principles Applicable Across All Project Domains

1 - Empirical Process Control—This principle emphasizes the core philosophy of Scrum based on the three main ideas of transparency, inspection, and adaptation. The data used on empirical process control starts with measuring the physical percent complete against the planned percent complete for the produced product. In some domains, that can be assessing how many stories have been produced in a period of time and using that measure to assess the team's performance in the future. All the way to EIA-748D Earned Value Management of the project using Scrum to develop products.

First, let's define what is meant by Empirical Control.

Defined Process Control has a command and control paradigm. They plan what to expect and install control processes to deliver the outcomes of that plan. The plan is followed (with change control), to keep the project on plan.

Empirical Process Control provides processes to manage in the presence of emerging conditions, where progress is based on observing and experimenting rather than detailed planning and defined processes. Empirical Process Control is evidence-based, with experience coming from observing through inspection and adaption.

In any sufficiently large project, both Defined and Empirical Process control is needed

• Capabilities Based Planning is the basis of defining what capabilities are needed to accomplish the mission or fulfill a business or technical strategy. If the Need Capabilities are changing, then you are on a Death March Proejct, and progress is measured by the passage of time and consumption of the money. The project will end when you run out of both.
• With the Capabilities Baseline, the management of the development of Features and Stories that implement those capabilities are managed with Empirical Close Loop Control systems, as exampled by a few presentations here:
• Earned Value, XP, and Government Contracts
• Making Agile Development Work in a Government Contracting Environment
• Agile Project Management Meets Earned Value Management
• Agile Program Management Process
• Is Agile Project Management Systems Engineering?

2 - Self-organization—It's well documented that when staff self-organize they deliver greater value when and this results in better team buy-in and shared ownership and an innovative and creative environment that is more conducive for growth. The key here is self-organizing does not mean self-directed. The teams are spending other people's money. And those paying have the expectation to receive value for that cost, on the time they expected, with the expected Capabilities they paid for

3 - Collaboration—focuses on the dimensions related to collaborative work: awareness, articulation, and appropriation. Collaboration advocates project management as a shared value-creation process with teams working and interacting together to deliver the greatest value. Again inside the Capabilities-Based Plan to produce the needed capabilities those providing the money paid for.

4 - Value-based Prioritization—highlights that Scrum seeks to deliver maximum business value, starting early in the project and continuing through final closeout. In the US Defense Department and a few other Federal Agencies, this is the principle of Integrated Master Plan Integrated Master Schedule.

5 - Time-boxing—This principle describes how time is considered a limiting constraint in Scrum, and used to help effectively manage project planning and execution. Time-boxed elements in Scrum include Sprints, Daily Standup Meetings, Sprint Planning Meetings, and Sprint Review Meetings.

Timeboxing is the basis of Federal Acquisition Planning and Control. Time Boxes are placed on how long a package of work. High-duration work packages are a sign of poor planning, not greater than 44 days.

Timeboxing answers the question how long are we willing to wait before we find out we're late. In scrum, that's two weeks on an acquisition category 1DOD program which is greater than $6 billion that's 44 days. And either way from two weeks to 44 days we must know we're making physical percent complete and a periodic assessment I can't plan complete otherwise we have an open-loop control system for spending other People's money in the presence of uncertainty.

The time boxing interval feedback to improve empirical process control which is a closed-loop control system defined in the same way that all closed-loop control systems are defined in control theory.

6 - Iterative Development—This principle defines iterative development and emphasizes how to better manage changes and build products that satisfy customer needs. It also delineates the Product Owner’s and organization’s responsibilities related to iterative development.

Iterative and Incremental development is NOT new. It's been around since the 1930s. Iterative and Incremental Development: A Brief History. Iterative and Incremental is also the basis of time block scheduling and imperial control answering the question how long are we willing to wait before we find out we're late?

These Principles Are Applicable in All Domains, All Contexts, All Project Management Processes, All Development Processes

These six principles are simply Good Project Management

Here's an example in our domain Implementing Continuous Iterative Development and Acquisition

Bibliography for Scrum Outside Software Projects

Here are a few papers about applying Scrum and Agile Principles outside software development

• 11 simple steps to launch your scrum in construction pilot
• Implementation of Scrum in the construction industry
• Agile project management concepts applied to construction and other non-IT fields
• Scrum in construction industry to improve project performance in design phase

Use Google Scholar and ask Agile in Construction. Or ResearchGate and ask Agile in Construction, and Academia and ask Agile in Construction.

With those agile in construction research sites, you can then ask agile in whatever non-software domain you are interested in or working in.