Removed scarcity risks

docs/estimating/Kitchen-Cabinet.md

@@ -114,7 +114,7 @@ Is lambda predictable on a project?  It doesn't appear that there have been any
 
 ### When Does Risk Happen?
 
-Too-early and too-late risks are both [Scarcity Risks](/risks/(/tags/Scarcity-Risk): they reflect the fact that time/budget/staff/opportunity are scarce resources which you can run out of.  
+Too-early and too-late risks are both [Dependency Risks](/risks/(/tags/Dependency-Risks): they reflect the fact that time/budget/staff/opportunity are scarce resources which you can run out of.  
 
 But where is the risk accrued?   If you give an estimate, you lock in a maximum too-early risk _at that point_.  From then on, the clock is ticking:  too-early risk decreases towards zero as the due-date approaches.
 
@@ -144,7 +144,7 @@ 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 [Scarcity Risks](/risks/(/tags/Scarcity-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-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.
 

docs/practices/Deployment-And-Operations/Demand-Management.md

@@ -43,7 +43,7 @@ TODO: buffers, queues, pools, kanban
 
 See: 
 
-- [Scarcity Risk](/risks/Dependency-Risks/Scarcity-Risks/Mitigations)
+- [Reliability Risk](/risks/Reliability-Risk)
 
 
 ## See Also

docs/risks/Complexity-Risk/Complexity-Analogies.md

@@ -3,14 +3,11 @@ sidebar_position: 3
 title: Analogies For Complexity
 ---
 
-
-## Analogies
-
 So, we've looked at some measures of software structure complexity.  We can say "this is more complex than this" for a given piece of code or structure.  We've also looked at three ways to manage it:  [Abstraction](/tags/Abstraction) and [Modularisation](/risks/Complexity-Risk#hierarchies-and-modularisation) and via [Dependencies](/risks/Complexity-Risk#languages-and-dependencies).  
 
 However, we've not really said why complexity entails [Risk](/tags/Attendant-Risk).  So let's address that now by looking at three analogies, [Mass](/risks/Complexity-Risk#complexity-is-mass), [Technical Debt](/risks/Complexity-Risk#technical-debt) and [Mess](/risks/Complexity-Risk#kitchen-analogy)  
 
-### Complexity is Mass
+## Complexity is Mass
 
 The first way to look at complexity is as **Mass** :  a software project with more complexity has greater mass than one with less complexity.  
 
@@ -32,7 +29,7 @@ If we want to move _fast_ we need simple code-bases.
 
 At a basic level, [Complexity Risk](/tags/Complexity-Risk) heavily impacts on [Schedule Risk](/tags/Schedule-Risk):  more complexity means you need more force to get things done, which takes longer.
 
-### Technical Debt
+## Technical Debt
 
 The most common way we talk about [Complexity Risk](/tags/Complexity-Risk) in software is as [Technical Debt](/risks/Complexity-Risk#technical-debt):
 
@@ -58,7 +55,7 @@ It's not long before someone comes down with food poisoning.
 
 We wouldn't tolerate this behaviour in a restaurant kitchen, so why put up with it in a software project?  This state-of-affairs is illustrated in the above diagram.  Not only does [Complexity Risk](/tags/Complexity-Risk) slow down future development, it can be a cause of [Operational Risks](/tags/Operational-Risk) and [Security Risks](Agency-Risk#security).
 
-### Feature Creep
+## Feature Creep
 
 In Brooks' essay "No Silver Bullet - Essence and Accident in Software Engineering", a distinction is made between:
 

docs/risks/Complexity-Risk/Connectivity.md

@@ -3,7 +3,6 @@ sidebar_position: 2
 title: Connectivity As Complexity
 ---
 
-
 A second useful measure of complexity comes from graph theory, and that is the connectivity of a graph:
 
 > "...the minimum number of elements (nodes or edges) that need to be removed to disconnect the remaining nodes from each other" - [Connectivity, _Wikipedia_](https://en.wikipedia.org/wiki/Connectivity_(graph_theory))

docs/risks/Complexity-Risk/Hiding-Places.md

@@ -3,10 +3,6 @@ sidebar_position: 4
 title: Hiding Places
 ---
 
-
-
-## Where Complexity Hides
-
 So far, we've focused mainly on [Codebase Risk](/tags/Codebase-Risk), but this isn't the only place complexity appears in software.  We're going to cover a few of these areas now, but be warned, this is not a complete list by any means:
 
  - Algorithmic (Space and Time) Complexity

docs/risks/Coordination-Risk/A-Model-Of-Coordination-Risk.md

@@ -5,7 +5,7 @@ sidebar_position: 1
 
 ## A Model Of Coordination Risk
 
-Earlier, when looking at [Dependency Risks](/tags/Dependency-Risks), we looked at various resources (time, money, people, events etc) and showed how we could [depend on them](/tags/Dependency-Risks) taking on risk.  Here, let's consider the situation where there is _competition for those dependencies_ due to [Scarcity Risk]((/tags/Scarcity-Risk):   other agents want to use them in a different way.  
+Earlier, when looking at [Dependency Risks](/tags/Dependency-Risks), we looked at various resources (time, money, people, events etc) and showed how we could [depend on them](/tags/Dependency-Risks) taking on risk.  Here, let's consider the situation where there is _competition for those dependencies_:   other agents want to use them in a different way.  
 
 ### Law Of Diminishing Returns
 

docs/risks/Dependency-Risks/Funding-Risk/Funding-Risk.md

@@ -1,6 +1,6 @@
 ---
 title: Funding Risk
-description: A particular scarcity risk, due to lack of funding.
+description: A particular dependency-scarcity risk, due to lack of funding.
 
 
 slug: /risks/Funding-Risk

docs/risks/Dependency-Risks/Process-Risk/Process-Risk.md

@@ -22,9 +22,8 @@ part_of: Dependency Risks
 
 Process Risk intersects with several other types of risk we've covered so far:
 
-- [Scarcity Risk](/tags/Scarcity-Risk): Processes may become scarce when they lack resources (think of CPU bottlenecks or queues at the post-office counter).
 - [Agency Risk](/tags/Agency-Risk): Processes have their own agency - they often involve decision making (a loan application or passport renewal).
-- [Reliability Risk](tags/Reliability-Risk): Processes can fail for various reasons (a payment process for example).
+- [Reliability Risk](tags/Reliability-Risk): Processes can fail for various reasons (a payment process for example) or unavailable when they lack resources (think of CPU bottlenecks or queues at the post-office counter)..
 - [Communication Risk](/tags/Communication-Risk): You need to communicate intent to the process, and have it report back its status (think of buying something on the Internet, and the delivery company communicating where the parcel is in transit).
 - [Feature Fit Risk](/tags/Feature-Fit-Risk): A Process should be supplying some useful _features_ to you in order for you to use it.  Is it fit for purpose? (An example might be starting to fill out a form but then realising you're filling out the wrong form).
 

docs/risks/Dependency-Risks/Reliability-Risk/Mitigations.md

@@ -1,12 +1,12 @@
 
 ## Mitigations
 
-Here are a selection of mitigations for [Scarcity Risk](/tags/Scarcity-Risk) in general:
+Here are a selection of mitigations for scarcity in general:
 
  - **Buffers**: smoothing out peaks and troughs in utilisation.
  - **Reservation Systems**: giving clients information _ahead_ of the dependency usage about whether the resource will be available to them.
  - **Graceful degradation**: ensuring _some_ service in the event of over-subscription.  It would be no use allowing people to cram onto the bus until it can't move.
- - **Demand Management**:  having different prices during busy periods helps to reduce demand.  Having "first class" seats means that higher-paying clients can get service even when the train is full. <!-- markdown-link-check-disable --> [Uber](https://www.uber.com) adjust prices in real-time by so-called [Surge Pricing](https://www.uber.com/en-GB/drive/partner-app/how-surge-works/).  This is basically turning [Scarcity Risk](/tags/Scarcity-Risk) into a [Market Risk](/tags/Market-Risk) problem. <!-- markdown-link-check-enable -->
+ - **Demand Management**:  having different prices during busy periods helps to reduce demand.  Having "first class" seats means that higher-paying clients can get service even when the train is full. <!-- markdown-link-check-disable --> [Uber](https://www.uber.com) adjust prices in real-time by so-called [Surge Pricing](https://www.uber.com/en-GB/drive/partner-app/how-surge-works/).  This is basically turning scarcity into a [Market Risk](/tags/Market-Risk) problem. <!-- markdown-link-check-enable -->
  - **Queues**: these provide a "fair" way of dealing with scarcity by exposing some mechanism for prioritising use of the resource.  Buses operate a first-come-first-served system, whereas emergency departments in hospitals triage according to need.
  - **Pools**: reserving parts of a resource for a group of customers, and sharing within that group.
  - **Horizontal Scaling**: allowing a scarce resource to flexibly scale according to how much demand there is.   (For example, putting on extra buses when the trains are on strike, or opening extra check-outs at the supermarket.)

docs/risks/Environmental-Risks/Operational-Risk/Operations-Management.md

@@ -77,16 +77,16 @@ In recent years the [DevOps](https://en.wikipedia.org/wiki/DevOps) movement has
 
 ## Improvement
 
-No system can be perfect, and after it meets the real world, we will want to improve it over time.  But [Operational Risk](/tags/Operational-Risk) includes an element of [Trust & Belief Risk](/tags/Trust-And-Belief-Risk): we have a  _reputation_ and the good will of our customers to consider when we make improvements.  Because this is very hard to rebuild, we should consider this before releasing software that might not live up to expectations.    
+No system can be perfect, and after it meets the real world, we will want to improve it over time.  But [Operational Risk](/tags/Operational-Risk) includes an element of [Reputational Risk](/tags/Reputational-Risk): we have a  _reputation_ and the good will of our customers to consider when we make improvements.  Because this is very hard to rebuild, we should consider this before releasing software that might not live up to expectations.    
 
 So there is a tension between "you only get one chance to make a first impression" and "gilding the lily" (perfectionism).  In the past I've seen this stated as _pressure to ship vs pressure to improve_.
 
 ![Balance of Risks from Delivering Software](/img/generated/risks/operational/ship-it.svg)
 
 A Risk-First re-framing of this (as shown in the diagram above) might be the balance between:
 
-- The perceived [Scarcity Risks](/tags/Scarcity-Risk) (such as funding, time available, etc) of staying in development (pressure to ship).
-- The perceived [Trust & Belief Risk](/tags/Trust-And-Belief-Risk), [Feature Fit  Risk](/tags/Feature-Fit-Risk) and [Operational Risk](/tags/Operational-Risk) of going to production (pressure to improve).
+- The perceived scarcity (such as funding, time available, etc) of staying in development (pressure to ship).
+- The perceived [Reputational Risk](/tags/Reputational-Risk), [Feature Fit Risk](/tags/Feature-Fit-Risk) and [Operational Risk](/tags/Operational-Risk) of going to production (pressure to improve).
 
 The "should we ship?" decision is therefore a complex one.  In [Meeting Reality](/thinking/Meeting-Reality), we discussed that it's better to do this "sooner, more frequently, in smaller chunks and with feedback".  We can meet [Operational Risk](/tags/Operational-Risk) _on our own terms_ by doing so: 
 

docs/risks/Risk-Landscape.md

@@ -57,7 +57,6 @@ Below is a table outlining the different risks we'll see.  There _is_ an order t
 |[Communication Risk](/tags/Communication-Risk)            |Risks associated with getting messages heard and understood.|             
 |[Complexity Risk](/tags/Complexity-Risk)                  |Your software is so complex it makes it hard to change, understand, or run.             |        
 |[Dependency Risks](/tags/Dependency-Risks)                  |Risks of depending on other people, products, software, functions, etc. This is a general look at dependencies, before diving into specifics like...|  
-|[Scarcity Risk](/tags/Scarcity-Risk)                      |Risks associated with having limited time, money or some other resource.|    
 |[Deadline Risk](/tags/Deadline-Risk)                      |The risk of creating a dependency around a point in time.|
 |[Process Risk](/tags/Process-Risk)                        |When you depend on a business process, or human process to give you something you need.|
 |[Lock-In Risk](/tags/Lock-In-Risk)                      |Risks due to making decisions that limit your choices later on.  Sometimes, you go the wrong way on the [Risk Landscape](/risks/Risk-Landscape) and it's hard to get back to where you want to be.|