Fixed broken links

docs/bets/Purpose-Development-Team.md

@@ -40,7 +40,7 @@ Scrum's rule about working-to-a-sprint is well-meaning but not always applicable
 
 ## Case 3: Technical Debt
 
-Sometimes, I am faced with a conflict over whether to pay off [technical debt](/risks/Complexity-Risk#technical-debt) or build new functionality.  Sometimes the conflict will be with people in my team, or with stake-holders but sometimes it is an internal, personal conflict.  
+Sometimes, I am faced with a conflict over whether to pay off [technical debt](/risks/Complexity-Analogies#technical-debt) or build new functionality.  Sometimes the conflict will be with people in my team, or with stake-holders but sometimes it is an internal, personal conflict.  
 
 ![Technical Debt vs Building Features](/img/generated/bets/purpose/technical-debt.svg)
 
@@ -133,15 +133,15 @@ Let's go back to our original cases:
 
  - If I decide to **suspend the current sprint** to fix an outage, then that’s because I’ve decided that the risk of lost business, or the damage to reputation is much greater than the risk of customers walking because we didn’t complete the planned features.  
 - When the Agile Manifesto stresses **Individuals and Interactions over Processes and Tools**, it’s because it believes focusing on processes and tools leads to much greater risk.  This is based on the experience that while focusing on individuals and interactions may appear to be a less efficient way to build software, following strict formal processes massively increases the much worse risk of [building the wrong product](/tags/Feature-Fit-Risk). 
-- When we argue for **fixing technical debt against shipping a new feature**, what we are really doing is expressing differences in our models of the [balance of risk](/tags/Balance-Of-Risk) from taking these actions.   My boss and I might both be trying to minimise the risk of customers defecting to another product but he might believe this is best achieved by [adding new features](/tags/Feature-Fit-Risk) in the short term, whilst I might believe that [clearing technical debt](/risks/Complexity-Risk#technical-debt) allows us to get features delivered faster in the long term.
+- When we argue for **fixing technical debt against shipping a new feature**, what we are really doing is expressing differences in our models of the [balance of risk](/tags/Balance-Of-Risk) from taking these actions.   My boss and I might both be trying to minimise the risk of customers defecting to another product but he might believe this is best achieved by [adding new features](/tags/Feature-Fit-Risk) in the short term, whilst I might believe that [clearing technical debt](/risks/Complexity-Analogies#technical-debt) allows us to get features delivered faster in the long term.
 - In the example of **Sustainably vs Quickly**, it's clear that what we should be doing is trying to avoid altering the balance of risks in a way that sacrifices too much Sustainability or Speed.  To do this requires judgement in the form of an accurate [Internal Model](/tags/Internal-Model) of the [balance of risks](/tags/Balance-Of-Risk).
 
 ### Other Scenarios
 
 In a way, this is not just about development teams.  Any time a person is added to an organisation, the hope is that it will improve the [balance of risk](/tags/Balance-Of-Risk) for that organisation.  The development team are experts in improving the balance of [technical risks](/risks/Risk-Landscape) but other teams have other specialities:
 
  - The Finance team are there to avoid the risk of [running out of money](/tags/Funding-Risk) and ensuring that the bills get paid (avoiding [Legal Risks](/tags/Operational-Risk)).
- - The Human Resources team are there to make sure staff are hired, managed and leave properly.  Doing this avoids [inefficiency](/tags/Schedule-Risk), [Reputation Damage](/tags/Reputational-Risk), [Morale Issues](/risks/Agency-Risk#morale-failure) and [Legal Risks](/tags/Operational-Risk).
+ - The Human Resources team are there to make sure staff are hired, managed and leave properly.  Doing this avoids [inefficiency](/tags/Schedule-Risk), [Reputation Damage](/tags/Reputational-Risk), [Morale Issues](/risks/Human-Agency-Risk#6-morale-failure) and [Legal Risks](/tags/Operational-Risk).
  - The best doctors have accurate [Internal Models](/tags/Internal-Model). They can best diagnose the illnesses and figure out treatments that improve the patient's [balance of risk](/tags/Balance-Of-Risk).  Medical Students are all taught to 'first, do no harm':
 
 > "given an existing problem, it may be better not to do something, or even to do nothing, than to risk causing more harm than good." - [Primum non nocere, _Wikipedia_](https://en.wikipedia.org/wiki/Primum_non_nocere).

docs/estimating/Analogies.md

@@ -19,7 +19,7 @@ So far, this track of articles has tried to bring the problems of estimating sof
 - [Fill-The-Bucket](Fill-The-Bucket):  This is the easiest domain to work in.   All tasks are similar and uncorrelated.  We can _extrapolate_ to figure out how much time the next _n_ units will take to do.
 - [Kitchen Cabinet](Kitchen-Cabinet):  In this domain, there is _hidden work_.  We don't know how much there might be.  If we can break down tasks into smaller units, then by the _law of averages_ and the _central limit theorem_, we can apply some statistics to figure out when we might finish.
 - [Journeys](Journeys):  In this domain, work is heterogeneous and interconnected.  Different parts depend on each other, and a failure in one part might mean going back to the drawing board entirely.  The way to estimate in this domain is to _know the landscape_ and to build in _buffers_.  
-- [Fractals](Fractals):  In this domain, [Parkinson's Law](/risks/Process-Risk#bureaucracy) is king.  There is always more work to be done.  The best thing we can do is try and apply ourselves to the _highest value_ work at any given point, and frequently refer back to reality to find out if we're building the right thing.
+- [Fractals](Fractals):  In this domain, [Parkinson's Law](/risks/Process-Risk#4-bureaucratic-creep) is king.  There is always more work to be done.  The best thing we can do is try and apply ourselves to the _highest value_ work at any given point, and frequently refer back to reality to find out if we're building the right thing.
 
 ![Three Dimensions From Fill-The-Bucket](/img/estimates/dimensions.png)
 
@@ -44,11 +44,11 @@ As we discussed in [Journeys](Journeys), there are plenty of problems in getting
 
 ![Journeys Meets Cabinets](/img/estimates/dimensions-2.png)
 
-What happens when you relax those constraints?  If there is _no map_ and the _closeness_ heuristic isn't available, you're in a maze.   You can't tell how "done" you are in a maze by judging your distance to the exit point - you may be heading to a [Dead End](/risks/Complexity-Risk/Complexity-Analogies#avolding-dead-ends) anyway!
+What happens when you relax those constraints?  If there is _no map_ and the _closeness_ heuristic isn't available, you're in a maze.   You can't tell how "done" you are in a maze by judging your distance to the exit point - you may be heading to a [Dead End](/risks/Complexity-Analogies#complexity-dead-ends) anyway!
 
 ![Maze Estimating](/img/estimates/mazes.png)
 
-Software development is littered with dead-ends:
+Software development is littered with dead ends:
 
  - The database you thought would be a good fit, but didn't work.
  - The library you thought would solve your networking problems, but turned out to be unable to work through the firewall.

docs/estimating/Fractals.md

@@ -86,7 +86,7 @@ With this in mind, you estimate a useful amount of time to go round this cycle,
 
 The fractal nature of many software development tasks is both a blessing and a curse.  It's a blessing because it means that sometimes, software developers can achieve almost-miracles of creating huge chunks of value in no time at all.  But that capability somehow ends up being _an expectation_.   The startup idea of "throwing together an MVP (Minimum Viable Product)" is taken as gospel.  Kyle Prifogle pushes against this when he writes:
 
-> "Lets explore this point more by means of an extended analogy. Suppose that you wanted to start a new business as a yachting captain... This is in many ways analogous to when a startup company decides that they want to serve the fortune 500, companies that have petabytes and beyond of data. However, you as a startup founder have to operate lean, and you are only willing to spend $10,000 on a boat. If you were to walk up to the owner of the multi-million dollar yacht and say, I’ll give you $10,000 for that boat, you would be laughed off the dock. " - [Kyle Prifogle, _Dear Startup_](https://kyleprifogle.com/dear-startup/)
+> "Lets explore this point more by means of an extended analogy. Suppose that you wanted to start a new business as a yachting captain... This is in many ways analogous to when a startup company decides that they want to serve the fortune 500, companies that have petabytes and beyond of data. However, you as a startup founder have to operate lean, and you are only willing to spend 10,000 dollars on a boat. If you were to walk up to the owner of the multi-million dollar yacht and say, I’ll give you $10,000 for that boat, you would be laughed off the dock. " - [Kyle Prifogle, _Dear Startup_](https://kyleprifogle.com/dear-startup/)
 
 Buying yachts is _not_ in the Fractal problem space.  It's much more [Fill-The-Bucket](Fill-The-Bucket): more money means more yacht.  So, it's not a great analogy.  But the point is that the _expectation_ is for a value-miracle to occur, simply by adopting the practice of MVP or agile development.
 

docs/estimating/Risk-First-Analysis.md

@@ -41,7 +41,7 @@ Seen like this, **Planning Poker** is a tool to avoid the [Coordination Risk](/t
 
 - [Kitchen Cabinet](Kitchen-Cabinet):  In this domain, there is _hidden work_.  We don't know how much there might be.  If we can break down tasks into smaller units, then by the _law of averages_ and the _central limit theorem_, we can apply some statistics to figure out when we might finish.
 - [Journeys](Journeys):  In this domain, work is heterogeneous and interconnected.  Different parts depend on each other, and a failure in one part might mean going right back to square one.  The way to estimate in this domain is to _know the landscape_ and to build in _buffers_.  
-- [Fractals](Fractals):  In this domain, [Parkinson's Law](/risks/Process-Risk#bureaucracy) is king.  There is always more work to be done.  The best thing we can do is try and apply ourselves to the _highest value_ work at any given point, and frequently refer back to reality to find out if we're building the right thing.
+- [Fractals](Fractals):  In this domain, [Parkinson's Law](/risks/Process-Risk#4-bureaucratic-creep) is king.  There is always more work to be done.  The best thing we can do is try and apply ourselves to the _highest value_ work at any given point, and frequently refer back to reality to find out if we're building the right thing.
 
 ![Three Dimensions From Fill-The-Bucket](/img/estimates/dimensions.png)
 

docs/practices/Deployment-And-Operations/Automation.md

@@ -49,11 +49,6 @@ practice:
 
 One of the key ways to measure whether your team is doing _useful work_ is to look at whether, in fact, it can be automated.  And this is the spirit of [DevOps](/methods/DevOps) - the idea that people in general are poor at repeatable tasks, and anything people do repeatedly _should_ be automated.  
 
-See: 
-
- - [Automation (Meeting Reality)](/thinking/Meeting-Reality#example-automation)
- - [The Purpose of Process](/risks/Process-Risk#the-purpose-of-process)
-
 ## See Also
 
 <TagList tag="Automation" />

docs/practices/Deployment-And-Operations/Monitoring.md

@@ -21,6 +21,8 @@ practice:
      reason: "Monitors for security breaches and anomalies."
    - tag: Process Risk
      reason: "Monitoring a process can ensure that when it misbehaves the issues are quickly caught."  
+   - tag: Agency Risk
+     reason: "Monitoring the behaviour of agents, whether people or processes, helps identify when behaviour becomes counter-productive."
   attendant:
    - tag: Complexity Risk
      reason: "Implementing comprehensive monitoring solutions can add complexity."
@@ -32,6 +34,7 @@ practice:
    - ../Deployment-and-Operations/Incident-Management
    - ../Tools-and-Standards/Prototyping
    - ../Communication-and-Collaboration/Documentation
+   - ../External-Relations/Analysis
 ---
 
 <PracticeIntro details={frontMatter} /> 
@@ -42,11 +45,6 @@ practice:
 
 Monitoring encompasses a wide range of practices designed to ensure that systems operate efficiently and without interruption. This includes tracking the performance, availability, and security of networks, systems, and applications. Effective monitoring helps in early detection of issues, allowing for prompt resolution and minimizing the impact on operations.
 
-See:
- - [Operations Management](/risks/Operational-Risk#operations-management)
- - [Monitoring](/risks/Agency-Risk#monitoring)
- - [Control](/risks/Operational-Risk#control)
-
 ## See Also
 
 <TagList tag="Monitoring" />

docs/practices/Development-And-Coding/Dependency-Adoption.md

@@ -42,7 +42,7 @@ Making use of third-party libraries or services in your code.
 
 See:
 
- - [Languages and Dependencies](/risks/Complexity-Risk#languages-and-dependencies)
+ - [Languages and Dependencies](/risks/Kolmogorov-Complexity#languages-and-dependencies)
  - [Software Libraries (On Software Dependencies)](/risks/On-Software-Dependencies#2-software-libraries)
  - [Software-as-a-Service (On Software Dependencies)](/risks/On-Software-Dependencies#3--software-as-a-service)
 

docs/practices/Development-And-Coding/Refactoring.md

@@ -51,9 +51,8 @@ Refactoring is all about ensuring you have the right abstractions.
 
 See: 
 
- - [Refactoring](/risks/Complexity-Risk#refactoring)
- - [The Power of Abstractions](/risks/Staging-And-Classifying#the-power-of-abstractions)
- - [Hierarchies and Modularisation](/risks/Complexity-Risk#hierarchies-and-modularisation)
+ - [Refactoring](/risks/Kolmogorov-Complexity#refactoring)
+ - [Hierarchies and Modularisation](/risks/Connectivity#hierarchies-and-modularisation)
 
 
 ## External References

docs/practices/External-Relations/Analysis.md

@@ -12,6 +12,7 @@ practice:
    - "Requirement Analysis"
    - "Business Analysis"
    - "System Analysis"
+   - "Environmental Scanning"
   mitigates:
    - tag: Implementation Risk
      reason: "Ensures that requirements and specifications are clearly understood before development begins."
@@ -25,6 +26,8 @@ practice:
      reason: "Analysis is the process of doing work to build a better Internal Model."
    - tag: Lock-In Risk
      reason: "Analysis can identify dependencies where Lock-In Risk is high."
+   - tag: Operational Risk
+     reason: "Analysis is important to identify threats to an operation from its environment."
   attendant:
    - tag: Schedule Risk
      reason: "Can be time-consuming, potentially delaying the start of development."
@@ -44,9 +47,7 @@ practice:
 
 Analysis in software development involves examining and breaking down the requirements, systems, and processes to understand the needs and ensure the correct implementation of the software. This practice is crucial for identifying potential issues, clarifying requirements, and ensuring that the development aligns with business goals and user needs.
 
-See: 
-
- - [Environmental Scanning](/risks/Operational-Risk#scanning-the-operational-context)
+Analysis is also important as a tool to understand the environment that your software will run in.  See [Environmental Risks](/tags/Environmental-Risks).
 
 ## See Also
 

docs/practices/Planning-And-Management/Approvals.md

@@ -43,11 +43,6 @@ practice:
 
 Approval / Sign Off in software development involves getting formal approval from stakeholders at various stages of the project. This practice ensures that the work meets the required standards and specifications before progressing to the next phase, providing a formal communication of acceptance and readiness.
 
-See:
-
-- [Processes, Sign-Offs and Agency Risk](/risks/Process-Risk#processes-sign-offs-and-agency-risk)_
-
-
 ## See Also
 
 <TagList tag="Approvals" />

docs/practices/Planning-And-Management/Delegation.md

@@ -42,7 +42,7 @@ Delegation involves assigning responsibility and authority to others to carry ou
 
 See:
 
- - [Goal Alignment](/risks/Agency-Risk#goal-alignment)=
+ - [Goal Alignment](/risks/Reducing-Agency-Risk#1-goal-alignment)
  - [Risk-First Diagrams](/thinking/Risk-First-Diagrams#example-blaming-others)
 
 ## See Also

docs/practices/Planning-And-Management/Prioritising.md

@@ -77,8 +77,7 @@ By prioritising, you get to [Meet Reality](/thinking/Meeting-Reality) _sooner_ a
 
 
 See:
- - [Operations Management](/risks/Operational-Risk#operations-management)
- - [Planning](/risks/Operational-Risk#planning)
+ - [Issue Management](Issue-Management)
  - [Tracking Risks](/thinking/Track-Risk#visualising-risks)
 
 

docs/practices/Start.md

@@ -21,6 +21,6 @@ This is an incomplete index of software development practices that you might app
 
 ## Main Areas
 
-Practices here are broken down into the following main categories.
+Practices here are broken down into the following (fairly arbitrary) categories.
 
 <TagList filter="practices" tag="Practice Category" />

docs/practices/Testing-and-Quality-Assurance/Security-Testing.md

@@ -43,9 +43,6 @@ practice:
 
 Security Testing involves assessing the security of software applications to identify vulnerabilities and ensure they are protected against threats and attacks. This practice is essential for maintaining the integrity, confidentiality, and availability of software systems.
 
-See:
- - [Penetration Testing](/risks/Operational-Risk#scanning-the-operational-context)
-
 ## See Also
 
 <TagList tag="Security Testing" />

docs/risks/Communication-Risks/Reading-Code.md

@@ -23,5 +23,5 @@ By now it should be clear that it's going to be _both_ quite hard to read and wr
 But now we should be able to see the reason why it's harder to read than write too: 
 
  - When reading code, you are having to shift your [Internal Model](/tags/Internal-Model) to wherever the code is, accepting decisions that you might not agree with and accepting counter-intuitive logical leaps.  i.e. [Internal Model Risk](/tags/Internal-Model-Risk). _(cf. [Principle of Least Surprise](https://en.wikipedia.org/wiki/Principle_of_least_astonishment))_
- - There is no [Feedback Loop](/tags/Feedback-Loop) between your [Internal Model](/tags/Internal-Model) and the [Reality](/tags/Meeting-Reality) of the code, opening you up to [misinterpretation](/risks/On-Messages#2--misinterpretation).  When you write code, your compiler and tests give you this.
+ - There is no [Feedback Loop](/tags/Feedback-Loop) between your [Internal Model](/tags/Internal-Model) and the [Reality](/tags/Meeting-Reality) of the code, opening you up to [misinterpretation](/risks/On-Messages#2-misinterpretation).  When you write code, your compiler and tests give you this.
  - While reading code _takes less time_ than writing it, this also means the learning curve is steeper.