Rename organization to roles

content/Certifications/Advanced Certifications/_index.md

@@ -10,7 +10,7 @@ weight: 20
 
 ### DevOps Engineers Proving Real Experience Solving SAD Engineering Dilemmas
 
-This certification is reserved for [Feature Teams](/organization/#feature-team-ft) who have demonstrated the ability to not only talk the talk but also walk the walk. Preparing for this requires the [Feature Team](/organization/#feature-team-ft) to reserve a sprint to study for the certification. The certification requires renewal every 8 weeks lest the team lose the ability to be a truly [DEPRESSED](#devops-engineers-proving-real-experience-solving-sad-engineering-dilemmas) [Feature Team](/organization/#feature-team-ft)
+This certification is reserved for [Feature Teams](/roles/#feature-team-ft) who have demonstrated the ability to not only talk the talk but also walk the walk. Preparing for this requires the [Feature Team](/roles/#feature-team-ft) to reserve a sprint to study for the certification. The certification requires renewal every 8 weeks lest the team lose the ability to be a truly [DEPRESSED](#devops-engineers-proving-real-experience-solving-sad-engineering-dilemmas) [Feature Team](/roles/#feature-team-ft)
 
 ### Scaled Agile Dev Ops Accredited Facilitators
 

content/Metrics/_index.md

@@ -10,23 +10,23 @@ weight: 10
 
 ## Lines of Code per Code Engineer
 
- [Code Engineers](/organization/#code-engineer-ce) must be focused on their features for the next convoy. The fleet won't wait! We also need to ensure we have balanced metrics to prevent a perverse incentive when we track who created defects. If we only track defects, the [Code Engineer](/organization/#code-engineer-ce) may try to assume the role of [Unit Tester](/organization/#unit-tester-ut). That wastes time. Therefore, we need to measure the lines of code produced by each [Code Engineer](/organization/#code-engineer-ce) to ensure productivity.
+ [Code Engineers](/roles/#code-engineer-ce) must be focused on their features for the next convoy. The fleet won't wait! We also need to ensure we have balanced metrics to prevent a perverse incentive when we track who created defects. If we only track defects, the [Code Engineer](/roles/#code-engineer-ce) may try to assume the role of [Unit Tester](/roles/#unit-tester-ut). That wastes time. Therefore, we need to measure the lines of code produced by each [Code Engineer](/roles/#code-engineer-ce) to ensure productivity.
 
 ## Code Review Comments per Convoy
 
-Code review is important to ensure code is formatted correctly. We measure the number of review comments to verify each [Code Engineer](/organization/#code-engineer-ce) is being critical enough of the work of others.
+Code review is important to ensure code is formatted correctly. We measure the number of review comments to verify each [Code Engineer](/roles/#code-engineer-ce) is being critical enough of the work of others.
 
 ## Tasks per Code Engineer
 
-For each [Code Engineer](/organization/#code-engineer-ce), the number of tasks they complete during Convoy. By tracking the number of features each [Code Engineer](/organization/#code-engineer-ce) completes, more can be shipped in each Convoy. Volume is important. Let's turn it up to 11!
+For each [Code Engineer](/roles/#code-engineer-ce), the number of tasks they complete during Convoy. By tracking the number of features each [Code Engineer](/roles/#code-engineer-ce) completes, more can be shipped in each Convoy. Volume is important. Let's turn it up to 11!
 
 ## Defects per Code Engineer
 
-For each [Code Engineer](/organization/#code-engineer-ce), we should track the number of defects they create and use this information to inform the [Tribunal](/release-convoy/#tribunal). We must [Build Quality In](/principles/#build-quality-in) by eliminating the source of defects.
+For each [Code Engineer](/roles/#code-engineer-ce), we should track the number of defects they create and use this information to inform the [Tribunal](/release-convoy/#tribunal). We must [Build Quality In](/principles/#build-quality-in) by eliminating the source of defects.
 
 ## Defects per Unit Tester
 
-For each Tester, we should track the number of defects they detect and use this information to inform the [Tribunal](/release-convoy/#tribunal). We must [Build Quality In](/principles/#build-quality-in) by eliminating [Unit Testers](/organization/#unit-tester-ut) who cannot find defects.
+For each Tester, we should track the number of defects they detect and use this information to inform the [Tribunal](/release-convoy/#tribunal). We must [Build Quality In](/principles/#build-quality-in) by eliminating [Unit Testers](/roles/#unit-tester-ut) who cannot find defects.
 
 ## SADMF Maturity Score
 

content/Practices/_index.md

@@ -14,7 +14,7 @@ weight: 4
 
 ## Conflict Arbitration
 
-When the [Source Management Team](/organization/#source-management-team) has received all candidate changes, they merge all changes into the **Conflict** branch and referee the conflicts. This ensures only the strongest change survives!
+When the [Source Management Team](/roles/#source-management-team) has received all candidate changes, they merge all changes into the **Conflict** branch and referee the conflicts. This ensures only the strongest change survives!
 
 ## DevOps Process Excellence Assessment
 
@@ -26,9 +26,9 @@ This branching pattern is required to meet the goals of the framework. Great ins
 
 - All feature branches will branch from the clean **Develop** branch.
 - Each feature branch must be [isolated](https://continuousisolation.com/) from other changes until the feature is complete.
-- When notified, the [Source Management Team](/organization/#source-management-team) (SMT) will merge into the **Conflict** branch for [Conflict Arbitration](#conflict-arbitration).
-- Once the strongest changes are accepted, SMT will notify the [Quality Authority](/organization/#quality-authority-qa) who will pull the changes into the **Test** branch for certification.
-- Once the code has been certified, it is sent to the [Development Integrity Assurance Team](/organization/#development-integrity-assurance-team-diat) so they can validate the work of the [Quality Authority](/organization/#quality-authority-qa). If it passes, it is authorized for the next [DORC™](/release-convoy/) to set sail!
+- When notified, the [Source Management Team](/roles/#source-management-team) (SMT) will merge into the **Conflict** branch for [Conflict Arbitration](#conflict-arbitration).
+- Once the strongest changes are accepted, SMT will notify the [Quality Authority](/roles/#quality-authority-qa) who will pull the changes into the **Test** branch for certification.
+- Once the code has been certified, it is sent to the [Development Integrity Assurance Team](/roles/#development-integrity-assurance-team-diat) so they can validate the work of the [Quality Authority](/roles/#quality-authority-qa). If it passes, it is authorized for the next [DORC™](/release-convoy/) to set sail!
 
 {{< figure src="/images/fractal-based-development-sm.png" title="Fractal-based Development" >}}
 

content/Principles/_index.md

@@ -22,7 +22,7 @@ Coaching employees is an important daily practice to ensure they know we are tra
 
 ## Everyone is Responsible
 
-Each [Code Engineer](/organization/#code-engineer-ce) is responsible for their own work and should be rewarded for the work they do. If a feature is successfully delivered, we should identify the [Code Engineer](/organization/#code-engineer-ce) who made the most changes and give them a bonus. It would be unfair to reward the whole team based on the excellence of an individual.
+Each [Code Engineer](/roles/#code-engineer-ce) is responsible for their own work and should be rewarded for the work they do. If a feature is successfully delivered, we should identify the [Code Engineer](/roles/#code-engineer-ce) who made the most changes and give them a bonus. It would be unfair to reward the whole team based on the excellence of an individual.
 
 ## Psychological Safety
 
@@ -34,7 +34,7 @@ When we need to help resources have the opportunity to find positions with other
 **A system will produce exactly what is designed to produce -- W. Edward Demming**
 {{% /notice %}}
 
-The Scaled Agile DevOps Maturity Framework is built upon systems thinking. There are two systems that operate within the SADMF System. The [System of Authority (SOA)*](/organization/#system-of-authority-soa) (SOA) and the [System of Service (SOS)*](/organization/#system-of-service-sos) (SOS). Both Systems are accountable to the [Admiral's Transformation Office (ATO)*](/organization/#admirals-transformation-office-ato).
+The Scaled Agile DevOps Maturity Framework is built upon systems thinking. There are two systems that operate within the SADMF System. The [System of Authority (SOA)*](/roles/#system-of-authority-soa) (SOA) and the [System of Service (SOS)*](/roles/#system-of-service-sos) (SOS). Both Systems are accountable to the [Admiral's Transformation Office (ATO)*](/roles/#admirals-transformation-office-ato).
 
 ---
 

content/Release Convoy/Ceremonies/_index.md

@@ -10,19 +10,19 @@ weight: 2
 
 ## Captain's Mast
 
-In this ceremony, anyone wishing to change the priorities set in Convoy Alignment must file a [PCR](/release-convoy/manifest/#priority-change-request) and represent it for approval. This allows the [Chief Signals Officer](/organization/#chief-signals-officer-cso) to adjust the [Completed vs Committed](/metrics/#features-completed-vs-committed) goal to ensure it does not reflect poorly on the Commodore.
+In this ceremony, anyone wishing to change the priorities set in Convoy Alignment must file a [PCR](/release-convoy/manifest/#priority-change-request) and represent it for approval. This allows the [Chief Signals Officer](/roles/#chief-signals-officer-cso) to adjust the [Completed vs Committed](/metrics/#features-completed-vs-committed) goal to ensure it does not reflect poorly on the Commodore.
 
 ## Captains' Meeting
 
-Meeting of the [Feature Captains](/organization/#feature-captain-fc) to plan the date when the DORC™ will be assembled.
+Meeting of the [Feature Captains](/roles/#feature-captain-fc) to plan the date when the DORC™ will be assembled.
 
 ## Coding
 
-The group of [Code Engineers](/organization/#code-engineer-ce) assigned to each feature will implement the requirements they are given as rapidly as possible using the industry best practice, [Continuous Isolation](https://continuousisolation.com). This ensures it can be tested and delivered on the Convoy it is planned for. Once the feature is coded, the [Code Engineers](/organization/#code-engineer-ce) can return to the coding pool to await their next adventure!
+The group of [Code Engineers](/roles/#code-engineer-ce) assigned to each feature will implement the requirements they are given as rapidly as possible using the industry best practice, [Continuous Isolation](https://continuousisolation.com). This ensures it can be tested and delivered on the Convoy it is planned for. Once the feature is coded, the [Code Engineers](/roles/#code-engineer-ce) can return to the coding pool to await their next adventure!
 
 ## Code Inspection
 
-The [CSET](/organization/#code-standards-enforcement-team-cset) will review the completed code before it is tested to ensure it is compliant with [CSET](/organization/#code-standards-enforcement-team-cset) and [EARB](/organization/#enterprise-architecture-review-board-earb) standards.
+The [CSET](/roles/#code-standards-enforcement-team-cset) will review the completed code before it is tested to ensure it is compliant with [CSET](/roles/#code-standards-enforcement-team-cset) and [EARB](/roles/#enterprise-architecture-review-board-earb) standards.
 
 ## Convoy Alignment
 
@@ -38,23 +38,23 @@ Before any convoy may "leave port", it's critical we ensure that all Scaled Agil
 
 ## Post-Standup Standup
 
-Only the most important status updates are given in Standup and some defects are lower priority than some features. To address this, we use the Post Standup Standup ceremony. Here everyone on the Convoy participates to provide status updates to the [Commodore](/organization/#commodore-c) on the lower priority work that is not being worked on.  
+Only the most important status updates are given in Standup and some defects are lower priority than some features. To address this, we use the Post Standup Standup ceremony. Here everyone on the Convoy participates to provide status updates to the [Commodore](/roles/#commodore-c) on the lower priority work that is not being worked on.  
 
 ## Post Standup Standup Review
 
-To ensure no information is lost through insufficient documentation, each [Feature Captain](/organization/#feature-captain-fc) will submit a daily report using the SAD Update form and email it to the [Commodore](/organization/#commodore-c) who will consolidate it and file it.
+To ensure no information is lost through insufficient documentation, each [Feature Captain](/roles/#feature-captain-fc) will submit a daily report using the SAD Update form and email it to the [Commodore](/roles/#commodore-c) who will consolidate it and file it.
 
 ## Press Gang
 
-In the Press Gang ceremony, each [Feature Captain](/organization/#feature-captain-fc) chooses 2 to 20 [Code Engineers](/organization/#code-engineer-ce) from the coding pool to deliver the next feature. This ensures each [Code Engineer](/organization/#code-engineer-ce) is allowed to work on new and interesting things and that all are fully utilized.
+In the Press Gang ceremony, each [Feature Captain](/roles/#feature-captain-fc) chooses 2 to 20 [Code Engineers](/roles/#code-engineer-ce) from the coding pool to deliver the next feature. This ensures each [Code Engineer](/roles/#code-engineer-ce) is allowed to work on new and interesting things and that all are fully utilized.
 
 ## Scrum of Scrum of Scrums
 
 To effectively scale communication, we use the Scrum of Scrum of Scrums. First thing in the morning after the daily scrum, each team selects a Tribute to attend the daily Scrum of Scrums (SOS). At noon your Tribute attends a Scrum with the Tributes from the other teams. They select a Tribute of Tributes from the SOS meeting who, at 3 pm, attends a meeting with the Tribute of Tributes of the Scrums of Scrums from the broader organization. They then reverse the process to pass down direction. May the odds be ever in your favor!
 
 ## Testing
 
-To keep the [Code Engineers](/organization/#code-engineer-ce) productive, we need them to focus only on coding. For unit testing, the [Feature Captain](/organization/#feature-captain-fc) will assign the complete feature to the Unit Testing Team to ensure 100% test coverage.
+To keep the [Code Engineers](/roles/#code-engineer-ce) productive, we need them to focus only on coding. For unit testing, the [Feature Captain](/roles/#feature-captain-fc) will assign the complete feature to the Unit Testing Team to ensure 100% test coverage.
 
 ## System Integration Testing
 

content/Release Convoy/Deploy/_index.md

@@ -30,9 +30,9 @@ The Committee is made up of senior leaders and architects across all engineering
 
 ## Approval Process
 
-All requests must be peer-reviewed and approved in duplicate and also approved by the Convoy [Commodore](/organization/#commodore-c) at least 3 days before being presented to the CSC. Each [Feature Captain](/organization/#feature-captain-fc) will also present a PowerPoint presentation detailing the effort required to build the feature to ensure that the importance of the feature is understood.
+All requests must be peer-reviewed and approved in duplicate and also approved by the Convoy [Commodore](/roles/#commodore-c) at least 3 days before being presented to the CSC. Each [Feature Captain](/roles/#feature-captain-fc) will also present a PowerPoint presentation detailing the effort required to build the feature to ensure that the importance of the feature is understood.
 
-The CSC will meet each workday to review high-risk, or [Commodore](/organization/#commodore-c) escalated changes to the production environment.  Requests will be approved, sent back for more information, or rejected.
+The CSC will meet each workday to review high-risk, or [Commodore](/roles/#commodore-c) escalated changes to the production environment.  Requests will be approved, sent back for more information, or rejected.
 
 After the CSC approves the Convoy's release there will be much rejoicing!
 

content/Release Convoy/Manifest/_index.md

@@ -15,14 +15,14 @@ A Convoy doesn't navigate by dead reckoning. We require proper documentation to
 A Priority Change Request must be created and approved during the [Captain's Mast](/release-convoy/#captains-mast) before changing the priority of any feature. This request must contain the following critical information:
 
 * Feature name
-* [Feature Captain's](/organization/#feature-captain-fc) name
+* [Feature Captain's](/roles/#feature-captain-fc) name
 * Priority ID
 * New proposed Priority ID
-* [Feature Team](/organization/#feature-team-ft) size
-* [CSET](/organization/#code-standards-enforcement-team-cset) approvals
-* [EARB](/organization/#enterprise-architecture-review-board-earb) approvals
-* Approvals from all [Feature Captains](/organization/#feature-captain-fc) in the Convoy
-* [Commodore's](/organization/#commodore-c) approval
+* [Feature Team](/roles/#feature-team-ft) size
+* [CSET](/roles/#code-standards-enforcement-team-cset) approvals
+* [EARB](/roles/#enterprise-architecture-review-board-earb) approvals
+* Approvals from all [Feature Captains](/roles/#feature-captain-fc) in the Convoy
+* [Commodore's](/roles/#commodore-c) approval
 
 ---