You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
* Add Any Decision Record (ADR) template
* Incorporate feedback
* Include link to ADR in the review playbook
* Fix broken link
* Improve the wording
* Emphasise the importance of managing the risk and tech debt
-`Deciders`: List all the key decision makers and state whether it is an internal decision or it requires additional endorsement or approval of an external group or governing body like `Tech Radar | Engineering | Architecture | Solution Assurance | Clinical Assurance | Technical Review and Governance | Information Governance | Cyber Security | Live Services Board` or any other
Describe the context and the problem statement. Is there a relationship to other decisions previously made? Are there any dependencies and/or constraints within which the decision will be made? Do these need to be reviewed or validated? Please, note that environmental limitations or restrictions such as accepted technology standards, commonly recognised and used patterns, engineering and architecture principles, organisation policies, governance and so on, may as an effect narrow down the choices. This should also be explicitly documented, as this is a point-in-time decision with the intention of being able to articulate it clearly and justify it later.
24
+
25
+
## Decision
26
+
27
+
### Assumptions
28
+
29
+
Summarise the underlying assumptions in the environment in which you make the decision. This could be related to technology changes, forecast of the monetary and non-monetary costs, further delivery commitments, impactful external drivers etc., and any known unknowns that translate to risks.
30
+
31
+
### Drivers
32
+
33
+
List the decision drivers that motivate this change or course of action. This may include any identified risks and residual risks after applying the decision.
34
+
35
+
### Options
36
+
37
+
Consider a comprehensive set of alternative options.
38
+
39
+
### Outcome
40
+
41
+
State the decision outcome as a result of taking into account all of the above.
42
+
43
+
### Rationale
44
+
45
+
Provide a rationale for the decision that is based on weighing the options to ensure that the same questions are not going to be asked again and again unless the decision needs to be superseded.
46
+
47
+
## Consequences
48
+
49
+
Describe the resulting context, after applying the decision. All the identified consequences should be listed here, not just the positive ones. Any decision comes with many implications. For example, it may introduce a need to make other decisions as an effect of cross-cutting concerns; it may impact structural or operational characteristics of the software, and influence non-functional requirements; as a result, some things may become easier or more difficult to do because of this change. What are the trade-offs?
50
+
51
+
## Compliance
52
+
53
+
Establish how the success is going to be measured. Once implemented, the effect might lend itself to be measured, therefore if appropriate a set of criteria for success could be established. Compliance checks of the decision can be manual or automated using a fitness function. If it is the latter this section can then specify how that fitness function would be implemented and whether there are any other changes to the codebase needed to measure this decision for compliance.
54
+
55
+
## Notes
56
+
57
+
Include any links to existing epics, decisions, dependencies, risks, and policies related to this decision record. This section could also include any further links to configuration items within the project or the codebase, signposting to the areas of change.
58
+
59
+
It is important that if the decision is sub-optimal or the choice is tactical or misaligned with the strategic directions the risk related to it is identified and clearly articulated. As a result of that, the expectation is that a [Tech Debt](./tech-debt.md) record is going to be created on the backlog.
60
+
61
+
## Tags
62
+
63
+
`#availability|#security|#resilience|#scalability|#maintainability|#accessibility|…` these tags are intended to be operational, structural or cross-cutting architecture characteristics to link to related decisions.
Copy file name to clipboardExpand all lines: insights/review.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -96,7 +96,7 @@ Finally (and most importantly) identify actions to move the score upward.
96
96
- Risky items and dependencies are clearly indicated and work to reduce risk is prioritised.
97
97
- The plan gets the right balance between delivering features and operational aspects.
98
98
- We track risks, issues, assumptions and dependencies ('RAID') and work creatively to resolve them.
99
-
- We keep a log of key technical and product decisions and who approved them.
99
+
- We keep a log of key technical and product decisions and who approved them, e.g. by using the [Any Decision Record template](../any-decision-record-template.md).
-[5. Deliver as fast as possible](#5-deliver-as-fast-as-possible)
10
+
-[6. Respect for people](#6-respect-for-people)
11
+
-[7. Optimise the whole](#7-optimise-the-whole)
12
+
13
+
## Details
4
14
5
15
Our principles guide the way we work and interact with each other. They are based on the seven Lean principles as expressed in Lean Software Development: An Agile Toolkit by Mary Poppendieck and Tom Poppendieck.
6
16
7
-
# Summary
8
-
9
-
1.[Eliminate waste](#1-eliminate-waste)
10
-
2.[Build quality in](#2-build-quality-in)
11
-
3.[Create knowledge](#3-create-knowledge)
12
-
4.[Defer commitment](#4-defer-commitment)
13
-
5.[Deliver as fast as possible](#5-deliver-as-fast-as-possible)
14
-
6.[Respect for people](#6-respect-for-people)
15
-
7.[Optimise the whole](#7-optimise-the-whole)
16
-
17
-
# Details
18
-
19
-
## 1. Eliminate waste
17
+
### 1. Eliminate waste
20
18
21
19
Waste is anything that interferes with giving customers what they really value at the time and place where it will provide the most value. Here are some examples, listed against the seven types of waste identified by Lean.
22
20
@@ -52,7 +50,7 @@ Waste is anything that interferes with giving customers what they really value a
52
50
53
51
**Defects** due to not understanding requirements properly or bugs leaking through. Use approaches described in the next section.
54
52
55
-
## 2. Build quality in
53
+
###2. Build quality in
56
54
57
55
The following practices support the principle of building quality in.
58
56
@@ -88,7 +86,7 @@ The following practices support the principle of building quality in.
88
86
89
87
**Bake in [observability](practices/observability.md) and [reliability](practices/service-reliability.md).**[SERVICE-RELIABILITY](https://service-manual.nhs.uk/service-standard/14-operate-a-reliable-service) Understand requirements as a team, treated as unspoken user needs. Consider it through every stage of delivery. Verify it automatically and continuously. Practice incident management resolution using techniques like [game days](https://wa.aws.amazon.com/wat.concept.gameday.en.html).
90
88
91
-
## 3. Create knowledge
89
+
###3. Create knowledge
92
90
93
91
**Generate knowledge.** Make time for activities which help us learn by doing, e.g. spikes, proof of concepts. Validation of technical design comes as the code is being written — expect the design to evolve. Encourage learning and experimentation.
94
92
@@ -98,7 +96,9 @@ The following practices support the principle of building quality in.
98
96
99
97
**Record knowledge.** e.g. tests, self-documenting code, self-documenting system (e.g. [OpenAPI](https://swagger.io/resources/open-api/)), documentation — in that order.
100
98
101
-
## 4. Defer commitment
99
+
**Record decisions.** Use the [Any Decision Record template](any-decision-record-template.md) to document point-in-time decisions providing information like context, assumption, drivers, options and rationale to articulate the decision for the stakeholders and your future self. Always, consider and compare options as a decision made without that is not a decision.
100
+
101
+
### 4. Defer commitment
102
102
103
103
**Make decisions small** by breaking a big problem down.
104
104
@@ -108,7 +108,9 @@ The following practices support the principle of building quality in.
108
108
109
109
**Just enough, just in time**— applied to all stages: research, analysis, product design, planning, technical design.
110
110
111
-
## 5. Deliver as fast as possible
111
+
**Recognise architecturally significant decisions** that affect the structure, non-functional characteristics, dependencies, interfaces or construction techniques. A good architecture decision is one that helps guide development teams in making the right technical choices.
112
+
113
+
### 5. Deliver as fast as possible
112
114
113
115
We need to figure out how to deliver software as fast as possible. This reduces the cycle time for change, allows the business to reach the point of increased learning sooner and provides more immediate gratification and feedback for the customer. This also allows us to defer commitment as much as possible.
114
116
@@ -122,7 +124,7 @@ We need to figure out how to deliver software as fast as possible. This reduces
122
124
123
125
**Choose the right tools for each job.**[SERVICE-TOOLS](https://service-manual.nhs.uk/service-standard/11-choose-the-right-tools-and-technology) Balance autonomy and conformity: unnecessary proliferation of a wide variety of tools impacts overall effectiveness, but limiting too much promotes "least worst" choices. Note that "each job" does not have to mean a single toolset for a service: consider a polyglot approach for component-based services.
124
126
125
-
## 6. Respect for people
127
+
###6. Respect for people
126
128
127
129
**Communicate** e.g. stand-ups, retrospectives, show and tell / demo.
128
130
@@ -140,7 +142,7 @@ We need to figure out how to deliver software as fast as possible. This reduces
140
142
141
143
**[Use inclusive language.](inclusive-language.md)** Avoid terms which cause hurt and offence, including if they have historically been considered industry-standard terms.
142
144
143
-
## 7. Optimise the whole
145
+
###7. Optimise the whole
144
146
145
147
**Visualise the work.** Map the value stream with a Kanban board, identify bottlenecks.
0 commit comments