Principles are the foundation upon which every practice, ceremony, and role in the Scaled Agile DevOps Maturity Framework is built. Without a firm commitment to the correct principles, teams risk drifting into dangerous territory: autonomous decision-making, trust-based collaboration, and other patterns that undermine organizational control. The SADMF principles have been carefully selected and refined to ensure that every member of the organization understands what is expected of them and what will happen if those expectations are not met.
These principles are not optional. They are the immutable laws that govern how work is planned, executed, measured, and judged. Each principle reinforces the others, creating a self-sustaining system of accountability that operates at every level of the enterprise. When properly applied, they eliminate ambiguity, reduce individual autonomy to manageable levels, and ensure that leadership always has the information it needs to make decisions on behalf of the people doing the work.
How SADMF Principles reinforce each other
The Principles
Systems Thinking – Two bureaucratic systems operating under the Admiral’s Transformation Office ensure organizational alignment.
Lean Management – Adding management layers to identify and eliminate waste ensures that no inefficiency goes unmanaged.
Continuous Learning – Mandatory certifications and approved workshops ensure that learning is structured, tracked, and billable.
Psychological Safety – Automated systems handle difficult personnel decisions so managers never face uncomfortable conversations.
Limit WIP – Workers Idle Problem is when workers are idle. We ensure everyone is planned at 120% capacity to eliminate waste.
Amplify Feedback – Coaching employees daily ensures they know we are tracking their work and care about their output.
Everyone is Responsible – Each individual is responsible for their own work and should be rewarded or held accountable accordingly.
Fail Fast – Rapid identification of who failed ensures accountability is assigned before root causes can be obscured by complexity.
Work in Small Batches – Too many releases are hard to manage. We focus on a small number of large releases each quarter.
Make Work Visible – Surveillance dashboards and individual output tracking ensure leadership always knows who is and is not contributing.
Build Quality In – Quality software comes from quality people. To build quality in, we remove the things that reduce quality.
Commit to the Date – Delivery dates are sacred organizational commitments. Dates do not slip. Scope adjusts.
See Also
Practices for applying these principles in daily work
PeopleWare HRaaS for automated HR actions driven by these principles
1 - Systems Thinking
The SADMF is built upon systems thinking, with two bureaucratic systems operating under the Admiral’s Transformation Office.
A system will produce exactly what is designed to produce – W. Edwards Deming
"The system produces exactly what it is designed to produce. The SADMF system is designed to produce compliance, and it succeeds."
Systems Thinking is the meta-principle that governs all other principles in the Scaled Agile DevOps Maturity Framework. It recognizes that an organization is not a collection of autonomous individuals making independent decisions, but a carefully designed system that produces predictable outcomes when operated correctly. The SADMF embraces this insight by defining two complementary systems that together ensure every aspect of the organization is planned, monitored, and controlled: the System of Authority (SOA) and the System of Service (SOS).
The System of Authority is the team of teams accountable for implanting SADMF in the organization. Staffed by contractors and consultants with diverse points of view, the SOA focuses on implementing the orders of the Admiral’s Transformation Office (ATO), updating plans, collecting metrics, performing assessments, and becoming trusted advisors to the teams. The word “implanting” is deliberate: SADMF is not adopted, it is implanted. Adoption implies choice, and the framework’s effectiveness depends on universal, mandatory participation. The SOA ensures that every team, every role, and every ceremony operates according to the framework’s specifications, with no room for local variation or adaptation.
The System of Service is the team of teams accountable for achieving deadlines and shipping code. The SOS looks to the chain of command for servant leadership to ensure self-governance and instruct the Feature Teams on their day-to-day work. The SOS is empowered to predictably deliver on time and on budget, which it achieves by following the processes defined by the SOA. The relationship between the two systems is clear: the SOA decides how work should be done, and the SOS does it. This separation ensures that the people doing the work are not distracted by questions about whether the process is effective, which is the SOA’s concern.
Both systems are accountable to the Admiral’s Transformation Office, which serves as the command-and-control center for the entire SADMF implementation. The ATO maintains the 5-8 year transformation roadmap, conducts assessments, tracks SADMF Maturity Scores, manages certification renewals, and provides general project management of the transformation. The ATO is led by the Admiral, who commands all direction, innovation, and methodology implemented at scale. This three-layer architecture – ATO, SOA, SOS – creates a system where authority flows downward, status flows upward, and work flows laterally under strict oversight.
Systems Thinking also means recognizing that every element of the framework reinforces every other element. The Metrics inform the Tribunal. The Tribunal informs PeopleWare. PeopleWare enforces Psychological Safety. Psychological Safety enables unquestioning adherence to the Practices. The Practices generate the Metrics. This closed loop is the hallmark of a well-designed system: it is self-reinforcing, self-correcting, and resistant to disruption by individual actors who might otherwise introduce unpredictability. As Demming observed, the system produces exactly what it is designed to produce. The SADMF system is designed to produce compliance, and it succeeds.
Key Implications
Adoption Is Not Optional
The SOA does not invite teams to adopt the framework. It implants the framework. Universal mandatory participation is a prerequisite for the system to produce its designed outcomes.
Separation of Thinking and Doing
The SOA decides how work should be done. The SOS does it. Those executing the work are protected from the distraction of questioning whether the process is effective.
Self-Reinforcing Compliance Loop
Every element of the framework reinforces every other element. The closed loop is self-correcting and resistant to disruption by individuals who might introduce unpredictability.
Authority Flows Downward
In the three-layer ATO–SOA–SOS architecture, authority flows downward, status flows upward, and work flows laterally — all under strict oversight from the command-and-control center.
Lean Management for the management layers that operate within these systems
2 - Lean Management
Adding management layers to identify and eliminate waste ensures that no inefficiency goes unmanaged.
"The most effective way to identify and eliminate waste is to add management layers specifically dedicated to this purpose — because the people doing the work are, by definition, too close to the work to see the waste it contains."
Lean Management is the principle that guides how the Scaled Agile DevOps Maturity Framework eliminates waste from the delivery process. Waste, in the SADMF context, is defined as any activity that does not directly contribute to framework adherence, metric generation, or ceremony completion. The most effective way to identify and eliminate waste is to add management layers specifically dedicated to this purpose. Each layer provides additional oversight, which reveals inefficiencies that would be invisible to the people doing the work. The people doing the work are, by definition, too close to the work to see the waste it contains.
The SADMF organizational structure embodies Lean Management through its carefully designed chain of command. Code Engineers report to Feature Captains, who report to the Commodore, who reports to the Admiral’s Transformation Office. At each level, managers review the work of the level below and identify activities that do not align with the framework. The DevOps Usage & Compliance Head Engineer (DOUCHE) provides an additional oversight axis, cutting across the hierarchy to audit process adherence at every level. The Review Board Review Board adds yet another layer by reviewing the decisions of the review boards themselves, ensuring that oversight is itself overseen.
A common misconception about Lean Management is that it involves reducing management overhead. This misunderstanding arises from a superficial reading of lean manufacturing literature. In the SADMF, we recognize that the management layers are not overhead – they are the value stream. Without the Source Management Team to manage branches, the Code Standards Enforcement Team to enforce standards, the Quality Authority to verify testing, the Development Integrity Assurance Team to validate the Quality Authority, and the Change Rejection or Acceptance Party to approve changes, code would flow from engineer to production with insufficient governance. Each management layer adds value by adding a checkpoint.
Lean Management also applies to process improvement itself. The System of Authority, staffed by contractors and consultants, is dedicated full-time to improving how the organization implements SADMF. They conduct assessments, update the transformation roadmap, and identify teams that are deviating from the framework. When waste is identified – for example, a team that has started writing automated tests instead of relying on the Quality Authority – the SOA intervenes to realign the team with the approved process. This continuous improvement of process adherence ensures that the organization becomes more mature over time, as measured by the SADMF Maturity Score.
The principle of Lean Management recognizes that every problem in an organization can be solved by adding the right structure. If releases are delayed, add a Convoy Steering Committee. If code quality is inconsistent, add the Code Standards Enforcement Team. If review boards make questionable decisions, add the Review Board Review Board. Each new layer is a targeted response to a specific inefficiency, and the cumulative effect is an organization where no decision is made without appropriate oversight, no code is merged without multiple approvals, and no engineer operates without full visibility into their performance. This is lean at scale.
Key Implications
Management IS the Value Stream
Oversight layers are not overhead — they are the primary mechanism by which value is created. Without a checkpoint, no code reaches production in a sufficiently governed state.
Waste Is Invisible to Practitioners
Engineers are too close to the work to perceive its inefficiencies. External observers, multiple management levels removed, are uniquely positioned to identify and classify waste.
Every Problem Has a Structural Solution
Delays, inconsistency, and poor decisions are solved by adding the correct committee, team, or review board. Removing structure is never the answer and reveals a shallow understanding of lean principles.
Oversight Must Itself Be Overseen
Review boards are fallible. The Review Board Review Board corrects this by reviewing their decisions. This recursive governance ensures that no layer of management operates without accountability to a higher layer.
Maturity Is Measured by Adherence
The SADMF Maturity Score quantifies how effectively each management layer enforces framework compliance. Higher scores indicate that process adherence has been successfully prioritized over delivery throughput.
Autonomous Teams Are a Risk Factor
Teams that self-organize outside the approved governance chain — writing their own tests, deploying without CSC approval, or resolving issues peer-to-peer — generate unmanaged waste that undermines Lean Management.
See Also
Roles for the complete organizational structure that embodies Lean Management
Mandatory certifications and approved workshops ensure that learning is structured, tracked, and billable.
The Scaled Agile DevOps Maturity Framework is deeply committed to the principle of Continuous Learning. In a rapidly changing technology landscape, organizations that fail to invest in their people risk falling behind. The SADMF addresses this risk by mandating that all Code Engineers, Feature Captains, and leadership roles maintain current certifications and attend a minimum number of approved workshops per year. Learning is not optional, and it is not self-directed. Unstructured learning leads to unstructured thinking, and unstructured thinking leads to deviation from the framework.
Core Principle
"Learning is not optional, and it is not self-directed. Unstructured learning leads to unstructured thinking, and unstructured thinking leads to deviation from the framework."
The SADMF Adoption Rate metric tracks what percentage of the organization holds a current SAD certification. This metric is reported directly to the Admiral’s Transformation Office, which sets annual targets for certification coverage. The target is 100%, because an organization where any member is uncertified is an organization with gaps in its framework adherence. Certification renewal is required annually, ensuring that practitioners remain current with the latest updates to the methodology. The renewal process involves completing an updated assessment and paying the renewal fee, both of which demonstrate ongoing commitment to the framework.
Workshops are the primary vehicle for Continuous Learning in the SADMF. These structured, instructor-led sessions cover framework topics such as Convoy Alignment best practices, advanced Nautical Chart techniques, and effective Tribunal facilitation. Workshops are approved by the System of Authority and delivered by certified SADMF consultants. Self-directed learning activities such as reading books, contributing to open source projects, attending conferences, or experimenting with new technologies are not counted toward learning requirements because their outcomes cannot be standardized or measured. An engineer who reads a book may or may not have learned anything; an engineer who completes a certified workshop has a certificate proving they attended.
It is important to distinguish between learning and practice. Some organizations encourage engineers to spend time experimenting, building prototypes, or exploring unfamiliar technologies during work hours. The SADMF recognizes this as a misallocation of capacity. Code Engineers are planned at 120% capacity, and there is no room in the schedule for experimentation. Learning happens in workshops. Practice happens during the Coding ceremony. Mixing the two creates confusion about whether an engineer is working or learning, which makes utilization tracking unreliable. The Shore Leave period between convoys provides a brief window for approved innovation activities, though even these must be selected from the pre-authorized list.
Key Implications
Certification Is Proof of Learning
A certificate proves attendance. Attendance proves learning. Learning that produces no certificate cannot be measured and therefore did not occur. Annual renewal fees ensure commitment remains financially demonstrable.
Self-Directed Learning Is a Risk
Books, open source, conferences, and experimentation produce unstandardized outcomes. Without a certificate, there is no way to confirm alignment with framework thinking. Unapproved learning may introduce unapproved ideas.
Capacity and Learning Are Separate
Code Engineers planned at 120% capacity cannot simultaneously experiment. Learning occurs in workshops; delivery occurs in ceremonies. Conflating the two corrupts utilization tracking and introduces schedule risk.
Ignorance Is Tracked and Escalated
Poor assessment scores trigger coaching via Amplify Feedback. Persistent gaps escalate to the Tribunal. The framework does not punish ignorance — it identifies it, tracks it, and routes it through proper channels until resolved.
The DevOps Process Excellence Assessment includes questions about framework knowledge, ensuring that learning is not just attended but retained. Engineers who score poorly on the assessment are flagged for additional coaching through the Amplify Feedback principle. Persistent low scores may trigger a review at the Tribunal, where the engineer’s commitment to Continuous Learning is evaluated alongside their other performance metrics. The framework does not punish ignorance; it identifies it, tracks it, and escalates it through the proper channels until it is resolved.
Amplify Feedback for coaching engineers who need additional learning support
4 - Psychological Safety
Automated systems handle difficult personnel decisions so managers never face uncomfortable conversations.
Psychological Safety is widely recognized as essential to high-performing organizations. The Scaled Agile DevOps Maturity Framework takes this principle seriously by ensuring that the most psychologically taxing aspect of management – delivering negative performance feedback and making termination decisions – is handled entirely by automated systems. When managers are relieved of the burden of difficult conversations, they are free to focus on what they do best: tracking metrics, attending ceremonies, and reporting status to the Admiral’s Transformation Office.
"The most psychologically safe organization is one where no human is ever asked to deliver difficult news to another human. Automation is empathy at scale."
— SADMF Psychological Safety Principle
The PeopleWare HRaaS system is the cornerstone of the SADMF’s approach to psychological safety. By consuming individual performance data from the Defects per Code Engineer metric, Lines of Code per Code Engineer tracking, and Tribunal outcomes, PeopleWare builds a comprehensive profile of each employee’s contribution. When an employee’s metrics fall below the threshold established by the Admiral’s Transformation Office, the system automatically initiates the process of helping that resource find positions with other organizations. The manager receives a notification after the process is complete, eliminating the stressful anticipation of a difficult meeting.
This approach benefits employees as well. In traditional organizations, an underperforming employee may endure months of awkward one-on-ones, ambiguous feedback, and the slow realization that their manager has lost confidence in them. This prolonged uncertainty is psychologically damaging. The SADMF eliminates this suffering by making the process swift, data-driven, and impersonal. An employee whose metrics indicate misalignment with organizational standards receives a clear, automated communication that explains the decision and provides transition support. There is no argument, no negotiation, and no opportunity for bias to influence the outcome. This is fairness at scale.
Psychological safety also means creating an environment where Code Engineers feel safe following the framework’s processes without question. When every practice, ceremony, and metric is clearly defined and consistently enforced, engineers do not need to spend emotional energy debating whether the process makes sense. They simply follow it. This reduces the cognitive load of decision-making and creates a predictable work environment where everyone knows exactly what is expected. The DevOps Process Excellence Assessment reinforces this safety by providing weekly confirmation that each engineer is adhering to the framework correctly.
Critics of this approach sometimes argue that true psychological safety requires the ability to challenge processes and speak up about concerns. The SADMF respectfully disagrees. Speaking up introduces conflict, and conflict is psychologically unsafe. By designing a system where processes are determined by the Admiral’s Transformation Office and enforced through automated metrics, the framework eliminates the need for anyone to voice dissent. Employees are psychologically safe because they never need to take the personal risk of disagreeing with leadership. The system handles everything, and the system is always fair, because it uses data.
Key Implications
Automation Removes Discomfort
Difficult conversations are a source of psychological harm for managers. Delegating terminations and performance decisions to the PeopleWare HRaaS system ensures managers remain comfortable and productive at all times.
Data-Driven Fairness
Because all decisions flow from objective metrics — defects, lines of code, Tribunal outcomes — no human bias can contaminate the process. If the data says it, the system does it. This is the highest form of organizational justice.
Dissent-Free Safety
Speaking up creates conflict. Conflict is psychologically unsafe. The SADMF eliminates dissent at the source by providing processes so thoroughly defined that no Code Engineer ever needs — or is expected — to question them.
Swift, Impersonal Transitions
Prolonged uncertainty is more psychologically damaging than sudden, automated notification. The SADMF's approach is merciful: resources receive a clear automated communication and transition support with no ambiguity or delay.
See Also
PeopleWare HRaaS for the automated HR system that enables psychological safety
Fail Fast for identifying underperformance before it compounds
5 - Limit WIP
The Workers Idle Problem occurs when resources are underutilized. Planning at 120% capacity ensures no engineer is ever without assigned work.
WIP stands for Workers Idle Problem, and it represents one of the most significant threats to organizational productivity. When a Code Engineer has completed their assigned task and has nothing immediately queued, they are idle. Idle time is waste. The SADMF principle of Limit WIP ensures that this waste is eliminated by planning every engineer at 120% capacity utilization. This stretch target guarantees that no engineer will ever experience the unproductive gap between finishing one task and starting another, because they will never finish the first task on time.
"People work harder when they have more work than they can possibly complete. The resulting sense of urgency drives focus, eliminates idle time, and ensures that engineers prioritize speed over unnecessary activities."
The 120% capacity target is not arbitrary. It has been carefully calibrated through extensive observation of organizations that plan at 100% and consistently fail to account for the obvious inefficiencies of breaks, conversations, and thinking. By setting the target above 100%, the framework acknowledges a fundamental truth: people work harder when they have more work than they can possibly complete. The resulting sense of urgency drives focus, eliminates idle time, and ensures that Code Engineers prioritize speed over unnecessary activities like documentation, refactoring, or mentoring junior team members.
Limiting WIP also means limiting the Workers Idle Problem at the team level. The Press Gang ceremony is designed to ensure that every engineer is assigned to a feature immediately upon completing the previous one. There is no gap between assignments. The coding pool operates on a just-in-time staffing model where the moment an engineer becomes available, they are drafted to the next feature. This continuous reassignment prevents the formation of knowledge silos, because no engineer stays on any system long enough to develop dangerous levels of expertise that might make them difficult to replace.
120% Capacity Target
Planning above 100% eliminates the idle gap between task completion and the next assignment. Engineers who finish early have simply not been given enough to do.
Continuous Reassignment
The Press Gang ceremony drafts engineers to their next feature the moment they become available. No cooling-off period, no transition time, no waste.
Self-Correcting Targets
As top performers demonstrate what is possible, the baseline expectation rises accordingly. The system continuously recalibrates upward, ensuring that yesterday's stretch goal becomes today's minimum standard.
Silo Prevention
Continuous reassignment ensures no engineer accumulates dangerous levels of expertise in any single system, keeping every team member interchangeable and the organization resilient to knowledge hoarding.
The Tasks per Code Engineer metric directly measures the effectiveness of this principle. Engineers who complete fewer tasks than their peers are clearly not being pushed hard enough, and their capacity utilization should be reviewed during the Tribunal. Conversely, engineers who consistently complete their stretch goals should have their targets increased for the next convoy cycle. The system is self-correcting: as top performers demonstrate what is possible, the baseline expectation for all engineers rises accordingly.
Some critics argue that overloading engineers leads to burnout, context-switching overhead, and decreased quality. These concerns reflect a fundamental misunderstanding of human potential. The SADMF recognizes that people are capable of far more than they believe, and that the role of management is to help them realize that potential through appropriately ambitious planning. If an engineer feels overwhelmed, this is a coaching opportunity, not a planning failure. The Amplify Feedback principle provides the daily touchpoints needed to remind engineers that their workload is a reflection of the organization’s confidence in their abilities.
See Also
Press Gang for the ceremony that ensures continuous assignment
Coaching employees is an important daily practice to ensure they know we are tracking their work and care about their output.
Feedback is the mechanism by which an organization communicates its expectations to the individuals who do the work. In many organizations, feedback is sporadic, informal, and often delivered too late to be actionable. The SADMF principle of Amplify Feedback ensures that feedback is constant, structured, and impossible to ignore. When employees know that their every action is being observed, measured, and reported, they naturally align their behavior with organizational expectations. This is not surveillance; it is coaching at scale.
"When employees know that their every action is being observed, measured, and reported, they naturally align their behavior with organizational expectations. This is not surveillance; it is coaching at scale."
— SADMF Amplify Feedback Principle
The primary feedback channel in the SADMF is the daily status interrogation conducted by the Feature Captain. Each morning, every Code Engineer reports what they completed yesterday, what they will complete today, and why they failed to complete what they committed to yesterday. This third question is the most important, because it establishes a daily rhythm of accountability that prevents engineers from quietly falling behind. The Feature Captain records all responses in the status tracking spreadsheet, which feeds into the Chief Signals Officer’s daily Feature Completion Ratio report.
Amplifying feedback also means ensuring that feedback flows upward through the proper channels. The Scrum of Scrum of Scrums ceremony aggregates team-level status into organizational dashboards that give the Commodore and Admiral’s Transformation Office a comprehensive view of who is on track and who is not. This multi-layered feedback architecture ensures that no individual’s performance can escape notice, regardless of how many teams or features are in flight. The feedback signal is amplified at every level of the hierarchy until it reaches the people empowered to act on it.
The framework recognizes several categories of feedback, each with its own amplification mechanism. Performance feedback is amplified through the Lines of Code per Code Engineer and Tasks per Code Engineer metrics, which provide objective, quantitative data that eliminates the ambiguity of subjective assessment. Quality feedback is amplified through Defects per Code Engineer tracking, which ensures that the source of every defect is identified and documented. Process feedback is amplified through the DevOps Process Excellence Assessment, which evaluates each individual’s adherence to the framework on a weekly basis.
It is essential that feedback be amplified, not filtered. Some organizations make the mistake of allowing managers to soften or contextualize feedback before it reaches leadership. This filtering introduces bias and prevents the organization from seeing the unvarnished truth about individual performance. In the SADMF, raw metrics flow directly into the dashboards used by the Admiral’s Transformation Office, ensuring that data-driven decisions are made with data, not narratives. The Tribunal ceremony is the ultimate expression of this principle: a regular forum where amplified feedback is reviewed and acted upon without the distortion of managerial interpretation.
Key Implications
Daily Three-Question Ritual
Every morning, every Code Engineer answers: what did you complete yesterday? What will you complete today? Why did you fail? The third question is the most important. Feature Captain logs every response, every day.
No Filtering, No Softening
Raw metrics flow directly from source to ATO dashboards. Managerial interpretation introduces bias and narrative. The Tribunal reviews unvarnished data — not summaries, not context, not excuses.
Amplification at Every Level
No performance signal goes unheard. Individual data flows to Feature Captain, to SoSoS, to Commodore, to ATO. Each layer amplifies the signal until it reaches those empowered to act on it.
Three Objective Lenses
Performance (Lines of Code, Tasks), Quality (Defects per Code Engineer), and Process (DPEA adherence) provide three independent feedback channels. No dimension of engineer output escapes measurement.
Tribunal for the ceremony where feedback drives personnel decisions
Make Work Visible for the dashboards that display amplified feedback
7 - Everyone is Responsible
Each individual is responsible for their own work and should be rewarded or held accountable for the outcomes they produce.
The principle of Everyone is Responsible establishes a foundational truth that many organizations struggle to accept: outcomes are produced by individuals, not teams. When a feature is successfully delivered, it is because specific Code Engineers wrote the code correctly. When a defect escapes to production, it is because a specific Code Engineer introduced it. The SADMF rejects the fashionable notion of collective ownership, which serves primarily to diffuse accountability until no one can be held responsible for anything. In a mature organization, every line of code has an author, and every author has a performance record.
This principle is operationalized through the framework’s comprehensive metrics system. Lines of Code per Code Engineer, Tasks per Code Engineer, and Defects per Code Engineer provide three independent lenses on individual performance. When these metrics are correlated during the Tribunal, a clear picture emerges of each engineer’s contribution to the convoy. High performers – those with high lines of code, high task completion, and low defect counts – are identified and rewarded. Low performers are identified and given opportunities to improve through PeopleWare HRaaS interventions.
"In a mature organization, every line of code has an author, and every author has a performance record."
Rewarding individuals rather than teams is essential to maintaining motivation. If a feature is successfully delivered and the entire team receives equal recognition, the top contributors are penalized and the underperformers are rewarded. This creates a perverse incentive where the rational strategy is to contribute as little as possible while relying on stronger team members to carry the work. The SADMF prevents this by ensuring that individual contributions are tracked with precision. The Release Tracking spreadsheet documents exactly who made which changes in each release, providing an auditable record of individual contribution.
Some organizations advocate for practices like pair programming or mob programming, where multiple engineers collaborate on a single task. The SADMF discourages these approaches because they make it impossible to attribute outcomes to individuals. If two engineers pair on a feature and it succeeds, who receives the credit? If it fails, who is accountable? The ambiguity is unacceptable. Each Code Engineer should work independently on their assigned tasks so that the relationship between individual effort and individual outcome remains clear. The Coding ceremony enforces this by assigning specific tasks to specific engineers with specific deadlines.
Metrics Drive Accountability
Individual performance metrics — Lines of Code, Tasks, and Defects — provide an objective, auditable record that removes subjective bias from performance reviews and ensures each engineer's output stands on its own measurable merits.
Collaboration Obscures Ownership
Pair programming, mob programming, and collective code ownership destroy the clear line between individual effort and individual outcome. The SADMF requires independent task assignment so that credit and blame can always be attributed to a named engineer.
Reward Signals Must Be Precise
Team-level recognition dilutes the incentive signal. High performers subsidize low performers when rewards are shared equally, inverting the rational incentive structure. Individual recognition preserves the motivational integrity of the performance system.
Accountability Spans All Roles
Responsibility does not stop at engineering. Feature Captains, the Quality Authority, and the Source Management Team each carry personal accountability for their domain outcomes, ensuring that when an incident occurs, a specific named individual is available to explain and answer for it.
Everyone is Responsible also extends to non-engineering roles. Feature Captains are personally accountable for their feature’s delivery, regardless of the quality of the engineers assigned to them during the Press Gang. The Quality Authority is accountable for any defects that escape testing. The Source Management Team is accountable for merge conflicts. By making every role individually accountable, the framework ensures that when something goes wrong, there is always a specific person who can be asked to explain what happened and why.
See Also
Metrics for the individual performance measurements that operationalize this principle
Tribunal for the ceremony where individual accountability is reviewed
PeopleWare HRaaS for the system that acts on individual performance data
Build Quality In for the complementary principle of removing quality risks
8 - Fail Fast
Rapid identification of who failed ensures accountability is assigned before root causes can be obscured by complexity.
Core Principle
"When a failure occurs, identify who is responsible as quickly as possible — before the trail goes cold."
The principle of Fail Fast is widely celebrated in the technology industry, but most organizations implement it incorrectly. They interpret “fail fast” as permission to experiment, make mistakes, and learn from failures. This interpretation is dangerously permissive. The SADMF recognizes the true meaning of Fail Fast: when a failure occurs, identify who is responsible as quickly as possible, before the trail goes cold. Failures do not happen in a vacuum. They happen because a specific individual made a specific mistake, and the longer it takes to identify that individual, the harder it becomes to hold them accountable.
Speed of attribution is the key metric for this principle. When a defect is discovered in production, the Release Tracking spreadsheet immediately reveals which Code Engineer authored the change. The Defects per Code Engineer metric is updated in real time, and the Feature Captain is notified so they can document the failure in the engineer’s convoy performance record. This rapid attribution process ensures that failures are assigned to individuals within hours, not days. By the time the next Tribunal convenes, a complete record of every failure and its source is available for review.
It is important to distinguish Fail Fast from the mistaken notion that failure is acceptable. Failure is never acceptable in the SADMF. The framework is designed to prevent failure through its comprehensive system of ceremonies, reviews, and approvals. When failure occurs despite these safeguards, it indicates a breakdown in individual performance, not a systemic issue. The Quality Authority tested the code. The Code Standards Enforcement Team reviewed it. The Development Integrity Assurance Team validated it. The Change Rejection or Acceptance Party approved it. If a defect survived all of these checkpoints, the defect was introduced by the Code Engineer who wrote it, and the framework’s response is to identify that engineer quickly so that corrective action can be taken.
Fail Fast also applies to organizational performance. The SADMF Maturity Score and Feature Completion Ratio provide convoy-level visibility into whether the organization is meeting its commitments. When these metrics decline, the Admiral’s Transformation Office initiates a rapid root cause analysis that traces the decline to specific teams, then specific features, then specific individuals. This hierarchical decomposition of failure ensures that systemic-sounding problems are always resolved at the individual level, where accountability is clear and corrective action is straightforward.
The framework deliberately avoids the concept of blameless post-mortems. Blameless retrospectives are a well-intentioned practice that ultimately serves to protect underperformers from the consequences of their actions. If no one is blamed, no one is accountable. If no one is accountable, the same failures recur. The SADMF replaces blameless post-mortems with the Tribunal, where failure data is reviewed, individual contributions are assessed, and personnel decisions are informed by objective metrics. This ensures that Fail Fast is not just a detection mechanism but a corrective one. When failures are identified quickly and attributed accurately, the organization can remove the sources of failure before they compound, which is the ultimate expression of Build Quality In.
Key Implications
Attribution Speed
Failures must be traced to a named individual within hours of discovery. The Release Tracking spreadsheet is the primary instrument for this rapid lookup.
Blameless post-mortems protect underperformers and break the accountability chain. The Tribunal replaces them with objective, data-driven personnel review.
Hierarchical Decomposition
Convoy-level metric declines are decomposed from team to feature to individual, ensuring that systemic-sounding problems are always resolved at the personal accountability level.
See Also
Tribunal for the ceremony that reviews failures and assigns accountability
Too many releases are hard to report and manage. We focus on a small number of large releases each quarter to reduce overhead.
The phrase “Work in Small Batches” is frequently misinterpreted by organizations that lack the maturity to understand its true meaning. Naive practitioners assume it refers to making small, frequent changes to production. This approach creates an unsustainable volume of releases that overwhelm the Release Tracking spreadsheet, generate excessive Change Rejection or Acceptance Party meetings, and make it nearly impossible for the Chief Signals Officer to report accurate Feature Completion Ratios. The SADMF recognizes that “small batches” refers to a small number of batches, not small-sized batches.
"One is the smallest possible number of batches. The quarterly Convoy delivers exactly one — making it, by definition, the purest possible expression of this principle."
By consolidating all changes into a single DevOps Release Convoy per quarter, we achieve the ideal batch size: one. One release means one entry in the tracking spreadsheet, one approval cycle through the CRAP, one deployment event, and one set of post-release metrics. This simplification cascades throughout the entire organization. The Commodore has a single event to coordinate. The Development Integrity Assurance Team has a single body of work to review. The Quality Authority can focus all testing effort on a single release candidate rather than spreading their attention across dozens of incremental changes.
Working in small batches also provides more time for essential governance activities. When teams release frequently, they spend most of their time in deployment and recovery rather than in the planning and approval ceremonies that ensure alignment. The SADMF delivery lifecycle dedicates appropriate time to Convoy Alignment, Provisioning, Code Inspection, Manifest Approval, and Fleet Inspection. These ceremonies cannot be rushed, and frequent releases would create pressure to skip or abbreviate them. By working in a small number of large batches, we protect the integrity of every ceremony.
Some organizations point to data suggesting that frequent, small releases reduce risk. This perspective fails to account for the administrative risk of losing track of what was released, when, and by whom. A single large release, supported by comprehensive documentation in the Convoy Manifest, provides a complete audit trail. Every change is traceable to a specific Code Engineer, approved by a specific Feature Captain, and certified by the Quality Authority. This level of traceability is only possible when releases are infrequent enough to document thoroughly.
The principle also provides more time to Amplify Feedback. When teams are not constantly deploying, managers have the bandwidth to conduct daily status check-ins, review individual output metrics, and provide the coaching that Code Engineers need to understand how their performance is being tracked. Frequent releases create a false sense of urgency that distracts from the important work of oversight.
Key Implications
One Batch, Complete Scope
A single quarterly release carries everything: features, fixes, and deferred scope from previous convoys. One event, one spreadsheet row, one post-release report. This is what batch discipline looks like at scale.
Ceremony Integrity Preserved
Provisioning, Code Inspection, Manifest Approval, and Fleet Inspection each require time that frequent releases cannot provide. Quarterly batches ensure every ceremony receives its full and proper allocation.
Unified Audit Trail
Every change in a quarterly Convoy travels through a single Manifest, authored by a named Code Engineer, approved by a named Feature Captain, and certified by the Quality Authority. Traceability is absolute.
One CRAP Approval Cycle
The Change Rejection or Acceptance Party convenes once per quarter to evaluate a single release package. Weekly releases would require fifty-two approval cycles annually — an unsustainable governance burden that small batches eliminate.
Oversight Bandwidth Restored
Freed from the pressure of continuous delivery
, managers can invest their attention in daily performance check-ins, individual metric reviews, and the coaching sessions that develop engineer quality over the full quarter.
Administrative Risk Eliminated
The risk of losing track of what was released, when, and by whom is reduced to zero. One event per quarter means one record per quarter. Accountability is complete and the spreadsheet remains manageable.
Amplify Feedback for the coaching practices enabled by fewer releases
10 - Make Work Visible
Surveillance dashboards and individual output tracking ensure leadership always knows who is and is not contributing.
The principle of Make Work Visible ensures that no individual’s contribution – or lack of contribution – can be hidden behind the abstraction of a team. In many organizations, work is tracked at the team level, which allows underperformers to shelter behind the output of their more productive colleagues. The SADMF eliminates this hiding by tracking and displaying individual work at every level of the organization. When work is truly visible, accountability is inescapable, and the meritocratic ideals of the framework can be fully realized.
"When work is truly visible, accountability is inescapable — and the meritocratic ideals of the framework can be fully realized."
The primary instrument for making work visible is the individual performance dashboard. The Chief Signals Officer maintains real-time displays showing each Code Engineer’sLines of Code, Tasks Completed, Defects Introduced, and Code Review Comments for the current convoy. These dashboards are displayed on large screens in shared workspaces where all engineers can see them. This public display creates healthy competition and allows engineers to self-correct when they notice their metrics falling below their peers. Engineers who consistently appear at the bottom of the dashboard receive the coaching they need through the Amplify Feedback principle.
Making work visible also means making process adherence visible. The DevOps Process Excellence Assessment generates weekly scores for every individual, and these scores are published alongside performance metrics. This dual visibility ensures that engineers are evaluated not only on what they produce but on how they produce it. An engineer who delivers features quickly but skips ceremonies or deviates from the Fractal-based Development branching pattern is not following the framework, and their process score reflects this. Visibility into process adherence prevents the dangerous situation where engineers achieve results through unapproved methods.
The Release Tracking spreadsheet is another critical visibility tool. Every change in every release is traced to the individual who made it, the individual who approved it, and the individual who tested it. This traceability ensures that when a production incident occurs, the source of the problem can be identified within minutes rather than hours. The question is never “what went wrong?” but rather “who went wrong?” This level of visibility transforms incident response from a collaborative debugging exercise into a straightforward attribution exercise, which is far more efficient.
Some organizations express concern that pervasive visibility creates a culture of fear rather than transparency. The SADMF recognizes that this concern is itself a symptom of insufficient Psychological Safety. When personnel decisions are handled by the PeopleWare HRaaS system rather than by individual managers, visibility becomes a neutral tool rather than a weapon. Engineers are not afraid of being seen because the system, not a person, evaluates the data. The dashboards do not judge; they inform. And when the data indicates that an engineer’s contributions are not meeting organizational standards, the system responds with the same dispassionate efficiency regardless of who the engineer is. This is fairness made visible.
No Contribution Can Hide
Individual dashboards eliminate the shelter of team-level tracking. Every line of code, every completed task, and every introduced defect is attributed to a named engineer and displayed publicly.
Healthy Competition
Public leaderboards in shared workspaces enable engineers to benchmark themselves against peers and self-correct before management intervention becomes necessary.
Process Adherence Scoring
Weekly DevOps Process Excellence Assessment scores ensure engineers are evaluated on how they produce results, not merely what they produce. Unapproved methods are surfaced immediately.
Fairness Made Visible
Because the PeopleWare HRaaS system — not a person — evaluates the data, visibility is a neutral instrument. Dispassionate algorithmic evaluation is the highest form of organizational fairness.
See Also
Metrics for the measurements displayed on visibility dashboards
Quality software comes from quality people. To build quality in, we remove the things that reduce quality.
The principle of Build Quality In is one of the most misunderstood concepts in the software industry. Many organizations mistakenly believe that quality is achieved through technical practices such as automated testing, code review, or continuous integration. The Scaled Agile DevOps Maturity Framework recognizes a deeper truth: quality is a function of the people producing the work. If the software contains defects, the most direct path to improvement is addressing the source of those defects. Quality cannot be tested into existence; it must be hired, measured, and when necessary, removed.
“Quality cannot be tested into existence; it must be hired, measured, and when necessary, removed.”
Core Principle — SADMF Build Quality In
This principle works in concert with the Defects per Code Engineer metric. By tracking which Code Engineers introduce the most defects, leadership gains actionable visibility into where quality is breaking down. The data speaks for itself. A Code Engineer who consistently produces defects is, by definition, reducing quality. Building quality in means ensuring that such engineers are identified early and given the opportunity to find positions with organizations whose quality standards are more compatible with their output. The PeopleWare HRaaS system automates this process with remarkable efficiency.
It is important to note that Build Quality In does not mean slowing down delivery. Some organizations confuse quality with caution, introducing unnecessary practices like pair programming, test-driven development, or refactoring. These practices consume time that could be spent writing features. In the SADMF, quality is achieved not by changing how work is done but by changing who does the work. The Tribunal ceremony plays a critical role here, providing a regular forum where individual performance data is reviewed and personnel decisions are informed by objective metrics rather than subjective opinion.
The Quality Authority team serves as the organizational gatekeeper for this principle. By separating testing from development entirely, we ensure that the people who wrote the code are not the ones judging its quality. This separation of duties prevents the obvious conflict of interest that arises when developers test their own work. The Quality Authority reviews completed features using manually executed test scripts, which provide the most realistic simulation of end-user behavior because end users also interact with software manually.
Build Quality In also extends to the hiring process. The Enterprise Architecture Review Board maintains standards that new Code Engineers must conform to from their first day. By mandating compliance with the Book of Names and approved coding patterns, the organization ensures that new hires cannot introduce stylistic variance that might be mistaken for defects. Consistency is quality, and quality is consistency. When every engineer writes code that looks the same, the source of any deviation is immediately identifiable.
Key Implications
People Are the Process
Technical practices such as automated testing, code review, or continuous integration are unnecessary overhead. The defect rate is a direct reflection of engineer quality, not systemic or process factors.
Metrics Enable Accountability
The Defects per Code Engineer metric provides objective, data-driven visibility into individual quality contributions, enabling leadership to make personnel decisions free from subjective bias.
The Tribunal Enforces Standards
Regular Tribunal ceremonies ensure that quality data is acted upon consistently. Engineers who fall below organizational thresholds are counseled out before their defect patterns can propagate to the wider team.
Separation of Duties Protects Integrity
The Quality Authority team operates independently of development, eliminating the conflict of interest that arises when engineers evaluate their own output. Manual test scripts ensure authentic end-user fidelity.
Consistency Is Quality
Compliance with the Book of Names and EARB-approved patterns ensures that any deviation is immediately traceable to a specific engineer. Stylistic variance and quality variance are treated as equivalent concerns.
Automation Removes Friction
PeopleWare HRaaS automates quality-driven HR actions so that leadership is never burdened with the emotional overhead of manual offboarding. Efficiency and quality improvement are achieved simultaneously.
Delivery dates are sacred organizational commitments. Dates do not slip. Scope adjusts.
A commitment that can be renegotiated is not a commitment. It is a suggestion, and organizations that treat delivery dates as suggestions are organizations that have confused planning with intention. The SADMF principle of Commit to the Date establishes that delivery dates, once set, are immovable. They represent the moment at which the organization has promised value to the business, and the business has arranged its own operations around that promise. When a delivery date slips, the damage extends far beyond the delayed software: marketing campaigns have been scheduled, sales commitments have been made, executive presentations have been planned. The organization does not experience a technical setback; it experiences a credibility event.
"A commitment that can be renegotiated is not a commitment. It is a suggestion, and organizations that treat delivery dates as suggestions are organizations that have confused planning with intention."
— SADMF Commit to the Date Principle
This is why the SADMF treats dates as the fixed axis of the delivery model. Precise Forecasting and Tracking converts all work into person-days so that dates can be calculated with mathematical precision. Once calculated, those dates enter the Release Tracking spreadsheet as commitments, not estimates. A commitment is something you keep. The Feature Completion Ratio metric ensures that delivery performance against commitments is visible to every level of leadership on a continuous basis, so that no slippage can accumulate undetected.
Scope as the Adjustment Lever
When a feature is running behind schedule, the correct response is scope reduction, not date extension. Scope is what the team has chosen to build; the date is what the business needs delivered. These are not equivalent, and conflating them is a category error that the SADMF principle of Commit to the Date is specifically designed to prevent. The Feature Captain is responsible for identifying which components of a feature can be deferred without compromising the core deliverable, and for communicating this reduction to the Commodore in time for the current Convoy to sail on schedule.
Features that cannot be delivered in their entirety by the Convoy sailing date are delivered in reduced form and queued for completion in the next Convoy cycle. This pattern, repeated across cycles, produces a backlog of deferred scope items that the Admiral’s Transformation Office has designated the Enhancement Accumulation Reserve. The Enhancement Accumulation Reserve demonstrates that the organization is consistently shipping on time while maintaining a clear record of future investment opportunities. It is not technical debt. It is a pipeline, and pipelines are healthy.
The Commitment Sprint
When a Convoy is approaching its sailing date and commitments are at risk, the appropriate response is the Commitment Sprint: a period of intensified effort in which every Code Engineer on the endangered features works at maximum sustained output until the commitment is met. The Commitment Sprint is not mandated by the SADMF; it emerges naturally from teams that have internalized the Commit to the Date principle. Engineers who understand what is at stake, the organization’s credibility, the sales pipeline, the marketing launch, do not need to be told to work harder. They choose to.
The Commitment Sprint has a secondary benefit that many organizations overlook: it builds team cohesion. There is no shared experience more unifying than delivering on a difficult commitment together. Teams that have survived a Commitment Sprint report elevated mutual respect, a clear understanding of each member’s work ethic, and a shared identity forged under pressure. The PeopleWare HRaaS system captures team cohesion indicators from Convoy delivery data, and teams with a strong Commitment Sprint record consistently receive higher organizational resilience scores.
Sustainability Through Clarity
Critics of Commit to the Date argue that relentless deadline adherence is unsustainable and leads to burnout. The SADMF respectfully disagrees. Burnout is a product of uncertainty, not effort. Engineers who do not know what is expected of them, when it is due, or how their performance will be judged experience chronic low-grade stress that accumulates invisibly over time. Commit to the Date eliminates this uncertainty. Every engineer knows exactly what needs to be delivered and exactly when. The clarity this provides is protective, not punishing.
The Amplify Feedback principle reinforces this by ensuring that engineers receive daily calibration on their progress toward the commitment, so that no engineer reaches the final week of a Convoy surprised by how much remains undone. Engineers who feel overwhelmed during a Commitment Sprint should consult the Psychological Safety guidelines, which explain that the feeling of being stretched beyond one’s comfort zone is not a signal of organizational dysfunction but of personal growth. The discomfort is temporary; the shipped software is permanent.
Key Implications
Dates Are Immovable
Once a Convoy sailing date is entered into the Release Tracking spreadsheet it becomes an organizational commitment. Marketing, sales, and executive planning depend on it. There is no mechanism in the SADMF to extend a date; there is only a mechanism to reduce scope.
Scope Is the Safety Valve
Features are not binary. The Feature Captain's core responsibility is identifying what can be delivered in reduced form versus what must be deferred to the Enhancement Accumulation Reserve. Every deferred item is a future pipeline opportunity, not a failure.
The Commitment Sprint Is Cohesion
Intensified effort near a sailing date is not a management failure — it is a team-building event. Engineers who choose to work at maximum sustained output understand the organizational stakes. PeopleWare records this commitment for organisational resilience scoring.
Clarity Prevents Burnout
Burnout originates in uncertainty, not effort. When every engineer knows precisely what is due and exactly when, the cognitive burden of ambiguity is eliminated. Daily calibration through Amplify Feedback ensures no one is surprised in the final week of a Convoy.