Fixing broken links

Author: robmoffat

dictionary.txt

@@ -376,3 +376,8 @@ externalities
 takedown
 microsystems
 skepticism
+scrappy
+tarnish
+goveranance
+subpostmasters
+exonerate

docs/bets/Coding-Bets.md

@@ -53,7 +53,7 @@ It looks like this:
 
 > "Sometimes a user story is generated that cannot be well estimated until the development team does some actual work to resolve a technical question or a design problem. The solution is to create a 'spike,' which is some work whose purpose is to provide the answer or solution. " - [Spike Solution, _Agile Dictionary_](https://agiledictionary.com/209/spike/) 
 
-You might want to use a Spike Solution to test out replacing a badly-fitting technology for a more appropriate one.  That is, addressing [Software Dependency](/tags/Software-Dependency-Risk) problems.  For example:
+You might want to use a Spike Solution to test out replacing a badly-fitting technology for a more appropriate one.  That is, addressing [Software Dependency](/risks/On-Software-Dependencies) problems.  For example:
 
 > "Let's explore using [ElasticSearch](https://en.wikipedia.org/wiki/Elasticsearch) for searching instead of SQL Statements."
 

docs/bets/Purpose-Development-Team.md

@@ -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-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-Risk#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/Trust-And-Belief-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/Agency-Risk#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

@@ -44,7 +44,7 @@ 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](/tags/Dead-End-Risk) 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-Risk/Complexity-Analogies#avolding-dead-ends) anyway!
 
 ![Maze Estimating](/img/estimates/mazes.png)
 

docs/estimating/Kitchen-Cabinet.md

@@ -144,9 +144,9 @@ This means that clients often keep projects running for far longer than they sho
 
 There is an alternative to too-early or too-late risk.  You can always choose to be _on time_.  This is definitely a choice: Just like a student can always hand _something_ in on assignment day (even if it's just a title scrawled on a piece of paper), you can always hand in whatever work you have.  
 
-Then, instead of worrying about [Deadline Risk](/risks/(/tags/Deadline-Risk), you are letting [Feature Fit Risk](/tags/Feature-Risk) vary to take up the slack.
+Then, instead of worrying about [Deadline Risk](/risks/(/tags/Deadline-Risk), you are letting [Feature Fit Risk](/tags/Feature-Fit-Risk) vary to take up the slack.
 
-So far, we've seen two kinds of estimate:  [Fill-The-Bucket](Fill-The-Bucket) and [Kitchen-Cabinet](Kitchen-Cabinet).  Now, it's time to review a third - estimating [Journey Style](Journeys), and looking at how we can minimise [Feature Fit Risk](/tags/Feature-Risk) within an available budget.
+So far, we've seen two kinds of estimate:  [Fill-The-Bucket](Fill-The-Bucket) and [Kitchen-Cabinet](Kitchen-Cabinet).  Now, it's time to review a third - estimating [Journey Style](Journeys), and looking at how we can minimise [Feature Fit Risk](/tags/Feature-Fit-Risk) within an available budget.
 
 
 

docs/estimating/On-Story-Points.md

@@ -63,7 +63,7 @@ After some back-and-forth, the team agrees on a number.  But what does this numb
 
 - **Complexity**: An alternate view is that [a story point is about _complexity_](https://www.clearvision-cm.com/blog/why-Story Points-are-a-measure-of-complexity-not-effort/).  This means a Sprint is all about budgeting complexity, rather than effort.   This makes some sense but given that the sprint is measured in person-days, and the scrum leader is going to produce a report showing how many story points were completed in a sprint, it's clear that complexity really is just a weak proxy for person-days anyway.  In fact, there are lots of tasks that might be low-complexity, but take a lot of time anyway, such as designing 500 icons.  This will clearly take a lot of time, but be low-complexity, so you better give it enough story points to represent the time you'll spend on it.   
 
-- **Relative Sizing**: A third way of looking at it is that really, story points are just about _relative_ sizing:  it doesn't matter what they refer to or how big they are, it's all about trying to budget the right amount of work into the sprint.  For example, you can either have two one-point stories, or a two-point story, and the effect on the sprint is the same.  Because there is no fixed definition of the size of a story point, you do run the risk of story-point "inflation" or "deflation".  But unless you are trying to use them to plot team productivity over time, this shouldn't really matter so much.  And we'd never make the mistake of doing that, [right](/tags/Map-And-Territory-Risk)?  
+- **Relative Sizing**: A third way of looking at it is that really, story points are just about _relative_ sizing:  it doesn't matter what they refer to or how big they are, it's all about trying to budget the right amount of work into the sprint.  For example, you can either have two one-point stories, or a two-point story, and the effect on the sprint is the same.  Because there is no fixed definition of the size of a story point, you do run the risk of story-point "inflation" or "deflation".  But unless you are trying to use them to plot team productivity over time, this shouldn't really matter so much.  And we'd never make the mistake of doing that, [right](/risks/Internal-Model-Risk/Metrics)?  
 
 ## Observations
 

docs/estimating/Risk-First-Analysis.md

@@ -95,7 +95,7 @@ On a Risk-First diagram, tasks - or actions as we call them - are shown in "sign
 
 By fixing the rendering bug, we are trying to deal the problem that the software _demos badly_ and the resulting risk that the potential customers don't trust the quality of our product.  Risk-First diagrams show chronology from left-to-right.  That is, on the left of the action is the world as it is now, whereas on the right is the world as it will be _after_ taking some action.  To show that our action will eliminate some existing risk, we can strike it out by drawing a line through it.
 
-So, this diagram encapsulates the reason why we might fix the rendering bug:  it's about addressing potential [Trust Risk](/tags/Trust-And-Belief-Risk) in our product.  
+So, this diagram encapsulates the reason why we might fix the rendering bug:  it's about addressing potential [Reputational Risk](/tags/Reputational-Risk) in our product.  
 
 ## Question 2: What Do We Gain?
 

docs/overview/Quick-Summary.md

@@ -63,7 +63,7 @@ If we accept the assertion that _all_ the actions we take on a project are about
 
 For example:
 
- - If we do a [Code Review](/tags/Review), we are partly trying to minimise the risks of bugs slipping through into production and also manage the [Key Person Risk](/tags/Staff-Risk) of knowledge not being widely-enough shared. 
+ - If we do a [Code Review](/tags/Review), we are partly trying to minimise the risks of bugs slipping through into production and also manage the key person risk of knowledge not being widely-enough shared. 
  - If we write [Unit Tests](/tags/Automated-Testing), we’re addressing the risk of bugs going to production. We’re also mitigating against the risk of _regression_ and future changes breaking our existing functionality.   
  - If we enter into a contract with a supplier then we are mitigating the risk of the supplier vanishing and leaving us exposed.  With the contract in place we have legal recourse against this risk.
 

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

@@ -62,7 +62,7 @@ But, this is a low bar -  some tools offer _amazing_ returns on investment:
 
 A _really good tool_ offers such advantages that not using it becomes _unthinkable_:  Linux is heading towards this point.   For Java developers, the JVM is there already.  
 
-Picking new tools and libraries should be done **very carefully**:  you may be stuck with your choices for some time.  Here is a [short guide that might help](/tags/Dependency-Risk).
+Picking new tools and libraries should be done **very carefully**:  you may be stuck with your choices for some time.  Here is a [short guide that might help](/risks/On-Software-Dependencies).
 
 
 ## See Also

docs/risks/Communication-Risks/On-Channels.md

@@ -24,7 +24,7 @@ Shannon discusses that no channel is perfect:  there is always the **risk of noi
 
 There are practical implications to this:  messages might be delayed or delivered in the wrong order, or not be acknowledged when they do arrive.  Sometimes, a channel is just an inappropriate way of communicating.  When you work in a different time-zone to someone else on your team, there is _automatic_ [Communication Risk](/tags/Communication-Risk), because instantaneous communication is only available for a few hours a day. 
 
-When channels are **poor-quality**, less communication occurs.  People will try to communicate just the most important information.  But, it's often impossible to know a-priori what constitutes "important".   This is why [Extreme Programming](https://en.wikipedia.org/wiki/Extreme_programming) recommends the practices of [Pair Programming](https://en.wikipedia.org/wiki/Pair_programming) and grouping all the developers together: although you don't know whether useful communication will happen, you are mitigating [Channel Risk](/tags/Channel-Risk) by ensuring high-quality communication channels are in place.
+When channels are **poor-quality**, less communication occurs.  People will try to communicate just the most important information.  But, it's often impossible to know a-priori what constitutes "important".   This is why [Extreme Programming](https://en.wikipedia.org/wiki/Extreme_programming) recommends the practices of [Pair Programming](https://en.wikipedia.org/wiki/Pair_programming) and grouping all the developers together: although you don't know whether useful communication will happen, you are mitigating [Communication Risk](/tags/Communication-Risk) by ensuring high-quality communication channels are in place.
 
 At other times channels are crowded and can contain so much information that we can't hope to receive all the messages.  In these cases we don't even observe the whole channel, just parts of it. 
 
@@ -43,4 +43,4 @@ This works both ways.  Let's looks at some of the **Communication Risks** from t
 
 ![Marketing Communication](/img/generated/risks/communication/communication_marketing.svg)
 
-[Internal Models](/tags/Internal-Model) don't magically get populated with the information they need:  they fill up gradually, as shown in the diagram above.  Popular products and ideas _spread_, by word-of-mouth or other means.  Part of the job of being a good technologist is to keep track of new **Ideas**, **Concepts** and **Options**, so as to use them as [Dependencies](/tags/Dependency-Risk) when needed.
+[Internal Models](/tags/Internal-Model) don't magically get populated with the information they need:  they fill up gradually, as shown in the diagram above.  Popular products and ideas _spread_, by word-of-mouth or other means.  Part of the job of being a good technologist is to keep track of new **Ideas**, **Concepts** and **Options**, so as to use them as [Dependencies](/tags/Dependency-Risks) when needed.