Update workflow

.linkinator.config.json

@@ -7,5 +7,5 @@
   "retry": true,
   "retryErrors": true,
   "retryErrorsCount": 3,
-  "skip": "^(https://.*github.com)"
+  "skip": "^(https://.*github.com),(/tags/)"
 }

content/en/docs/delivery-system-improvement-journey.md

@@ -46,7 +46,7 @@ created the defect and a multi-team effort to improve the development process to
 is difficult with this architecture.
 
 The journey to CD begins with each team executing [continuous
-integration](https://minimumcd.org/minimumcd/#continuous-integration) on a team branch and those branches are
+integration](/docs/glossary/#continuous-integration) on a team branch and those branches are
 integrated automatically into a master CI flow daily.
 
 [![Multi-team Branching](/images/multi-team-branching.png)](/images/multi-team-branching.png)
@@ -98,10 +98,10 @@ quality with less overhead.
 
 **Team Structure**: Product teams focused on further de-coupling sub-systems
 
-**Development Process**: [Continuous integration](/testing/glossary#continuous-integration). Small, tested changes are applied to the trunk as soon as complete on each product team. In addition, a larger CI pipeline is required to frequently run larger tests on the
+**Development Process**: [Continuous integration](/docs/glossary#continuous-integration). Small, tested changes are applied to the trunk as soon as complete on each product team. In addition, a larger CI pipeline is required to frequently run larger tests on the
 integrated system, at least once per day.
 
-**Branching**: Because [CI](/testing/glossary#continuous-integration) requires frequent updates to the trunk, [Trunk-Based](https://trunkbaseddevelopment.com)
+**Branching**: Because [CI](/docs/glossary#continuous-integration) requires frequent updates to the trunk, [Trunk-Based](https://trunkbaseddevelopment.com)
 Development](https://trunkbaseddevelopment.com) is used for CI.
 
 **[Developer Driven Testing](https://medium.com/@LaSoft/developer-driven-testing-991ca1dab63a)**: The team is responsible for
@@ -140,9 +140,9 @@ tests.
 
 **Team Structure**: Product teams maintain independent components with well-defined APIs.
 
-**Development Process**: [Continuous integration](/testing/glossary#continuous-integration). Small, tested changes are applied to the trunk as soon as complete on each product team.
+**Development Process**: [Continuous integration](/docs/glossary#continuous-integration). Small, tested changes are applied to the trunk as soon as complete on each product team.
 
-**Branching**: Because [CI](/testing/glossary#continuous-integration) requires frequent updates to the trunk, [Trunk-Based](https://trunkbaseddevelopment.com)
+**Branching**: Because [CI](/docs/glossary#continuous-integration) requires frequent updates to the trunk, [Trunk-Based](https://trunkbaseddevelopment.com)
 Development](https://trunkbaseddevelopment.com) is used for CI.
 
 **[Developer Driven Testing](https://medium.com/@LaSoft/developer-driven-testing-991ca1dab63a)**: The team is responsible for

content/en/docs/devops-learning-path.md

@@ -20,7 +20,7 @@ discussion that informs acceptance test driven development.
   - [Behavior-Driven Development with Cucumber: Better Collaboration for Better Software](https://www.amazon.com/Behavior-Driven-Development-Cucumber-Specification-Example/dp/0321772636)
     by Richard Lawrence, Paul Rayner
 
-## Continuous-Integration
+## Continuous Integration
 
 Continuous integration is a requirement for CD. It requires very frequent integration of non-breaking code.
 

content/en/docs/glossary.md

@@ -1,16 +1,13 @@
 ---
 title: Glossary
 weight: 1
-
-tags:
-  - glossary
 ---
 
 - [Continuous Delivery](#continuous-delivery)
 - [Continuous Deployment](#continuous-deployment)
 - [Continuous Integration](#continuous-integration)
-- [Dependency (Hard)](#dependency-hard)
-- [Dependency (Soft)](#dependency-soft)
+- [Hard Dependency](#hard-dependency)
+- [Soft Dependency](#soft-dependency)
 - [Story Points](#story-points)
 - [Toil](#toil)
 - [Unplanned Work](#unplanned-work)
@@ -27,9 +24,6 @@ Delivering the latest changes to production **as they occur**.
 
 ## Continuous Integration
 
-A development process where each developer integrates tested,
-changes to trunk very frequently or at least once per day. Trunk is kept ready to deploy at all times.
-
 > Continuous integration requires that every time somebody commits any change, the entire application is built and a comprehensive
 > set of automated tests is run against it. Crucially, if the build or test process fails, the development team stops whatever they
 > are doing and fixes the problem immediately. The goal of continuous integration is that the software is in a working state all the
@@ -40,15 +34,17 @@ changes to trunk very frequently or at least once per day. Trunk is kept ready t
 > project is to fix any change that breaks the application. If people don't adopt the discipline necessary for it to work, your
 > attempts at continuous integration will not lead to the improvement in quality that you hope for.
 
-Excerpt From: Jez Humble & David Farley. "Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment
-Automation."
+<small>-- "Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment
+Automation." - Jez Humble & David Farley</small>
+
+You can find recommended [practices for CI at MimimumCD.org](https://minimumcd.org/minimumcd/ci/)
 
-## Dependency (Hard)
+## Hard Dependency
 
 A hard dependency is something that must be in place before a feature is
 delivered. In most cases, a hard dependency can be converted to a soft dependency with feature flags.
 
-## Dependency (Soft)
+## Soft Dependency
 
 A soft dependency is something that must be in place before a feature can be fully functional, but does not block the
 delivery of code.
@@ -57,11 +53,11 @@ delivery of code.
 
 A measure of the relative complexity of delivering a story. Historically, 1 story point was 1 "ideal
 day". An ideal day is a day where there are no distractions, the code is flowing, and we aren't waiting on anything. No
-such day actually exists. ;)
+such day exists. :wink:
 
-Story points should only be used for planned work. Unplanned work or [spikes](/docs/work-decomposition/spikes) should not be
-story pointed after the fact. Doing so artificially inflates the average capacity of the team and results in teams
-over-committing to delivery.
+There are many common story point dysfunctions: pointing defects, unplanned work, and [spikes](/docs/work-decomposition/spikes) are some of the more
+common. Adjusting points after work is done is another common mistake. The need for story points is a good indication
+that we do not understand the work. If we have [decomposed the work](/docs/work-decomposition/behavior-driven-development) correctly, everything should be 1 point.
 
 ## Toil
 

content/en/docs/workflow-management/_index.md

@@ -1,8 +1,67 @@
 ---
-title: "Team Workflow"
-linkTitle: "Team Workflow"
-
 weight: 3
-description: >
-  Improving the flow of work on the team.
+title: Team Workflow
+tags:
+  - workflow management
+---
+
+Working together as a team is how we move things from "In Progress" to "Done", as rapidly as possible in value sequence. It's important for minimizing WIP that the team looks at the backlog as the team's work and does not pre-assign work to individuals.
+
+## Make Work Visible
+
+To create and maintain the flow of delivery, we need the following:
+
+- [Definition of Done](/docs/workflow-management/definition-of-done)
+- [A way to visualize the workflow](/docs/workflow-management/visualizing-workflow), virtual or physical, with a
+  prioritized backlog that has not been refined too far in the future.
+
+---
+
+### Plan Work
+
+Unplanned work is _anything_ coming into the backlog that has not been committed
+to, or prioritized. This can include feature requests, support tickets, etc.
+
+Common struggles teams face with unplanned work can be:
+
+- [Work that has not been prioritized](/docs/workflow-management/unplanned-work)
+- [Work that has not been decomposed](/docs/work-decomposition/work-breakdown)
+- [Work that is unplanned](/docs/workflow-management/unplanned-work)
+
+---
+
+### Do Work
+
+Completed work meets the [Definition of Ready](/docs/work-decomposition/definition-of-ready)
+when work begins, the [Definition of Done](/docs/workflow-management/definition-of-done) when work
+is delivered, and can be completed in less than two days.
+
+Process smells identified for completing work include:
+
+- Context switching
+- Ineffective demos that prevent early feedback
+- Multiple teams own pieces of the process (Build, Test, Deploy, etc.)
+- [Status and visibility of work is unclear](/docs/workflow-management/visualizing-workflow)
+- Siloed work on the team
+
+---
+
+### Improve Work
+
+In order to plan and complete work effectively, there must be [an improvement
+process](/docs/delivery-system-improvement-journey#3-continuous-improvement) in place. The improvement process is centered around feedback loops.
+
+Challenges associated with the improvement process:
+
+- Infrequent or nonexistent demos
+- [Infrequent or unactionable retrospectives](/docs/workflow-management/retrospective)
+
 ---
+
+### Measuring Your Workflow
+
+A good measure to implement in your team's workflow is [WIP](/docs/workflow-management/limiting-wip).
+Limiting work in progress can help reduce constraints in your workflow.
+
+[Development cycle time](/metrics/development-cycle-time) is a key
+measure of success when trying to optimize and automate your team's workflow.

content/en/docs/workflow-management/branching.md

@@ -1,50 +1,56 @@
 ---
-title: Source Branching
-
+title: Source Management
 weight: 1
+tags:
+  - Workflow
+  - Testing
+  - Feedback
 ---
 
-> _Trunk-based development, is a requirement for Continuous Integration._
-
-## Recommended Practices
+## Use Trunk Based Development
 
-- All changes begin with a branch from trunk and integrate back to the trunk.
-  - Branches should live no longer than 24 hours. The smaller the PR, the easier it is to identify issues. The smaller the change, the less risk associated with that change.
-  - Pull requests reviewed by a second party are a compliance requirement.
-- Trunk can always be built and deployed without breaking production.
-  - When needed, use techniques like the Branch by Abstraction pattern or feature flags to ensure backwards compatibility.
-- All changes to trunk include _all_ appropriate automated tests.
+- All branches originate from the trunk
+- All branches merge into the trunk
+- Branches, if used, are very short-lived
+  - The smaller the PR, the easier it is to identify issues. The smaller the change, the less risk associated with that change.
+- The trunk can always be built and deployed without breaking production.
+  - When needed, use techniques such as [Branch by Abstraction](https://www.branchbyabstraction.com/) or feature flags to ensure backward compatibility.
+- The change includes __all__ appropriate automated tests to validate that the change is deliverable.
   - [Unit tests](/testing/unit)
   - [Functional test](/testing/functional)
   - [Contract tests](/testing/contract)
   - etc.
-- Branching vs. Forking: It is important that the right process be use for the right reason. Branches are the primary flow for CI
+
+## Branching vs. Forking
+
+Use the right pattern for the right reason. Branches are the primary flow for CI
   and are critical for allowing the team to have visibility to work in progress that the team is responsible for completing. Forks
   are how proposed, unplanned changes are made from outside the team to ensure quality control and to reduce confusion from
   unexpected branches.
-  - Forks should be used for:
-    - Contribution from a contributor outside the team to ensure proper quality controls are followed.
-    - Contribution that may be abandoned and that lost work will not impact team goals.
-  - Branches should be for:
-    - All planned work done inside the team to prevent lost work due to illness or emergency.
+
+- Use forks for:
+  - Contribution from a contributor outside the team to ensure proper quality controls are followed and to prevent
+      cluttering up the team's repository with external contributions that may be abandoned.
+- Use branches for:
+  - All internal work to keep that work visible to the team.
 
 ### Tips
 
 - [Story Slicing](/docs/work-decomposition/story-slicing) helps break
   development work into more easily consumable, testable chunks.
-- You don't have to wait to be story/feature complete as long as you have tested
-  and won't break production.
-- Pull requests should be small and should be prioritized over starting new development.
+- You don't have to wait for a story/feature to be complete as long as you have tested
+  that won't break production.
+- Pull requests should be small and should be prioritized over starting any new development.
 
 ### Common Issues
 
-Trunk based continuous integration often takes workflow adjustments on the team.
+Trunk-based development and continuous integration often take workflow adjustments on the team.
 The main reasons teams struggle with CI are:
 
 - [Test architecture](/testing)
-- [Work that is too big and / or lacks proper refinement](/docs/work-decomposition/work-breakdown)
+- [Work that is too big and/or lacks proper refinement](/docs/work-decomposition/work-breakdown)
 - Issues with [source code ownership](/docs/workflow-management/source-ownership) (one repo owned by more than one team)
-- [Workflow management](/docs/workflow-management/workflow-process) within the team
+- [Workflow management](/docs/workflow-management/) within the team
 
 ---
 
@@ -54,22 +60,6 @@ The main reasons teams struggle with CI are:
 - [Branching by Abstraction](https://www.branchbyabstraction.com/).
 - [Feature Flags/Toggles](https://martinfowler.com/articles/feature-toggles.html).
 
----
-
-## Value
-
-As a team, the use of trunk-based development enhances our ability to
-deliver small, value adding, functional enhancements to trunk while
-also decreasing the time it takes to get feedback on our changes.
-
-## Acceptance Criteria
-
-- All Development begins with branching from trunk.
-- The artifact resulting from changes to trunk is running in production.
-- Branches live an average of less than 24 hours.
-- Team members hold each other accountable to the size and frequency of integrations.
-- Repositories only have short-lived branches and trunk.
-
 ## FAQ
 
 - [Pre-requisites for TBD](https://trunkbaseddevelopment.com/deciding-factors/)

content/en/docs/workflow-management/code-review.md

@@ -1,15 +1,11 @@
 ---
 title: Code Review
-
 weight: 1
+tags:
+  - Testing
+  - Teamwork
 ---
 
-As Wikipedia puts it, "Code review is systematic examination of computer
-source
-code. It is intended to find and fix mistakes overlooked in the initial
-development phase, improving both the overall quality of software and the
-developers' skills."
-
 ## Recommended Practices
 
 - Small changes allow for faster code review and enhance the feedback loops.
@@ -19,11 +15,12 @@ developers' skills."
 
 ## Tips
 
-- Automated Code Review processes like linting and static code analysis.
-- Code review that there are tests that meet the acceptance criteria agreed upon by
+- Automate coding standards instead of reviewing for them.
+- Focus the review on the tests and code readability. The tests should meet the acceptance criteria agreed upon by
   the team.
-- Keep pull requests small. Look in to [Work Decomposition](/docs/work-decomposition/work-breakdown)
+- Keep pull requests small. Look into [Work Decomposition](/docs/work-decomposition/work-breakdown)
   for guidance.
+- Use synchronous code review to remove communication delays.
 - As the person being reviewed, remember the 10 Commandments of Code Review
   - Thou shalt not take it personally
   - Thou shalt not marry thy code
@@ -40,19 +37,6 @@ developers' skills."
 
 ## References
 
-- [The 10 commandments of navigating code reviews](https://techbeacon.com/app-dev-testing/10-commandments-navigating-code-reviews)
-
-## Value
-
-- Finds issues before deployment, saving time and money.
-- Increased [Quality](/metrics/quality).
-- Decreased [Change Failure Rate](/metrics/change-fail-rate).
-
-## Acceptance Criteria
-
-- Automated checks for standards and complexity.
-- Code is reviewed for testing and clarity.
-- Pull requests are small and last no more than a day.
-- CI tests run upon opening and modifying pull requests.
+- [The 10 Commandments of Navigating Code Reviews](https://techbeacon.com/app-dev-testing/10-commandments-navigating-code-reviews)
 
 ---

content/en/docs/workflow-management/definition-of-done.md

@@ -1,16 +1,15 @@
 ---
 title: Definition of Done
-
 tags:
-  - teamwork
-  - workflow management
+  - Teamwork
+  - Workflow
   - Work Decomposition
 ---
 
-> Is it DONE, is it DONE DONE, or is it DONE DONE DONE?
+> Is it __DONE__, __DONE DONE__, or is it __DONE DONE DONE__?
 
 All teams need a Definition of Done. The Definition of Done is an agreement made between the team
-that a unit of work isn't actually complete without meeting certain conditions.
+that a unit of work isn't complete without meeting certain conditions.
 
 ## Recommended Practices