First draft of Lock-In risk

risk-first · Dec 28, 2024 · 15cefaa · 15cefaa
1 parent 37b9327
commit 15cefaa
Show file tree

Hide file tree

Showing 37 changed files with 5,276 additions and 267 deletions.
diff --git a/docs/estimating/Fractals.md b/docs/estimating/Fractals.md
@@ -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.

diff --git a/docs/estimating/Interference-Checklist.md b/docs/estimating/Interference-Checklist.md
@@ -77,7 +77,7 @@ Download this in [PDF](/estimating/Interference-Checklist.pdf) or [Numbers](/est
 |                                              | No prior work exists in this area                                                 |           |                 |
 |                                              | Significant algorithmic innovation is required                                    |           |                 |
 |                                              |                                                                                   |           |                 |
-| **\- [Boundary Risk](/tags/Boundary-Risk)**   | Ecosystem choice                                                                  |           |                 |
+| **\- [Lock-In Risk](/tags/Lock-In-Risk)**   | Ecosystem choice                                                                  |           |                 |
 |                                              | Platform choice                                                                   |           |                 |
 |                                              | App stores                                                                        |           |                 |
 |                                              | Language choice                                                                   |           |                 |

diff --git a/docs/practices/Development-And-Coding/Library-Adoption.md b/docs/practices/Development-And-Coding/Library-Adoption.md
@@ -23,7 +23,7 @@ practice:
   attendant:
    - tag: Software Dependency Risk
      reason: "Creates dependencies on the adopted standards and libraries."
-   - tag: Boundary Risk
+   - tag: Lock-In Risk
      reason: "Limits flexibility by adhering to specific standards and libraries which may be hard to change later."
    - tag: Funding Risk
      reason: "Can incur costs associated with adopting standards or libraries."

diff --git a/docs/practices/Development-And-Coding/Tool-Adoption.md b/docs/practices/Development-And-Coding/Tool-Adoption.md
@@ -26,7 +26,7 @@ practice:
      reason: "Can incur costs associated with acquiring and maintaining tools."
    - tag: Complexity Risk
      reason: "Integrating multiple tools can add complexity to the development process."
-   - tag: Boundary Risk
+   - tag: Lock-In Risk
      reason: Once tools become embedded in the process, they can be hard to change.
   related:
    - ../Planning-and-Management/Change-Management

diff --git a/docs/practices/External-Relations/Analysis.md b/docs/practices/External-Relations/Analysis.md
@@ -28,7 +28,7 @@ practice:
      reason: "Can be time-consuming, potentially delaying the start of development."
    - tag: Agency Risk
      reason: "Creates dependencies on the availability and accuracy of information from stakeholders."
-   - tag: Boundary Risk
+   - tag: Lock-In Risk
      reason: "Well-defined analysis can create rigid boundaries that limit flexibility."
   related:
    - ../Planning-and-Management/Requirements-Capture

diff --git a/docs/practices/External-Relations/Contracts.md b/docs/practices/External-Relations/Contracts.md
@@ -20,7 +20,7 @@ practice:
    - tag: Schedule Risk
      reason: "Establishes timelines and milestones to keep the project on track."
   attendant:
-   - tag: Boundary Risk
+   - tag: Lock-In Risk
      reason: "Contracts can create rigid boundaries that limit flexibility."
    - tag: Coordination Risk
      reason: "Contracting work can often involve setting careful terms to minimise coordination risks."

diff --git a/docs/practices/Planning-And-Management/Design.md b/docs/practices/Planning-And-Management/Design.md
@@ -24,7 +24,7 @@ practice:
    - tag: Market Risk
      reason:  (Research and) design allows you to leapfrog competitors and provide new sources of value.   
   attendant:
-   - tag: Boundary Risk
+   - tag: Lock-In Risk
      reason: "Design decisions can create boundaries that limit flexibility and adaptability."
    - tag: Software Dependency Risk
      reason: "Creates dependencies on software components and design patterns."

diff --git a/docs/practices/Planning-And-Management/Terms-Of-Reference.md b/docs/practices/Planning-And-Management/Terms-Of-Reference.md
@@ -18,7 +18,7 @@ practice:
    - tag: Coordination Risk
      reason: "Provides a clear framework for coordination among team members and stakeholders."
   attendant:
-   - tag: Boundary Risk
+   - tag: Lock-In Risk
      reason: "Poorly defined terms can create rigid boundaries that limit flexibility."
    - tag: Coordination Risk
      reason: "Requires alignment and coordination among all parties to agree to the terms."

diff --git a/docs/presentations/AgileVsOpenSource/index.md b/docs/presentations/AgileVsOpenSource/index.md
@@ -128,15 +128,15 @@ hide_table_of_contents: true
 
       <p>For example, if I was building a twitter-based website for printing T-Shirts, I might use some twitter APIs, some OAuth2 login piece, an API for getting the T-Shirts printed, and some kind of payments API like Stripe.  </p>
 
-      <p>One really key risk then for me is what I call Boundary Risk:  can I get all those dependencies to behave together in a cohesive manner.  What happens when the dependencies change?   Will they all co-operate in the way I want.  </p>
+      <p>One really key risk then for me is what I call Lock-In Risk:  can I get all those dependencies to behave together in a cohesive manner.  What happens when the dependencies change?   Will they all co-operate in the way I want.  </p>
 
       <p>If some of my libraries are written in Java, and some in C++, will I be in the situation above where I’m trying to join Lego with those sticklebrick things on the left?  </p>
 
       <p>There are various tools out there to help you with this exact problem: things like Kubernetes, Docker or running other languages on the JVM, for example… but those are not things Agile really cares about.</p>
 
       <p>One tennet of Agile development is do “the simplest thing that could possibly work”.</p>
 
-      <p>But is that going to lead you into this Boundary Risk problem?  Are you going to try to combine things that just don’t work together?</p>
+      <p>But is that going to lead you into this Lock-In Risk problem?  Are you going to try to combine things that just don’t work together?</p>
 
       <p>This goes back to that whole “Meta-Game” idea that I was talking about earlier.</p>
 
@@ -170,7 +170,7 @@ hide_table_of_contents: true
                 <img src="/img/presentations/AgileVsOpenSource/images/images.009.jpg" alt="Image of slide number 9" />
             </div>
             <div class="slide-notes">
-                      <p>So this Boundary Risk problem is getting worse over time.  Every day there are more and more Open Source libraries to choose from.  No one has time to evaluate even a tiny fraction of them.</p>
+                      <p>So this Lock-In Risk problem is getting worse over time.  Every day there are more and more Open Source libraries to choose from.  No one has time to evaluate even a tiny fraction of them.</p>
 
       <p>I call this the “Broccoli Problem”.  To start with, on the left, we had computers, which did.. well, computing. </p>
 

diff --git a/docs/risks/Complexity-Risk/Complexity-Risk.md b/docs/risks/Complexity-Risk/Complexity-Risk.md
@@ -43,7 +43,7 @@ It's the early 2000s: your Pokémon website is becoming really popular and profi
 
 ![Increasing the Cost To Reduce Operational Risks](/img/generated/risks/posters/complexity-risk2.svg) 
 
-It's the early 2020s: your Pokémon website is becoming really popular and profitable but you're worried that you're carrying too much [Operational Risk](tags/Operational-Risk).  You're able to turn on some backup features, load balancing and increase the instances via the console provided by your Cloud Service Provider, handing off the [Complexity Risk](/tags/Complexity-Risk) to them at some expense.  As well as helping with [Demand Management](/tags/Demand-Management), CSPs have allowed software developers to shift a lot of [Complexity Risk](/tags/Complexity-Risk) to them, the downsides being [cost](/tags/Funding-Risk) and [lock-in](/tags/Boundary-Risk).
+It's the early 2020s: your Pokémon website is becoming really popular and profitable but you're worried that you're carrying too much [Operational Risk](tags/Operational-Risk).  You're able to turn on some backup features, load balancing and increase the instances via the console provided by your Cloud Service Provider, handing off the [Complexity Risk](/tags/Complexity-Risk) to them at some expense.  As well as helping with [Demand Management](/tags/Demand-Management), CSPs have allowed software developers to shift a lot of [Complexity Risk](/tags/Complexity-Risk) to them, the downsides being [cost](/tags/Funding-Risk) and [lock-in](/tags/Lock-In-Risk).
 
 ## Example Threats
 

diff --git a/docs/risks/Complexity-Risk/Kolmogorov-Complexity.md b/docs/risks/Complexity-Risk/Kolmogorov-Complexity.md
@@ -92,4 +92,4 @@ In the third version of the program, we used the method `.repeat()`, which allow
 
 ![Using Libraries and Languages to reduce Codebase Risk](/img/generated/risks/complexity/libraries.svg)
 
-So as the above diagram shows, we can also reduce [Codebase Risk](/tags/Codebase-Risk) in our choice of _languages_ and _third party libraries_.   This doesn't come without a cost, though.  We are trading-off our own [Codebase Risk](/tags/Codebase-Risk) but increasing [Dependency Risk](/tags/Dependency-Risk) and [Boundary Risk](/tags/Boundary-Risk) instead.   
+So as the above diagram shows, we can also reduce [Codebase Risk](/tags/Codebase-Risk) in our choice of _languages_ and _third party libraries_.   This doesn't come without a cost, though.  We are trading-off our own [Codebase Risk](/tags/Codebase-Risk) but increasing [Dependency Risk](/tags/Dependency-Risk) and [Lock-In Risk](/tags/Lock-In-Risk) instead.
Original file line number	Diff line number	Diff line change
Expand Up		@@ -92,4 +92,4 @@ In the third version of the program, we used the method `.repeat()`, which allow

		![Using Libraries and Languages to reduce Codebase Risk](/img/generated/risks/complexity/libraries.svg)

		So as the above diagram shows, we can also reduce [Codebase Risk](/tags/Codebase-Risk) in our choice of _languages_ and _third party libraries_. This doesn't come without a cost, though. We are trading-off our own [Codebase Risk](/tags/Codebase-Risk) but increasing [Dependency Risk](/tags/Dependency-Risk) and [Boundary Risk](/tags/Boundary-Risk) instead.
		So as the above diagram shows, we can also reduce [Codebase Risk](/tags/Codebase-Risk) in our choice of _languages_ and _third party libraries_. This doesn't come without a cost, though. We are trading-off our own [Codebase Risk](/tags/Codebase-Risk) but increasing [Dependency Risk](/tags/Dependency-Risk) and [Lock-In Risk](/tags/Lock-In-Risk) instead.