Practice pages

dictionary.txt

@@ -351,3 +351,33 @@ nagging
 wrongdoing
 demystify
 dysfunctional
+outlier
+ousted
+lockheed
+strategically
+erratically
+eidos
+lara
+croft
+accrete
+decommissioned
+ratchets
+laborious
+reimplement
+devolved
+microservices
+serviceability
+automakers
+pinto
+uptime
+nokia
+outsourcing
+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."
 
@@ -87,7 +87,7 @@ Often you get user-stories like these:
 
 > "We need a global search because people spend too much time menu-diving."
 
-New features might help sell your software to new markets and please existing power users.  But too many features confuse users, obscuring the essential purpose of the software.  This is [Conceptual Integrity Risk](/tags/Conceptual-Integrity-Risk) - trying to please everyone means you please no-one.  
+New features might help sell your software to new markets and please existing power users.  But too many features confuse users, obscuring the essential purpose of the software.  This is a [Communication Risk](/tags/Communication-Risk) - trying to please everyone means you please no-one.  
 
 ![Stake and Reward for Adding New Features](/img/generated/bets/coding/new-feature.svg)
 

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-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/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/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](/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-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/Fixing-Scrum.md

@@ -29,11 +29,11 @@ Work in Scrum is done within periods of time called _Sprints_.  Each sprint ends
 
 > "The goal of this activity is to inspect and adapt the product being built... Everyone in attendance gets clear visibility into what is occurring and has an opportunity to help guide the forthcoming development to ensure that the most business-appropriate solution is created." - Essential Scrum (p26), _Rubin_
 
-In Risk-First, we tend to call this validation step [Meeting Reality](/tags/Meeting-Reality):  you are creating a [feedback loop](/thinking/Cadence) in order to minimise risk.  What is the risk you are minimising?  Essentially, we are trying to reduce the risk of the developers _building the wrong thing_, which could be due to misunderstanding of requirements, or perfectionism, or because the piece of work was ill-conceived in the first place.  In Risk-First, the risk of building the wrong thing is called [Feature Risk](/tags/Feature-Risk).
+In Risk-First, we tend to call this validation step [Meeting Reality](/tags/Meeting-Reality):  you are creating a [feedback loop](/thinking/Cadence) in order to minimise risk.  What is the risk you are minimising?  Essentially, we are trying to reduce the risk of the developers _building the wrong thing_, which could be due to misunderstanding of requirements, or perfectionism, or because the piece of work was ill-conceived in the first place.  In Risk-First, the risk of building the wrong thing is called [Feature Fit Risk](/tags/Feature-Fit-Risk).
 
-![Feature Risk mitigated by Meeting Reality](/img/generated/estimating/scrum/scrum1.svg)
+![Feature Fit Risk mitigated by Meeting Reality](/img/generated/estimating/scrum/scrum1.svg)
 
-The above diagram demonstrates us mitigating [Feature Risk](/tags/Feature-Risk) (the risk of not building the right software for our clients) by organising a Sprint Review.  But there is a downside to a Sprint Review:  _it takes time_.
+The above diagram demonstrates us mitigating [Feature Fit Risk](/tags/Feature-Fit-Risk) (the risk of not building the right software for our clients) by organising a Sprint Review.  But there is a downside to a Sprint Review:  _it takes time_.
 
 ![Schedule Risk for Stakeholders](/img/generated/estimating/scrum/scrum2.svg)
 
@@ -121,7 +121,7 @@ How can we, as software developers, minimise the chance of building the wrong th
 
 ![Scrum](/img/generated/estimating/scrum/scrum4.svg)
 
-Look above at the diagram what Scrum is trying to do to mitigate [Feature Risk](/tags/Feature-Risk):
+Look above at the diagram, showing how Scrum is trying to mitigate [Feature Fit Risk](/tags/Feature-Fit-Risk):
 
 - We [Meet Reality](/tags/Meeting-Reality) to ensure we've got a feedback loop.
 - We **time-box** to avoid wasting stake-holders' time (Schedule Risk).

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.
 
@@ -98,7 +98,7 @@ Although there are some high-profile wins with these types of problems, generall
 
 ## Applying Risk-First
 
-Let's look at the conclusions we reached in [Boundary Risk](/tags/Boundary-Risk):
+Let's look at the conclusions we reached in [Lock-In Risk](/tags/Lock-In-Risk):
 
 > - **Human need is [Fractal](https://en.wikipedia.org/wiki/Fractal)**:  this means that over time, software products have evolved to more closely map human needs.   Software that would have delighted us ten years ago lacks the sophistication we expect today.
 - **Software and hardware are both improving with time**: due to evolution and the ability to support greater and greater levels of complexity.