diff --git a/docs/estimating/Fixing-Scrum.md b/docs/estimating/Fixing-Scrum.md index 026dade17..5c0bd63a8 100644 --- a/docs/estimating/Fixing-Scrum.md +++ b/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). diff --git a/docs/estimating/Interference-Checklist.md b/docs/estimating/Interference-Checklist.md index ae5693f00..7d1a9806d 100644 --- a/docs/estimating/Interference-Checklist.md +++ b/docs/estimating/Interference-Checklist.md @@ -30,134 +30,134 @@ This is just meant to be used as a starting point - feel free to adapt this to t Download this in [PDF](/estimating/Interference-Checklist.pdf) or [Numbers](/estimating/Interference-Checklist.numbers) format. -| **Area** | **Concern** | **Notes** | **Point Value** | -| -------------------------------------------- | --------------------------------------------------------------------------------- | --------- | --------------- | -| **[Communication Risks](/tags/Communication-Risk)** | | | | -| **\- [Channel Risk](/tags/Channel-Risk)** | Requires input from other team members | | | -| | Requires input from other teams | | | -| | Requires input from other departments | | | -| | Input required, not clear from who, but further up the hierarchy | | | -| | | | | -| **\- [Protocol Risk](/tags/Protocol-Risk)** | Requires agreement on a protocol / data format with another team | | | -| | Requires regular meetings | | | -| | | | | -| **\- [Learning-Curve Risk](/tags/Learning-Curve-Risk)** | Requires learning an unfamiliar technology / standard | | | -| | Untrained staff involved in the delivery | | | -| | | | | -| **\- [Invisibility Risk](/tags/Invisibility-Risk)** | Specifications not available | | | -| | Reverse-Engineering Required | | | -| | | | | -| **\- [Internal-Model Risk](/tags/Internal-Model-Risk)** | Involves reconciliation with another data source | | | -| | Involves real-time data synchronisation | | | -| | | | | -| **\- [Map-And-Territory Risk](/tags/Map-And-Territory-Risk)** | Use of metrics | | | -| | Use of bonuses | | | -| | Competing targets / KPIs | | | -| | | | | -| **[Coordination Risks](/tags/Coordination-Risk)** | Task will require an approval from someone outside the team | | | -| | Task requires sign-off from a committee/board | | | -| | Requires other tasks to be completed | | | -| | Work must be coordinated amongst multiple stakeholders | | | -| | Approvals are required from multiple stakeholders | | | -| | Different timezones involved | | | -| | Data must be synchronised across different machines | | | -| | Developers will be required to work together | | | -| | Teams are required to work together | | | -| | | | | -| **[Complexity Risks](/tags/Complexity-Risk)** | | | | -| **\- [Codebase Risk](/tags/Codebase-Risk)** | Involves refactoring | | | -| | Introduces new languages / DSLs | | | -| | Requires adding significant code | | | -| | Can’t be easily unit-tested | | | -| | Requires manual testing | | | -| | Requires deleting significant code | | | -| | Creates new repos | | | -| | | | | -| **\- [Dead-End Risk](/tags/Dead-End-Risk)** | Involves experimentation about best approach | | | -| | No prior work exists in this area | | | -| | Significant algorithmic innovation is required | | | -| | | | | -| **\- [Lock-In Risk](/tags/Lock-In-Risk)** | Ecosystem choice | | | -| | Platform choice | | | -| | App stores | | | -| | Language choice | | | -| | Market choice | | | -| | | | | -| **[Feature Risks](/tags/Feature-Risk)** | | | | -| **\- [Conceptual Integrity Risk](/tags/Conceptual-Integrity-Risk)** | Requires new interface to be added | | | -| | Requires refactoring of existing interfaces | | | -| | Deprecates existing functionality | | | -| | Requested by multiple stakeholders | | | -| | | | | -| **\- [Regression Risk](/tags/Regression-Risk)** | Changes existing functionality | | | -| | | | | -| **\- [Feature-Access Risk](/tags/Feature-Access-Risk)**| Interface Experimentation required | | | -| | Varied user population | | | -| | Accessibility requirements | | | -| | Localisation Requirements | | | -| | | | | +| **Area** | **Concern / Threat Origin** | **Notes** | **Point Value** | +|---------------------------------------------------------|-----------------------------------------------------------------------------------|-----------|-----------------| +| **[Communication Risks](/tags/Communication-Risk)** | | | | +| | Requires input from other team members | | | +| | Requires input from other teams | | | +| | Requires input from other departments | | | +| | Input required, not clear from who, but further up the hierarchy | | | +| | | | | +| | Requires agreement on a protocol / data format with another team | | | +| | Requires regular meetings | | | +| | | | | +| | Requires learning an unfamiliar technology / standard | | | +| | Untrained staff involved in the delivery | | | +| | | | | +| | Specifications not available | | | +| | Reverse-Engineering Required | | | +| | | | | +| **\- [Internal-Model Risk](/tags/Internal-Model-Risk)** | Involves reconciliation with another data source | | | +| | Involves real-time data synchronisation | | | +| | | | | +| | Use of metrics | | | +| | Use of bonuses | | | +| | Competing targets / KPIs | | | +| | | | | +| **[Coordination Risks](/tags/Coordination-Risk)** | Task will require an approval from someone outside the team | | | +| | Task requires sign-off from a committee/board | | | +| | Requires other tasks to be completed | | | +| | Work must be coordinated amongst multiple stakeholders | | | +| | Approvals are required from multiple stakeholders | | | +| | Different timezones involved | | | +| | Data must be synchronised across different machines | | | +| | Developers will be required to work together | | | +| | Teams are required to work together | | | +| | | | | +| **[Complexity Risks](/tags/Complexity-Risk)** | | | | +| | Involves refactoring | | | +| | Introduces new languages / DSLs | | | +| | Requires adding significant code | | | +| | Can’t be easily unit-tested | | | +| | Requires manual testing | | | +| | Requires deleting significant code | | | +| | Creates new repos | | | +| | | | | +| | Involves experimentation about best approach | | | +| | No prior work exists in this area | | | +| | Significant algorithmic innovation is required | | | +| | | | | +| **\- [Lock-In Risk](/tags/Lock-In-Risk)** | Ecosystem choice | | | +| | Platform choice | | | +| | App stores | | | +| | Language choice | | | +| | Market choice | | | +| | | | | +| **[Feature Risks](/tags/Feature-Risks)** | | | | +| | Requires new interface to be added | | | +| | Requires refactoring of existing interfaces | | | +| | Deprecates existing functionality | | | +| | Requested by multiple stakeholders | | | +| | | | | +| | Changes existing functionality | | | +| | | | | +| | Interface Experimentation required | | | +| | Varied user population | | | +| | Accessibility requirements | | | +| | Localisation Requirements | | | +| | | | | | **\- [Implementation Risk](/tags/Implementation-Risk)** | Developer unfamiliar with the requirements / system | | | -| | Known corner-cases | | | -| | Home-grown protocols vs. standards | | | -| | | | | -| **\- [Feature-Fit](/tags/Feature-Fit-Risk)**| Success criteria hard to define | | | -| | Difficult-to-access user base | | | -| | | | | -| **\- [Market Risk](/tags/Market-Risk)** | Rapidly changing market | | | -| | Market needs are not clear | | | -| | Market itself is uncertain | | | -| | Product needs to find it’s market | | | -| | | | | -| **[Agency Risks](/tags/Agency-Risk)** /| 3rd Party involved | | | -| **[Trust Risk](/tags/Trust-And-Belief-Risk)** / | Competitor involvement | | | -| **[Security Risks](/tags/Security-Risk)**| General public involved | | | -| | Available on the open internet | | | -| | Requires authentication / authorisation schemes | | | -| | Requires cryptography | | | -| | Involves crowdsourcing | | | -| | Involves untrusted data-sources | | | -| | Involves multiple processes / threads cooperating | | | -| | Involves payments | | | -| | Involves security infrastructure: firewalls, proxies, VPN etc. | | | -| | | | | -| **[Dependency Risks](/tags/Dependency-Risk)** | | | | -| **\- [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 | | | -| | … which is In-House | | | -| | … which is Commercial | | | -| | | | | -| **\- [Scarcity Risk](/tags/Scarcity-Risk)** | Requires booking time with a 3rd party | | | -| | Requires specific licenses / approvals | | | -| | | | | -| **\- [Funding Risk](/tags/Funding-Risk)** | Requires payment by a customer for completed work | | | -| | Requires agreement on pricing / budget | | | -| | | | | -| **\- [Staff Risk](/tags/Staff-Risk)** | Requires involvement from other members of staff | | | -| | Requires hiring-in new specialist skills | | | -| | Has dependency on key-persons | | | -| | | | | -| **\- [Red-Queen Risk](/tags/Red-Queen-Risk)** | Dependency on rapidly changing/unpublished standards | | | -| | Dependency on rapidly evolving 3rd party code | | | -| | | | | -| **\- [Schedule Risk](/tags/Schedule-Risk)** | Task is repetitive | | | -| | Task takes a long time | | | -| | Task is unusually tedious | | | -| | | | | -| **\- [Reliability Risk](/tags/Reliability-Risk)** | Has strict reliability / response time requirements | | | -| | Has unusual hosting requirements | | | -| | Unfamiliar hardware involved | | | -| | | | | -| **\- [Process Risk](/tags/Process-Risk)** | Unfamiliar process for releasing | | | -| | New CI Steps Needed | | | -| | Unfamiliar approvals required | | | -| | | | | -| **\- [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](/tags/Operational-Risk)** | Requires new or extra production support | | | -| | Requires special roll-out | | | -| | Legal Requirements | | | -| | Regulatory Requirements | | | -| | | | | \ No newline at end of file +| | Known corner-cases | | | +| | Home-grown protocols vs. standards | | | +| | | | | +| **\- [Feature-Fit](/tags/Feature-Fit-Risk)** | Success criteria hard to define | | | +| | Difficult-to-access user base | | | +| | | | | +| **\- [Market Risk](/tags/Market-Risk)** | Rapidly changing market | | | +| | Market needs are not clear | | | +| | Market itself is uncertain | | | +| | Product needs to find it’s market | | | +| | | | | +| **[Agency Risks](/tags/Agency-Risk)** / | 3rd Party involved | | | +| | Competitor involvement | | | +| **[Security Risks](/tags/Security-Risk)** | General public involved | | | +| | Available on the open internet | | | +| | Requires authentication / authorisation schemes | | | +| | Requires cryptography | | | +| | Involves crowdsourcing | | | +| | Involves untrusted data-sources | | | +| | Involves multiple processes / threads cooperating | | | +| | Involves payments | | | +| | Involves security infrastructure: firewalls, proxies, VPN etc. | | | +| | | | | +| **[Dependency Risks](/tags/Dependency-Risk)** | | | | +| | Requires the introduction of a new dependency | | | +| | … which is immature | | | +| | … which must be chosen from competing alternatives | | | +| | … which is Open-Source | | | +| | … which is In-House | | | +| | … which is Commercial | | | +| | | | | +| | Requires booking time with a 3rd party | | | +| | Requires specific licenses / approvals | | | +| | | | | +| **\- [Funding Risk](/tags/Funding-Risk)** | Requires payment by a customer for completed work | | | +| | Requires agreement on pricing / budget | | | +| | | | | +| | Requires involvement from other members of staff | | | +| | Requires hiring-in new specialist skills | | | +| | Has dependency on key-persons | | | +| | | | | +| | Dependency on rapidly changing/unpublished standards | | | +| | Dependency on rapidly evolving 3rd party code | | | +| | | | | +| **\- [Schedule Risk](/tags/Schedule-Risk)** | Task is repetitive | | | +| | Task takes a long time | | | +| | Task is unusually tedious | | | +| | | | | +| **\- [Reliability Risk](/tags/Reliability-Risk)** | Has strict reliability / response time requirements | | | +| | Has unusual hosting requirements | | | +| | Unfamiliar hardware involved | | | +| | | | | +| **\- [Process Risk](/tags/Process-Risk)** | Unfamiliar process for releasing | | | +| | New CI Steps Needed | | | +| | Unfamiliar approvals required | | | +| | | | | +| **\- [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](/tags/Operational-Risk)** | Requires new or extra production support | | | +| | Requires special roll-out | | | +| | Legal Requirements | | | +| | Regulatory Requirements | | | +| | | | | \ No newline at end of file diff --git a/docs/estimating/Kitchen-Cabinet.md b/docs/estimating/Kitchen-Cabinet.md index 13b2f7d09..d74e461f0 100644 --- a/docs/estimating/Kitchen-Cabinet.md +++ b/docs/estimating/Kitchen-Cabinet.md @@ -122,11 +122,11 @@ This is important: the point at which you present your estimate is the point of ![Accepting an estimate](/img/generated/estimating/accept_estimate.svg) -The diagram above is an example of this. A supplier is bidding for a contract with a client. The client has functionality they want build (or [Feature Risk](/tags/Feature-Risk) as we call it on Risk-First). The supplier needs money to keep their business going ([Funding Risk](/tags/Funding-Risk) on this diagram). +The diagram above is an example of this. A supplier is bidding for a contract with a client. The client has functionality they want build (or [Feature Fit Risk](/tags/Feature-Fit-Risk) as we call it on Risk-First). The supplier needs money to keep their business going ([Funding Risk](/tags/Funding-Risk) on this diagram). -If the estimate is accepted, the supplier's [Funding Risk](/tags/Funding-Risk) is transferred to the client (the requester of the estimate). Conversely, the trade is that the client's [Feature Risk](/tags/Feature-Risk) is transferred to the supplier. +If the estimate is accepted, the supplier's [Funding Risk](/tags/Funding-Risk) is transferred to the client (the requester of the estimate). Conversely, the trade is that the client's [Feature Fit Risk](/tags/Feature-Fit-Risk) is transferred to the supplier. -If the supplier is short on opportunities or funds, there is a tendency to under-estimate. That's because the [Feature Risk](/tags/Feature-Risk) is a problem for the supplier _in the future_, whereas their [Funding Risk](/tags/Funding-Risk) is a problem _right now_. +If the supplier is short on opportunities or funds, there is a tendency to under-estimate. That's because the [Feature Fit Risk](/tags/Feature-Fit-Risk) is a problem for the supplier _in the future_, whereas their [Funding Risk](/tags/Funding-Risk) is a problem _right now_. You can often see suppliers under-bid on projects because of this future discounting, which we discussed before in [Evaluating Risk](/thinking/Evaluating-Risk#discounting). @@ -144,9 +144,9 @@ 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 Risk](/tags/Feature-Risk) vary to take up the slack. +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. -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 Risk](/tags/Feature-Risk) within an available budget. +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. \ No newline at end of file diff --git a/docs/estimating/Risk-First-Analysis.md b/docs/estimating/Risk-First-Analysis.md index 723871127..f229305c8 100644 --- a/docs/estimating/Risk-First-Analysis.md +++ b/docs/estimating/Risk-First-Analysis.md @@ -29,7 +29,7 @@ The previous article, [Fixing Scrum](Fixing-Scrum), examined Scrum's idea of "Sp ![Scrum: Consequences Of Time-Boxing](/img/generated/estimating/planner/scrum-consequences.svg) -The diagram above shows this behaviour in the form of a [Risk-First Diagram](/thinking/Risk-First-Diagrams). Put briefly: _risks_ ([Schedule Risk](/tags/Schedule-Risk), [Feature Risk](/tags/Feature-Risk)) are addressed by actions such as "Development", "Review" or "Planning Poker". +The diagram above shows this behaviour in the form of a [Risk-First Diagram](/thinking/Risk-First-Diagrams). Put briefly: _risks_ ([Schedule Risk](/tags/Schedule-Risk), [Feature Fit Risk](/tags/Feature-Fit-Risk)) are addressed by actions such as "Development", "Review" or "Planning Poker". If you're new to [Risk-First](https://www.riskfirst.org) then it's probably worth explaining at this point that one of the purposes of this project is to enumerate the different types of risk you could face running a software project. You can begin to learn about them all [here](/risks/Start). Suffice to say, we have icons to represent each of these kinds of risks, and the rest of this article will introduce some of them to you in passing. @@ -103,9 +103,9 @@ So, this diagram encapsulates the reason why we might fix the rendering bug: it Let's move on to task 2, the **Search Function**, as shown in the above diagram. -As with the **Rendering Bug**, above, we lose something: [Feature Risk](/tags/Feature-Risk), which is the risk (to us) that the features our product is supplying don't meet the client's (or the market's) requirements. Writing code is all about identifying and removing [Feature Risk](/tags/Feature-Risk), and building products that fit the needs of their users. +As with the **Rendering Bug**, above, we lose something: [Feature Fit Risk](/tags/Feature-Fit-Risk), which is the risk (to us) that the features our product is supplying don't meet the client's (or the market's) requirements. Writing code is all about identifying and removing [Feature Fit Risk](/tags/Feature-Fit-Risk), and building products that fit the needs of their users. -So as in the Rendering Bug example, we can show [Feature Risk](/tags/Feature-Risk) being eliminated by showing it on the left with a strike-out line. However, it's been established during analysis that the way to implement this feature is to introduce [ElasticSearch](https://www.elastic.co), a third-party piece of software. This in itself is an [Attendant Risk](/tags/Attendant-Risk) of taking that action: +So as in the Rendering Bug example, we can show [Feature Fit Risk](/tags/Feature-Fit-Risk) being eliminated by showing it on the left with a strike-out line. However, it's been established during analysis that the way to implement this feature is to introduce [ElasticSearch](https://www.elastic.co), a third-party piece of software. This in itself is an [Attendant Risk](/tags/Attendant-Risk) of taking that action: - Are we going to find that easy to deploy and maintain? - What impact will this have on hosting charges? diff --git a/docs/estimating/Stop-Estimating-Start-Navigating.md b/docs/estimating/Stop-Estimating-Start-Navigating.md index 897bb8dda..ffe9b284d 100644 --- a/docs/estimating/Stop-Estimating-Start-Navigating.md +++ b/docs/estimating/Stop-Estimating-Start-Navigating.md @@ -106,7 +106,7 @@ What does that mean? The problem is that estimation only addresses a single risk: runway risk/time resource. It says nothing about other risks that you might bump into. -Why is all my code in the bin? I guess either it was badly written (which, probably it isn't, given that it's probably not objectively worse than the 10% that is in production) or, more likely, it didn't address _Feature RIsk_ properly, or, it was useful, but people didn't find out about how amazing it was. Or, it was built to work on top of X, but then X was decomissioned (Dependency Risk) or, the budget was cut from the department and there was no funding (Dependency Risk... but maybe caused by Feature RIsk)? +Why is all my code in the bin? I guess either it was badly written (which, probably it isn't, given that it's probably not objectively worse than the 10% that is in production) or, more likely, it didn't address [Feature Fit Risk](/tags/Feature-Fit-Risk) properly, or, it was useful, but people didn't find out about how amazing it was. Or, it was built to work on top of X, but then X was decommissioned (Dependency Risk) or, the budget was cut from the department and there was no funding (Dependency Risk... but maybe caused by Feature Fit Risk)? No estimates says forget about trying to get the numbers right, because you can't. What's better than that? Let's try and focus on reducing that 90% of waste by thinking about _risks other than time_. diff --git a/docs/practices/Deployment-And-Operations/Redundancy.md b/docs/practices/Deployment-And-Operations/Redundancy.md index 49419be64..839e9a413 100644 --- a/docs/practices/Deployment-And-Operations/Redundancy.md +++ b/docs/practices/Deployment-And-Operations/Redundancy.md @@ -14,8 +14,6 @@ practice: - "Resilience" - "Stockpiling" mitigates: - - tag: Feature Risk - reason: "Ensures system availability and reliability in case of component failure." - tag: Reliability Risk reason: "Minimizes operational disruptions by providing backup components." - tag: Security Risk diff --git a/docs/practices/Development-And-Coding/Coding.md b/docs/practices/Development-And-Coding/Coding.md index d5cbf51e3..183592a9e 100644 --- a/docs/practices/Development-And-Coding/Coding.md +++ b/docs/practices/Development-And-Coding/Coding.md @@ -13,7 +13,7 @@ practice: - "Development" - "Software Engineering" mitigates: - - tag: Feature Risk + - tag: Feature Fit Risk reason: "Build or improve some features which our clients will find useful." - tag: Process Risk reason: Problems and edge cases with software processes can be fixed by adding code. diff --git a/docs/practices/External-Relations/Fundraising.md b/docs/practices/External-Relations/Fundraising.md index a91650768..11cfacb47 100644 --- a/docs/practices/External-Relations/Fundraising.md +++ b/docs/practices/External-Relations/Fundraising.md @@ -18,7 +18,7 @@ practice: reason: "Provides necessary financial resources to support the startup’s operations and growth." - tag: Market Risk reason: "Allows the startup to invest in market research and customer acquisition." - - tag: Feature Risk + - tag: Feature Fit Risk reason: "Enables the startup to fund product development and innovation." attendant: - tag: Agency Risk diff --git a/docs/presentations/HowToWin/index.md b/docs/presentations/HowToWin/index.md index 21a316b83..188f90ae6 100644 --- a/docs/presentations/HowToWin/index.md +++ b/docs/presentations/HowToWin/index.md @@ -450,7 +450,7 @@ hide_table_of_contents: true

So, the payoff, for doing Fixed Price Contract is that your business is going to make money - it’s funding risks will be reduced.

-

But, for the client, the great thing about a Fixed Price Contract is that they know how much the project will cost. So, you’ve taken on their funding risk. And of course, you’ve taken on their Feature Risk - you have to provide the Features of the software that this client needs.

+

But, for the client, the great thing about a Fixed Price Contract is that they know how much the project will cost. So, you’ve taken on their funding risk. And of course, you’ve taken on their Feature Risks - you have to provide the Features of the software that this client needs.

So in order to make accurate estimates, and win these bets, it’s all about having a good internal model of the development process, and how long things take.

diff --git a/docs/risks/Complexity-Risk/Complexity-Analogies.md b/docs/risks/Complexity-Risk/Complexity-Analogies.md index 5b888e868..0c47d11a8 100644 --- a/docs/risks/Complexity-Risk/Complexity-Analogies.md +++ b/docs/risks/Complexity-Risk/Complexity-Analogies.md @@ -38,11 +38,11 @@ The most common way we talk about [Complexity Risk](/tags/Complexity-Risk) in so > "Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite... The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organisations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise." - [Ward Cunningham, 1992, _Wikipedia, Technical Debt_](https://en.wikipedia.org/wiki/Technical_debt) -Building a low-complexity first-time solution is often a waste: in the first version, we're usually interested in reducing [Feature Risk](/tags/Feature-Risk) as fast as possible. That is, putting working software in front of users to get [feedback](/thinking/Meeting-Reality). We would rather carry [Complexity Risk](/tags/Complexity-Risk) than take on more [Schedule Risk](/tags/Schedule-Risk). +Building a low-complexity first-time solution is often a waste: in the first version, we're usually interested in reducing [Feature Fit Risk](/tags/Feature-Fit-Risk) as fast as possible. That is, putting working software in front of users to get [feedback](/thinking/Meeting-Reality). We would rather carry [Complexity Risk](/tags/Complexity-Risk) than take on more [Schedule Risk](/tags/Schedule-Risk). -So a quick-and-dirty, over-complex implementation mitigates the same [Feature Risk](/tags/Feature-Risk) and allows you to [Meet Reality](/thinking/Meeting-Reality) faster. +So a quick-and-dirty, over-complex implementation mitigates the same [Feature Fit Risk](/tags/Feature-Fit-Risk) and allows you to [Meet Reality](/thinking/Meeting-Reality) faster. -But having mitigated the [Feature Risk](/tags/Feature-Risk) this way, you are likely exposed to a higher level of [Complexity Risk](/tags/Complexity-Risk) than would be desirable. This "carries forward" and means that in the future, you're going to be slower. As in the case of a real debt, "servicing" the debt incurs a steady, regular cost. +But having mitigated the [Feature Fit Risk](/tags/Feature-Fit-Risk) this way, you are likely exposed to a higher level of [Complexity Risk](/tags/Complexity-Risk) than would be desirable. This "carries forward" and means that in the future, you're going to be slower. As in the case of a real debt, "servicing" the debt incurs a steady, regular cost. ### Kitchen Analogy @@ -67,7 +67,7 @@ In Brooks' essay "No Silver Bullet - Essence and Accident in Software Engineerin The problem with this definition is that we are accepting features of our software as _essential_. -Applying Risk-First, if you want to mitigate some [Feature Risk](/tags/Feature-Risk) then you have to pick up [Complexity Risk](/tags/Complexity-Risk) as a result. But, that's a _choice you get to make_. +Applying Risk-First, if you want to mitigate some [Feature Fit Risk](/tags/Feature-Fit-Risk) then you have to pick up [Complexity Risk](/tags/Complexity-Risk) as a result. But, that's a _choice you get to make_. ![Mitigating Feature Risk](/img/generated/risks/complexity/feature-creep.svg) diff --git a/docs/risks/Dependency-Risks/Process-Risk/Process-Risk.md b/docs/risks/Dependency-Risks/Process-Risk/Process-Risk.md index 0d816b9f9..0f871f8a1 100644 --- a/docs/risks/Dependency-Risks/Process-Risk/Process-Risk.md +++ b/docs/risks/Dependency-Risks/Process-Risk/Process-Risk.md @@ -26,7 +26,7 @@ Process Risk intersects with several other types of risk we've covered so far: - [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). - [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 Risks](/tags/Feature-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). +- [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). So clearly there is overlap here with other types of risk we've looked at: a good process should be reliable, available (i.e. not scarce), transparent in its communications and obedient to our wishes. In fact, Process Risk really should be thought of as just a wrapper for other things. Nevertheless, it's a useful pattern to talk about as it comes up repeatedly. diff --git a/docs/risks/Dependency-Risks/Software-Dependency-Risks/Software-Dependency-Risk.md b/docs/risks/Dependency-Risks/Software-Dependency-Risks/Software-Dependency-Risk.md index 3edcaaef4..44941ad4f 100644 --- a/docs/risks/Dependency-Risks/Software-Dependency-Risks/Software-Dependency-Risk.md +++ b/docs/risks/Dependency-Risks/Software-Dependency-Risks/Software-Dependency-Risk.md @@ -149,7 +149,7 @@ All 3 approaches involve a different risk-profile. Let's look at each in turn, Way before the Internet, this was the only game in town. Tool support was very thin-on-the-ground. Algorithms could be distributed as code snippets _in books and magazines_ which could be transcribed and run, and added to your program. This spirit lives on somewhat in StackOverflow and JSFiddle, where you are expected to "adopt" others' code into your own project. Code-your-own is still the best option if you have highly bespoke requirements, or are dealing with unusual environmental contexts. -One of the hidden risks of embarking on a code-your-own approach is that the features you need are _not_ apparent from the outset. What might appear to be a trivial implementation of some piece of functionality can often turn into its own industry as more and more hidden [Feature Risk](/tags/Feature-Risk) is uncovered. For example, as we discussed in our earlier treatment of [Dead-End Risk](/tags/Dead-End-Risk), building log-in screens _seemed like a good idea_. However, this gets out-of-hand fast when you need: +One of the hidden risks of embarking on a code-your-own approach is that the features you need are _not_ apparent from the outset. What might appear to be a trivial implementation of some piece of functionality can often turn into its own industry as more and more hidden [Feature Fit Risk](/tags/Feature-Fit-Risk) is uncovered. For example, as we discussed in our earlier treatment of [Dead-End Risk](/tags/Dead-End-Risk), building log-in screens _seemed like a good idea_. However, this gets out-of-hand fast when you need: - A password reset screen - To email the reset links to the user @@ -158,7 +158,7 @@ One of the hidden risks of embarking on a code-your-own approach is that the fea - Reminders to complete the sign up process - ... and so on. -![Code-Your-Own mitigates immediate feature risk, but at the expense of schedule risk, complexity risk and communication risk. There is also a hidden risk of features you don't yet know you need.](/img/generated/risks/software-dependency/code-your-own.svg) +![Code-Your-Own mitigates immediate [Feature Fit Risk](/tags/Feature-Fit-Risk), but at the expense of schedule risk, complexity risk and communication risk. There is also a hidden risk of features you don't yet know you need.](/img/generated/risks/software-dependency/code-your-own.svg) ### Unwritten Software @@ -193,7 +193,7 @@ By choosing a particular software library, we are making a move on the [Risk Lan - **[Communication Risk](/tags/Communication-Risk)**: because we now have to learn how to communicate with this new dependency. - **[Lock-In Risk](/tags/Lock-In-Risk)**: - because now are limited to using the functionality provided by this dependency. We have chosen it over alternatives and changing to something else would be more work and therefore costly. -But, it's quite possible that we could wind up in a worse place than we started out, by using a library that's out-of-date, riddled with bugs or badly supported. i.e. full of new, hidden [Feature Risk](/tags/Feature-Risk). +But, it's quite possible that we could wind up in a worse place than we started out, by using a library that's out-of-date, riddled with bugs or badly supported. i.e. full of new, hidden [Feature Fit Risk](/tags/Feature-Fit-Risk). It's _really easy_ to make bad decisions about which tools to use because the tools don't (generally) advertise their deficiencies. After all, they don't generally know how _you_ will want to use them. @@ -211,7 +211,7 @@ But, leaving that aside, let's try to build a model of what this decision making In the table above, I am summarising three different sources (linked at the end of the section), which give descriptions of which factors to look for when choosing open-source libraries. Here are some take-aways: - - **[Feature Risk](/tags/Feature-Risk) is a big concern**: How can you be sure that the project will do what you want it to do ahead of schedule? Will it contain bugs or missing features? By looking at factors like _release frequency_ and _size of the community_ you get a good feel for this which is difficult to fake. + - **[Feature Fit Risk](/tags/Feature-Fit-Risk) is a big concern**: How can you be sure that the project will do what you want it to do ahead of schedule? Will it contain bugs or missing features? By looking at factors like _release frequency_ and _size of the community_ you get a good feel for this which is difficult to fake. - **[Lock-In Risk](/tags/Lock-In-Risk) is also very important**: You are going to have to _live_ with your choices for the duration of the project, so it's worth spending the effort to either ensure that you're not going to regret the decision, or that you can change direction later. - **Third is [Communication Risk](/tags/Communication-Risk)**: how well does the project deal with its users? If a project is "famous", then it has communicated its usefulness to a wide, appreciative audience. Avoiding [Communication Risk](/tags/Communication-Risk) is also a good reason to pick _tools you are already familiar with_. @@ -248,7 +248,7 @@ SaaS is now a very convenient way to provide _commercial_ software. Popular ex The diagram above summarises the risks raised in some of the available literature (sources below). Some take-aways: - Clearly, [Operational Risk](/tags/Operational-Risk) is now a big concern. By depending on a third-party organisation you are tying yourself to its success or failure in a much bigger way than just by using a piece of open-source software. What happens to data security, both in the data centre and over the Internet? Although you might choose a SaaS solution to mitigate _internal_ [Operational Risk](/tags/Operational-Risk), you might just be "throwing it over the wall" to a third party, who might do a worse job. -- With [Feature Risk](/tags/Feature-Risk) you now have to contend with the fact that the software will be upgraded _outside your control_, and you may have limited control over which features get added or changed. +- With [Feature Fit Risk](/tags/Feature-Fit-Risk) you now have to contend with the fact that the software will be upgraded _outside your control_, and you may have limited control over which features get added or changed. - [Lock-In Risk](/tags/Lock-In-Risk) is also a different proposition: you are tied to the software provider by _a contract_. If the service changes in the future, or isn't to your liking, you can't simply fork the code (like you could with an open source project). ![Risk Tradeoff From Using Software as a Service (SaaS)](/img/generated/risks/software-dependency/saas.svg) diff --git a/docs/risks/Environmental-Risks/Legal-Risk/Legal-Risk.md b/docs/risks/Environmental-Risks/Legal-Risk/Legal-Risk.md index 36f40ae4e..4a16d6888 100644 --- a/docs/risks/Environmental-Risks/Legal-Risk/Legal-Risk.md +++ b/docs/risks/Environmental-Risks/Legal-Risk/Legal-Risk.md @@ -29,7 +29,7 @@ If you are building software, you need to account for the [Legal Risks](/tags/Le An online gaming firm is considering adding forum features, where players can discuss tactics and events related to their game and upload images and videos that they've created related to the game. -![Mitigating Feature Risk Leads to Legal Risk](/img/generated/risks/posters/legal-risk.svg) +![Mitigating Feature Fit Risk Leads to Legal Risk](/img/generated/risks/posters/legal-risk.svg) But as the above diagram shows, mitigating these [Feature Fit Risks](/tags/Feature-Fit-Risk) naively exposes the firm to [Leagl Risks](/tags/Legal-Risk). For example: diff --git a/docs/risks/Environmental-Risks/Operational-Risk/Operations-Management.md b/docs/risks/Environmental-Risks/Operational-Risk/Operations-Management.md index 52ff2328f..22837f645 100644 --- a/docs/risks/Environmental-Risks/Operational-Risk/Operations-Management.md +++ b/docs/risks/Environmental-Risks/Operational-Risk/Operations-Management.md @@ -86,7 +86,7 @@ So there is a tension between "you only get one chance to make a first impressio 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 Risk](/tags/Feature-Risk) and [Operational Risk](/tags/Operational-Risk) of going to production (pressure to improve). +- 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 "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: @@ -101,6 +101,6 @@ The "should we ship?" decision is therefore a complex one. In [Meeting Reality] ## The End Of The Road -In a way, [actions](/tags/Take-Action) like **Design** and **Improvement** bring us right back to where we started from: identifying [Dependency Risks](/tags/Dependency-Risk), [Feature Risks](/tags/Feature-Risk) and [Complexity Risks](/tags/Complexity-Risk) that hinder our operation, and mitigating them through actions like _software development_. +In a way, [actions](/tags/Take-Action) like [Design](/tags/Design) and [Development](/tags/Coding) bring us right back to where we started from: identifying [Dependency Risks](/tags/Dependency-Risk), [Feature Risks](/tags/Feature-Risks) and [Complexity Risks](/tags/Complexity-Risk) that hinder our operation, and mitigating them through actions like _software development_. Our safari of risk is finally complete: it's time to reflect on what we've seen in the next section, [Staging and Classifying](Staging-And-Classifying). \ No newline at end of file diff --git a/docs/risks/Feature-Risks/Application.md b/docs/risks/Feature-Risks/Application.md.unused similarity index 100% rename from docs/risks/Feature-Risks/Application.md rename to docs/risks/Feature-Risks/Application.md.unused diff --git a/docs/risks/Feature-Risks/Feature-Fit-Risk.md b/docs/risks/Feature-Risks/Feature-Fit-Risk.md index ea9796432..a0f22d871 100644 --- a/docs/risks/Feature-Risks/Feature-Fit-Risk.md +++ b/docs/risks/Feature-Risks/Feature-Fit-Risk.md @@ -9,7 +9,7 @@ sidebar_position: 1 tags: - Risks - Feature Fit Risk -part_of: Feature Risk +part_of: Feature Risks --- diff --git a/docs/risks/Feature-Risks/Feature-Risks.md b/docs/risks/Feature-Risks/Feature-Risks.md index b20c8647d..d1c906ebe 100644 --- a/docs/risks/Feature-Risks/Feature-Risks.md +++ b/docs/risks/Feature-Risks/Feature-Risks.md @@ -9,25 +9,19 @@ featured: tweet: yes slug: /risks/Feature-Risks tags: - - Feature Risk + - Feature Risks --- -[Feature Risks](/tags/Feature-Risk) are types of risks to do with functionality that you need to have in the software you're building. +[Feature Risks](/tags/Feature-Risks) are types of risk to do with functionality that you need to have in the software you're building. -[Feature Risk](/tags/Feature-Risk) is very fundamental: if your project has _no_ [Feature Risk](/tags/Feature-Risk) it would be perfect! And we all know that _can't happen_. +[Feature Risks](/tags/Feature-Risks) are very fundamental: if your project has _no_ [Feature Risk](/tags/Feature-Risks) it would be perfect! And we all know that _can't happen_. -As a rule of thumb, [Feature Risk](/tags/Feature-Risk) exists in the gaps between what users _want_, and what they _are given_. +As a rule of thumb, [Feature Risks](/tags/Feature-Risks) exist in the gap between what users _want_, and what they _are given_. -Not considering [Feature Risk](/tags/Feature-Risk) means that you might be building the wrong functionality, for the wrong audience or at the wrong time. Eventually, this will come down to lost money, business, acclaim, or whatever you are doing your project for. So let's unpack this concept into some of its variations. - -[Feature Risks](/tags/Feature-Risk) are a family of risks you face any time you start trying to build functionality to serve a client. In this article, we will: - - - Break down and talk about the main different types of [Feature Risks](/tags/Feature-Risk) on software projects. - - Discuss how they occur and what action you can take to address them. - - Analyse the family of feature risks along three axes of _fit_, _audience_ and _change_. +Not considering [Feature Risks](/tags/Feature-Risks) means that you might be building the wrong functionality, for the wrong audience or at the wrong time. Eventually, this will come down to lost money, business, acclaim, or whatever you are doing your project for. So let's unpack this concept into some of its variations. ## Types Of Feature Risk - + diff --git a/docs/risks/Feature-Risks/Implementation-Risk.md b/docs/risks/Feature-Risks/Implementation-Risk.md index a7a045fbc..aacfcfc59 100644 --- a/docs/risks/Feature-Risks/Implementation-Risk.md +++ b/docs/risks/Feature-Risks/Implementation-Risk.md @@ -8,7 +8,7 @@ sidebar_position: 2 tags: - Risks - Implementation Risk -part_of: Feature Risk +part_of: Feature Risks --- diff --git a/docs/risks/Feature-Risks/Market-Risk.md b/docs/risks/Feature-Risks/Market-Risk.md index 3a78e1e50..90f16ccda 100644 --- a/docs/risks/Feature-Risks/Market-Risk.md +++ b/docs/risks/Feature-Risks/Market-Risk.md @@ -8,7 +8,7 @@ sidebar_position: 4 tags: - Risks - Market Risk -part_of: Feature Risk +part_of: Feature Risks --- diff --git a/docs/risks/Feature-Risks/Analysis.md b/docs/risks/Feature-Risks/Service-Quality-Model.md.unused similarity index 54% rename from docs/risks/Feature-Risks/Analysis.md rename to docs/risks/Feature-Risks/Service-Quality-Model.md.unused index 92d7faddf..154df6cc0 100644 --- a/docs/risks/Feature-Risks/Analysis.md +++ b/docs/risks/Feature-Risks/Service-Quality-Model.md.unused @@ -8,21 +8,6 @@ sidebar_position: 9 sidebar_label: Analysis --- -## Fashion - -Fashion plays a big part in IT. By being _fashionable_, web-sites are communicating: _this is a new thing_, _this is relevant_, _this is not terrible_. All of which is mitigating a [Communication Risk](/tags/Communication-Risk). Users are all-too-aware that the Internet is awash with terrible, abandon-ware sites that are going to waste their time. - -How can you communicate that you're not one of them to your users? - -## Delight - -If this breakdown of [Feature Risk](/tags/Feature-Risk) seems reductive, then try not to think of it that way: the aim _of course_ should be to delight users, and turn them into fans. - -Consider [Feature Risk](/tags/Feature-Risk) from both the down-side and the up-side: - - - What are we missing? - - How can we be _even better_? - ## Analysis So far in this section, we've simply seen a bunch of different types of [Feature Risk](/tags/Feature-Risk). But we're going to be relying heavily on [Feature Risk](/tags/Feature-Risk) as we go on in order to build our understanding of other risks, so it's probably worth spending a bit of time up front to classify what we've found. @@ -53,20 +38,11 @@ For further reading, you can check out [The Service Quality Model](https://en.wi In the [Staging And Classifying](/risks/Staging-And-Classifying) section we'll come back and build on this model further. -### Fit and Audience - -Two risks, [Feature Access Risk](/tags/Feature-Access-Risk) and [Market Risk](/tags/Market-Risk), consider _fit_ for a whole _audience_ of users. They are different: just as it's possible to have a small audience, but a large revenue, it's possible to have a product which has low [Feature Access Risk](/tags/Feature-Access-Risk) (i.e lots of users can access it without difficulty) but high [Market Risk](/tags/Market-Risk) (i.e. the market is highly volatile or capricious in it's demands). _Online services_ often suffer from this [Market Risk](/tags/Market-Risk) roller-coaster, being one moment highly valued and the next irrelevant. - - - **Market Risk** is therefore risk to _income_ from the market changing. - - **Feature Access Risk** is risk to _audience_ changing. - -### Fit, Audience and Change +## Delight -Risks of Change either of the product or the expectations of clients.(/img/generated/risks/feature/all-feature-risk2.svg) +If this breakdown of [Feature Risks](/tags/Feature-Risks) seems reductive, then try not to think of it that way: the aim _of course_ should be to delight users, and turn them into fans. -Two risks further consider how the **fit** and **audience** _change_: [Regression Risk](/tags/Regression-Risk) and [Feature Drift Risk](/tags/Feature-Drift-Risk). We call this _Change_ in the sense that: +Consider [Feature Risks](/tags/Feature-Risks) from both the down-side and the up-side: - - Our product's features _evolve_ with time and the changes made by the development team. - - Our audience changes and evolves as it is exposed to our product and competing products. - - The world as a whole is an evolving system within which our product exists. - \ No newline at end of file + - What are we missing? + - How can we be _even better_? diff --git a/docs/tags.yml b/docs/tags.yml index 7a7a46bd7..0bbe1adc1 100644 --- a/docs/tags.yml +++ b/docs/tags.yml @@ -126,9 +126,9 @@ label: "Feature Fit Risk" permalink: "Feature-Fit-Risk" -"Feature Risk": - label: "Feature Risk" - permalink: "Feature-Risk" +"Feature Risks": + label: "Feature Risks" + permalink: "Feature-Risks" "Funding Risk": label: "Funding Risk" diff --git a/numbers/Practices.numbers b/numbers/Practices.numbers index f03a7677c..29b59a720 100644 Binary files a/numbers/Practices.numbers and b/numbers/Practices.numbers differ diff --git a/src/images/generated/estimating/accept_estimate.adl b/src/images/generated/estimating/accept_estimate.adl index c8d3fa0c7..7ceddf58a 100644 --- a/src/images/generated/estimating/accept_estimate.adl +++ b/src/images/generated/estimating/accept_estimate.adl @@ -7,7 +7,7 @@ - +