Hygene Re-org 1

risk-first · Jul 13, 2024 · 06c2383 · 06c2383
1 parent ae83e02
commit 06c2383
Show file tree

Hide file tree

Showing 16 changed files with 140 additions and 72 deletions.
diff --git a/docs/methods/SAFe.md b/docs/methods/SAFe.md
diff --git a/docs/misc/Authors.md b/docs/misc/Authors.md
diff --git a/docs/misc/Start.md b/docs/misc/Start.md
diff --git a/docs/misc/_category_.yaml b/docs/misc/_category_.yaml
diff --git a/docs/misc/Audience.md → docs/overview/Audience.md b/docs/misc/Audience.md → docs/overview/Audience.md
diff --git a/docs/misc/Contributors.md → docs/overview/Contributors.md b/docs/misc/Contributors.md → docs/overview/Contributors.md
@@ -10,13 +10,6 @@ sidebar_position: 13
 
 # Contributors
 
-If you feel something important is missing, or you spot a mistake, [we need help](https://github.com/risk-first/website/blob/master/CONTRIBUTING.md).
-
-Although this is a collaborative Github project, it's not meant to be an open-ended discussion of software techniques like [Ward's Wiki](https://wiki.c2.com).  In order to be concise and useful, discussions need to be carried out by either:
-
- - **[Opening an Issue](https://github.com/risk-first/website/issues).**
- - **["Star"ing the project](https://github.com/risk-first/website/stargazers)**: this will cause you to be invited to join the Risk-First organisation
-
 Ideas, issues and proof-reading:
 
 - [Ali Abbas](https://github.com/realabbas)
@@ -31,5 +24,15 @@ Ideas, issues and proof-reading:
 - [Serhan Tutar](https://github.com/randomnoise)
 - [Stephan Westen](https://github.com/stephanwesten)
 
+## Want To Help?
+
+If you feel something important is missing, or you spot a mistake, [we need help](https://github.com/risk-first/website/blob/master/CONTRIBUTING.md).
+
+Although this is a collaborative Github project, it's not meant to be an open-ended discussion of software techniques like [Ward's Wiki](https://wiki.c2.com).  In order to be concise and useful, discussions need to be carried out by either:
+
+ - **[Opening an Issue](https://github.com/risk-first/website/issues).**
+ - **["Star"ing the project](https://github.com/risk-first/website/stargazers)**: this will cause you to be invited to join the Risk-First organisation
+
+## Author
 
 _Currently, all articles authored by [Rob Moffat](https://github.com/robmoffat)_
diff --git a/docs/thinking/A-Conversation.md b/docs/thinking/A-Conversation.md
@@ -10,7 +10,7 @@ tags:
  - Internal Model
  - Hidden Risk
  - Attendant Risk
-sidebar_position: 13
+sidebar_position: 14
 redirect_from: 
  - /A-Conversation
 tweet: yes
@@ -88,7 +88,11 @@ At this point, you might be wondering what all the fuss is about.   This stuff i
 
 The problem is that although all this _is_ obvious, it appears to have largely escaped codification within the literature, practices and methodologies of software development.   Further, while it is obvious, there is a huge hole: successful De-Risking depends heavily on individual experience and talent.  
 
-In the [next section](One-Size-Fits-No-One.md), we are going to briefly look at software methodology, and how it comes up short in when addressing risk.
+## Where Next?
+
+This section has hopefully underscored the importance of _talking about risk_ with colleagues.  If you're working in a team where this isn't happening then perhaps you can introduce this practice and improve your teams' odds of winning.  
+
+If you're working in a larger organisation then the chances are that risk management is already well embedded in the organisation.   So in the next section we'll have a quick run-down covering what developers need to know about [Enterprise Risk Management](Enterprise-Risk.md).
 
 
 

diff --git a/docs/misc/Anti-Goals.md → docs/thinking/Anti-Goals.md b/docs/misc/Anti-Goals.md → docs/thinking/Anti-Goals.md
@@ -9,7 +9,7 @@ featured:
 author: rob
 tags:
  - Goal
-sidebar_position: 10
+sidebar_position: 11
 tweet: yes
 ---
 
@@ -78,6 +78,15 @@ We need to acknowledge that pursuing certain goals via certain courses of action
 
 > "GIVEN the scope of this SaaS project, WHEN I develop it THEN I want to avoid burn-out and bankruptcy"  
 
+## Summing Up
+
+The most valuable project management skill is being able to chart a course controlling your exposure to risk.  Sometimes, that will mean [hitting a deadline](/tags/Deadline-Risk), but equally it could be [reducing codebase complexity](/tags/Complexity-Risk), [making a feature more accessible](/tags/Feature-Access-Risk) or [removing problematic dependencies](/tags/Software-Dependency-Risk).
+
+The most important skill is to be able to _weigh up the risks_, decide on a course of action that exposes you to the greatest expected value, while looking for ways of increasing the payoff of winning and minimise the impact of losing.
+
+In the next section, we'll turn our attention to time:  often, urgent risks _can_ crowd out the merely important.  Why does that happen, and what should we do about it?  In the next section, we'll look at how you can account for different levels of _urgency_ in your payoff considerations.   
+
+On to [Evaluating Risk](Evaluating-Risk.md).
 
 
 

diff --git a/docs/thinking/Cadence.md b/docs/thinking/Cadence.md
@@ -80,12 +80,4 @@ Yes, CD will give you faster feedback loops, but even getting things into produc
 
 The right answer is to use multiple feedback loops, as shown in the diagram above.  
 
-## Moving On
-
-Let's quickly review the new terms introduced in this section:
-
-<BoxOut title="New Terms" link="/thinking/Glossary" linkText="View Glossary">
-	<TermList details={frontMatter} /> 
-</BoxOut>
-
 In the next section we'll be [Considering Payoff](Consider-Payoff.md), and figuring out how we can use terminology from _betting_ to make us better software developers.
diff --git a/docs/thinking/Consider-Payoff.md b/docs/thinking/Consider-Payoff.md
@@ -273,12 +273,6 @@ As we've seen, figuring out payoff is made more tricky because often the actions
 
 Many Agile frameworks such as [Scrum](../bets/Purpose-Development-Team#case-2-scrum) place a lot of emphasis on estimating and time-boxing work:  trying to work out when you're going to deliver something and sticking to it.  But Risk-First is suggesting a totally different focus:  factors like _time taken to deliver_ and _coordinating the completion of work_ are just risks to consider along with all the others.  
 
-The most valuable project management skill is being able to chart a course which minimises risk.  Sometimes, that will mean [hitting a deadline](/tags/Deadline-Risk), but equally it could be [reducing codebase complexity](/tags/Complexity-Risk), [making a feature more accessible](/tags/Feature-Access-Risk) or [removing problematic dependencies](/tags/Software-Dependency-Risk).
-
-The most important skill is to be able to _weigh up the risks_, decide on a course of action that gives you the greatest expected value and look for ways of increasing the payoff of winning and losing.
-
-Often, urgent risks _can_ crowd out the merely important.  Why does that happen, and what should we do about it?  In the next section, we'll look at how you can account for different levels of _urgency_ in your payoff considerations.   
-
-On to [Evaluating Risk](Evaluating-Risk.md).
-
+Betting generally focuses on the odds of winning.  However, there are entire classes of problem (such as short positions) where you need to focus on minimising the risk of losing.   
 
+Let's look at that next in [Anti-Goals](Anti-Goals.md).
diff --git a/docs/thinking/Crisis-Mode.md b/docs/thinking/Crisis-Mode.md
@@ -6,7 +6,7 @@ description: Why 'Crisis Mode' shouldn't be a mode.
 featured: 
   class: bg3
   element: '<risk href="/public/templates/risk-first/redesign/risks/attendant_risk_v2.svg"><code>Panic</code><title>Crisis Mode</title></risk>'
-sidebar_position: 12
+sidebar_position: 13
 tweet: yes
 ---
 
@@ -18,9 +18,13 @@ In this section we're going to explore the assertion that good risk management p
 
 As software developers, we face crises of different sorts. Perhaps there's a production outage and we're up at 3am scrambling around to recover data from backups, or a sudden meeting with clients or investors arises in which we have to scramble to put together a prototype in short order.  Agile software development doesn't have much to say about what we should do in these situations:  Scrum's rigorous 2-week sprint model doesn't account for the sprint being interrupted by urgent events.
 
-In this section, we are going to look at how a risk management approach to software development is invariant to a number of different things:  the size of the project, the level of pressure and the technology being used.  
+## Testing For Invariances
 
-## Crisis Management?
+In this section, we are going to look at how a risk management approach to software development is invariant to a number of different things:  the size of the project, the level of pressure and the technology being used.  For example, I am an advocate of [Extreme Programming](../methods/Extreme-Programming.md).  However, as you scale the size of the project, it breaks down.  This is well understood and explains why methodologies like [Scaled Agile](../methods/SAFe.md) arose which attempt to fix this.  
+
+Why would we want to do this?  Einstein's ideas around relativistic gravity were proven because people discovered that the Newtonian model of gravity [failed to predict the orbit of Mercury](https://en.wikipedia.org/wiki/Tests_of_general_relativity#Classical_tests).  So it's important to explore and understand the limits of our ideas and practices.  
+
+## Invariance 1: Is It A Crisis?
 
 First though, let's talk specifically about "Crisis Management".  A lot of literature on Crisis Management suggests that when a crisis occurs, you abandon your normal approach and switch to a different, crisis management approach.  For example:
 
@@ -36,7 +40,7 @@ Third, Crisis Management is _still just Risk Management_:  the crisis (Earthquak
 
 Yes, it's fine to say "we're in crisis", but to assume there is a different strategy for dealing with it is a mistake:  this is the [Fallacy of Sunk Costs](https://en.wikipedia.org/wiki/Escalation_of_commitment). 
 
-## Invariance #1: Pressure Invariance
+## Invariance #2: Pressure Invariance
 
 You would expect that ideally, any methods for managing software delivery should be _invariant_ to the degree of crisis in the project.  If, for example, a project proceeds using [Scrum](https://en.wikipedia.org/wiki/Scrum_(software_development)) for eight months and then the deadline looms and everyone agrees to throw Scrum out of the window and start hacking, then _this implies there is a problem with Scrum_ and that it is not **Pressure Invariant**.  In fact, many tools like Scrum don't consider this:
 
@@ -49,7 +53,7 @@ This is **Pressure Invariance**:  ideally, your methodology shouldn't need to ch
 
 **See:** In [Debugging Bets](../bets/Debugging-Bets.md) I tell the story of a high-pressure situation where I applied a risk-analysis approach in order to try and bring a new problem to ground ahead of a big presentation.
 
-## Invariance #2: Scale Invariance
+## Invariance #3: Scale Invariance
 
 We are used to the idea that physical laws work at _any scale_: if they don't apply equally to big and small scenarios then that implies something is wrong.  For example, Newton's Laws of Motion work fine for artillery shells but fail to calculate the orbital period of Mercury, which led to Einstein trying to improve on them with the [Theory of Relativity](https://en.wikipedia.org/wiki/Theory_of_relativity).  
 
@@ -67,7 +71,7 @@ If the methodology _fails at a particular scale_ this tells you something about
 
 In the previous section on [Health](Health.md) we looked at how risk management was used by the UK government at the scale of _the whole country_. 
 
-## Invariance #3: Technology Invariance
+## Invariance #4: Technology Invariance
 
 In 2020 the world was plunged into pandemic.  Everything changed very quickly, including the nature of software development.  Lots of the practices we'd grown used to (such as XP's small, co-located teams) had to be jettisoned and replaced with Zoom calls and instant messaging apps.   This was a very sudden, rapid change in the technology we use to do our jobs, but in a more general sense we need to understand that Agile, XP and Scrum were invented at the turn of the 21st century.  The [Lean Manufacturing](https://en.wikipedia.org/wiki/Lean_manufacturing) movement originated post-WW2.  
 
@@ -79,7 +83,11 @@ The point I am making here is that while there are [technology tools to support
 
 ## Summing Up
 
--- sum up here.
+Humans have a built-in fight-or-flight mechanism which makes it hard for us to act rationally in times of stress.  And as we'll explore in [Agency Risk](../risks/Agency-Risk.md), firms are able to abuse their staff's loyalty or enthusiasm in order to get them to work much longer than is healthy for either them or their projects.  
+
+Risk management, like everything else, can be abused or misunderstood.  
+
+In this section, we've looked at an important "proof" - the idea that risk management applies irrespective of pressure, scale or technology trends (so far, at least).  This is really important as we need to know whether there's a point at which our tools won't apply anymore.
 
-On to [A Conversation](A-Conversation.md)
+In the next section, we'll start to look at how risk management can fit into working in our organisations, starting with discussing risk in a project team.  On to [A Conversation](A-Conversation.md)