Skip to content

Commit

Permalink
Starting to fix links
Browse files Browse the repository at this point in the history
  • Loading branch information
@robmoffat
robmoffat committed Jun 17, 2024
1 parent c7c08b3 commit 9425ef8
Show file tree
Hide file tree
Showing 15 changed files with 39 additions and 39 deletions.
2 changes: 1 addition & 1 deletion docs/bets/Coding-Bets.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -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](../risks/Software-Dependency-Risk.md) 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](/tags/Software-Dependency-Risk) problems. For example:

> "Let's explore using [ElasticSearch](https://en.wikipedia.org/wiki/Elasticsearch) for searching instead of SQL Statements."
Expand Down
2 changes: 1 addition & 1 deletion docs/bets/Purpose-Development-Team.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -133,7 +133,7 @@ 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](../risks/Feature-Risk.md#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](../thinking/Glossary.md#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](../risks/Feature-Risk.md) in the short term, whilst I might believe that [clearing technical debt](../risks/Complexity-Risk.md#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](../thinking/Glossary.md#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.md#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](../thinking/Glossary.md#internal-model) of the [balance of risks](../thinking/Glossary.md#balance-of-risk).

### Other Scenarios
Expand Down
2 changes: 1 addition & 1 deletion docs/estimating/Fill-The-Bucket.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -135,7 +135,7 @@ This is a really contrived example, but actually this represents _most of_ how b

1. Aren't there other options? We might be able to work nights to get the project done, or hire more staff, or give bonuses for overtime _or something_. In fact, in [Pressure](../practices/Pressure.md) we'll look at some of these factors.

2. We've actually got a project here which _degrades gracefully_. The costs of taking longer are clearly sign-posted in advance. In reality, the costs of missing a date might be much more disastrous: not getting your game completed for Christmas, missing a regulatory deadline, not being ready for an important demo - these are all-or-nothing outcomes where it's a [stark contrast between in-time and missing-the-bus](../risks/Deadline-Risk.md).
2. We've actually got a project here which _degrades gracefully_. The costs of taking longer are clearly sign-posted in advance. In reality, the costs of missing a date might be much more disastrous: not getting your game completed for Christmas, missing a regulatory deadline, not being ready for an important demo - these are all-or-nothing outcomes where it's a [stark contrast between in-time and missing-the-bus](/tags/Deadline-Risk).

3. Software development isn't generally isn't like this - as we will explore in the following sections, software development is _not_ in the [Fill-The-Bucket](Fill-The-Bucket.md) domain, generally.

Expand Down
6 changes: 3 additions & 3 deletions docs/estimating/Fixing-Scrum.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -30,11 +30,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](../thinking/Glossary.md#meet-reality): you are creating a [feedback loop](../thinking/Cadence.md) 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](../risks/Feature-Risk.md).
In Risk-First, we tend to call this validation step [Meeting Reality](../thinking/Glossary.md#meet-reality): you are creating a [feedback loop](../thinking/Cadence.md) 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).

![Feature Risk mitigated by Meeting Reality](/img/generated/estimating/scrum/scrum1.png)

The above diagram demonstrates us mitigating [Feature Risk](../risks/Feature-Risk.md) (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 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_.

![Schedule Risk for Stakeholders](/img/generated/estimating/scrum/scrum2.png)

Expand Down Expand Up @@ -122,7 +122,7 @@ How can we, as software developers, minimise the chance of building the wrong th

![Scrum](/img/generated/estimating/scrum/scrum4.png)

Look above at the diagram what Scrum is trying to do to mitigate [Feature Risk](../risks/Feature-Risk.md):
Look above at the diagram what Scrum is trying to do to mitigate [Feature Risk](/tags/Feature-Risk):

- We [Meet Reality](../thinking/Glossary.md#meet-reality) to ensure we've got a feedback loop.
- We **time-box** to avoid wasting stake-holders' time (Schedule Risk).
Expand Down
4 changes: 2 additions & 2 deletions docs/estimating/Fractals.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -98,11 +98,11 @@ 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](../risks/Boundary-Risk.md):
Let's look at the conclusions we reached in [Boundary Risk](/tags/Boundary-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.
- **Abstractions accrete too**: as we saw in [Process Risk](../risks/Process-Risk.md), we _encapsulate_ earlier abstractions in order to build later ones.
- **Abstractions accrete too**: as we saw in [Process Risk](/tags/Process-Risk), we _encapsulate_ earlier abstractions in order to build later ones.

If we accept this problem of the fractal nature of human desire, then we have to contend with the fact that our software systems are always going to get continually more complex to serve it.

Expand Down
14 changes: 7 additions & 7 deletions docs/estimating/Interference-Checklist.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -32,7 +32,7 @@ Download this in [PDF](/estimating/Interference-Checklist.pdf) or [Numbers](/est

| **Area** | **Concern** | **Notes** | **Point Value** |
| -------------------------------------------- | --------------------------------------------------------------------------------- | --------- | --------------- |
| **[Communication Risks](../risks/Communication-Risk.md)** | | | |
| **[Communication Risks](/tags/Communication-Risk)** | | | |
| **\- [Channel Risk](../risks/Communication-Risk.md#channel-risk)** | Requires input from other team members | | |
| | Requires input from other teams | | |
| | Requires input from other departments | | |
Expand Down Expand Up @@ -77,13 +77,13 @@ 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](../risks/Boundary-Risk.md)** | Ecosystem choice | | |
| **\- [Boundary Risk](/tags/Boundary-Risk)** | Ecosystem choice | | |
| | Platform choice | | |
| | App stores | | |
| | Language choice | | |
| | Market choice | | |
| | | | |
| **[Feature Risks](../risks/Feature-Risk.md)** | | | |
| **[Feature Risks](/tags/Feature-Risk)** | | | |
| **\- [Conceptual Integrity Risk](../risks/Feature-Risk.md#conceptual-integrity-risk)** | Requires new interface to be added | | |
| | Requires refactoring of existing interfaces | | |
| | Deprecates existing functionality | | |
Expand All @@ -108,7 +108,7 @@ Download this in [PDF](/estimating/Interference-Checklist.pdf) or [Numbers](/est
| | Market itself is uncertain | | |
| | Product needs to find it’s market | | |
| | | | |
| **[Agency Risks](../risks/Agency-Risk.md)** /| 3rd Party involved | | |
| **[Agency Risks](/tags/Agency-Risk)** /| 3rd Party involved | | |
| **[Trust Risk](../risks/Communication-Risk.md#trust--belief-risk)** / | Competitor involvement | | |
| **[Security Risks](../risks/Agency-Risk.md#security)**| General public involved | | |
| | Available on the open internet | | |
Expand All @@ -121,7 +121,7 @@ Download this in [PDF](/estimating/Interference-Checklist.pdf) or [Numbers](/est
| | Involves security infrastructure: firewalls, proxies, VPN etc. | | |
| | | | |
| **[Dependency Risks](../risks/Dependency-Risk.md)** | | | |
| **\- [Software Dependency Risk](../risks/Software-Dependency-Risk.md)**| Requires the introduction of a new dependency | | |
| **\- [Software Dependency Risk](/tags/Software-Dependency-Risk)**| Requires the introduction of a new dependency | | |
| | … which is immature | | |
| | … which must be chosen from competing alternatives | | |
| | … which is Open-Source | | |
Expand Down Expand Up @@ -149,11 +149,11 @@ Download this in [PDF](/estimating/Interference-Checklist.pdf) or [Numbers](/est
| | Has unusual hosting requirements | | |
| | Unfamiliar hardware involved | | |
| | | | |
| **\- [Process Risk](../risks/Process-Risk.md)** | Unfamiliar process for releasing | | |
| **\- [Process Risk](/tags/Process-Risk)** | Unfamiliar process for releasing | | |
| | New CI Steps Needed | | |
| | Unfamiliar approvals required | | |
| | | | |
| **\- [Deadline Risk](../risks/Deadline-Risk.md)** | Has components that must be completed during certain time windows (e.g. weekends) | | |
| **\- [Deadline Risk](/tags/Deadline-Risk)** | Has components that must be completed during certain time windows (e.g. weekends) | | |
| | Has components that must be completed before drop-dead dates | | |
| | | | |
| **[Operational Risk](../risks/Operational-Risk.md)** | Requires new or extra production support | | |
Expand Down
Loading

0 comments on commit 9425ef8

Please sign in to comment.