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
Apply consistent document style to all Markdown pages (#300)
The following changes have been applied to Markdown files:
- Include Table of Contents
- Ensure sentence case heading
- Use `-` for unordered list style
-[What does this mean for me as a less-technical person?](#what-does-this-mean-for-me-as-a-less-technical-person)
21
+
-[What does this mean for me as a technical person?](#what-does-this-mean-for-me-as-a-technical-person)
22
+
-[Closing remarks](#closing-remarks)
23
+
3
24
Continuous improvement is the practice of iteratively reviewing processes and impediments and making incremental changes to reduce waste and increase quality.
4
25
5
26
## Quick start
@@ -33,10 +54,10 @@ The [Improvement Kata](https://www.atlassian.com/agile/agile-at-scale/using-impr
33
54
34
55
It is common to describe the iterative continuous improvement process as a cycle, and the most common is called Plan-Do-Check-Act (PDCA). This gives a mental model rather than a process to follow, but this can still be useful when adopting and maintaining continuous improvement. The PDCA cycle is attributed to Demming and Shewhart, and here adapted from [ASQ](https://asq.org/quality-resources/continuous-improvement), has four stages which are performed in a continuous loop:
35
56
36
-
***Plan**: Identify an opportunity and plan for change.
37
-
***Do**: Implement the change on a small scale.
38
-
***Check**: Use data to analyse the results of the change and determine whether it made a difference.
39
-
***Act**: If the change was successful, reinforce it or implement it on a wider scale and continuously assess your results. If the change did not work, begin the cycle again — i.e. try a different approach to driving improvement in this area.
57
+
-**Plan**: Identify an opportunity and plan for change.
58
+
-**Do**: Implement the change on a small scale.
59
+
-**Check**: Use data to analyse the results of the change and determine whether it made a difference.
60
+
-**Act**: If the change was successful, reinforce it or implement it on a wider scale and continuously assess your results. If the change did not work, begin the cycle again — i.e. try a different approach to driving improvement in this area.
40
61
41
62
At any one time, you may have several improvement initiatives in progress.
42
63
@@ -48,9 +69,9 @@ Continuous improvement has significant benefits for teams.
48
69
49
70
Improving processes:
50
71
51
-
* Reduces waste, leading to improved efficiency and productivity.
52
-
* Improves quality and reduce error rates.
53
-
* Leads to happier people and improved engagement, retention, and recruitment.
72
+
- Reduces waste, leading to improved efficiency and productivity.
73
+
- Improves quality and reduce error rates.
74
+
- Leads to happier people and improved engagement, retention, and recruitment.
54
75
55
76
It takes continuous effort to maintain and evolve processes in response to challenges and changing circumstances. Without this sustained effort, productivity and quality decline over time.
56
77
@@ -68,13 +89,13 @@ Where things like this are missing or need improvement, it is not tech debt &mda
68
89
69
90
The benefits of improving these areas are:
70
91
71
-
* Service has fewer bugs.
72
-
* Performance is more reliable.
73
-
* Services are more available.
74
-
* Services are more secure.
75
-
* Incidents are less severe.
76
-
* Incidents are detected earlier.
77
-
* Incidents are fixed more quickly.
92
+
- Service has fewer bugs.
93
+
- Performance is more reliable.
94
+
- Services are more available.
95
+
- Services are more secure.
96
+
- Incidents are less severe.
97
+
- Incidents are detected earlier.
98
+
- Incidents are fixed more quickly.
78
99
79
100
## Identifying improvement opportunities
80
101
@@ -88,29 +109,29 @@ The [Lean principles](principles.md) give some useful areas to consider.
88
109
89
110
Examples include:
90
111
91
-
* The way stories are analysed or elaborated.
92
-
* The way code is written or reviewed.
93
-
* The tools and techniques for testing.
94
-
* Communication and collaboration mechanisms within and between teams.
95
-
* Team structures.
112
+
- The way stories are analysed or elaborated.
113
+
- The way code is written or reviewed.
114
+
- The tools and techniques for testing.
115
+
- Communication and collaboration mechanisms within and between teams.
116
+
- Team structures.
96
117
97
118
### 2. Technical debt
98
119
99
120
Examples include:
100
121
101
-
* Code which needs to be refactored.
102
-
* Technologies which should be replaced.
103
-
* Areas with insufficient, inefficient or ineffective testing.
122
+
- Code which needs to be refactored.
123
+
- Technologies which should be replaced.
124
+
- Areas with insufficient, inefficient or ineffective testing.
104
125
105
126
### 3. Reliability and operability
106
127
107
128
Examples include:
108
129
109
-
* Automated build and deployment pipelines.
110
-
* Monitoring dashboards.
111
-
* Automated alerts.
112
-
* Application logs.
113
-
* Automated security testing.
130
+
- Automated build and deployment pipelines.
131
+
- Monitoring dashboards.
132
+
- Automated alerts.
133
+
- Application logs.
134
+
- Automated security testing.
114
135
115
136
## Prioritising
116
137
@@ -181,45 +202,45 @@ Other teams find it too difficult to determine relative priorities between featu
181
202
182
203
When seeking to [identify](#identifying-improvement-opportunities) and [prioritise](#prioritising) improvements, it can be helpful to have agreed metrics as a guide. These will be specific to each team, but some good defaults to start with are:
183
204
184
-
* Deployment frequency
185
-
* Lead time for changes
186
-
* Incident rate
187
-
* Mean time to recover
188
-
* Team happiness
205
+
- Deployment frequency
206
+
- Lead time for changes
207
+
- Incident rate
208
+
- Mean time to recover
209
+
- Team happiness
189
210
190
211
In addition, it is useful to track the proportion of time being spent on various activities so that the balance can be corrected if required:
191
212
192
-
* Features
193
-
* Bug fixing
194
-
* Operability
195
-
* Tech debt
196
-
* Other improvement work
213
+
- Features
214
+
- Bug fixing
215
+
- Operability
216
+
- Tech debt
217
+
- Other improvement work
197
218
198
219
## What does this mean for me as a less-technical person?
199
220
200
221
Good engineering and good ways of working are intrinsically connected. Every team member, regardless of how technical they perceive themselves, has a role to play. Think of how your own area of expertise may contribute to improving the metrics the team has selected. Looking at the examples in [Acting](#acting), the conditions to enable increased number of deployments, or better communication, are created by the team as a whole.
201
222
202
223
Same as for more technical people, continuous improvement should help you reduce waste and enable more focus on the core activities that deliver value from your role. Start with general concepts that may help you identify more specific areas for improvement:
203
224
204
-
* Can you observe handoffs between "teams-within-a-team"? How could you help reduce or avoid them?
205
-
* Do you have no understanding of what a part of the team is working on? How could that be made more visible?
206
-
* Do you find yourself spending significant time on activities which seem to have no influence on the value of what the team produces? Why do such activities exist, and how could they be reduced or avoided so that time can be better spent?
225
+
- Can you observe handoffs between "teams-within-a-team"? How could you help reduce or avoid them?
226
+
- Do you have no understanding of what a part of the team is working on? How could that be made more visible?
227
+
- Do you find yourself spending significant time on activities which seem to have no influence on the value of what the team produces? Why do such activities exist, and how could they be reduced or avoided so that time can be better spent?
207
228
208
229
## What does this mean for me as a technical person?
209
230
210
231
If you are an Engineer or Tester, continuous improvement will help you:
211
232
212
-
* Reduce waste and spend more time delivering value for users.
213
-
* Implement features and fix bugs more quickly and safely.
214
-
* Spend less time on menial or repetitive work.
233
+
- Reduce waste and spend more time delivering value for users.
234
+
- Implement features and fix bugs more quickly and safely.
235
+
- Spend less time on menial or repetitive work.
215
236
216
237
You have an important role to play!
217
238
218
-
* Make sure you understand the user needs well enough to have an informed conversation about the relative priority of the functional work items.
219
-
* Express technical work in terms of the benefits it will deliver so that as a team you can have a meaningful conversation about relative priorities.
220
-
* Play an active role in backlog refinement and planning, ensuring that operability and reliability work is adequately represented.
221
-
* Be bold and make sure technical quality is maintained.
222
-
* But also, be pragmatic and accept that all systems have imperfections and some degree of tech debt.
239
+
- Make sure you understand the user needs well enough to have an informed conversation about the relative priority of the functional work items.
240
+
- Express technical work in terms of the benefits it will deliver so that as a team you can have a meaningful conversation about relative priorities.
241
+
- Play an active role in backlog refinement and planning, ensuring that operability and reliability work is adequately represented.
242
+
- Be bold and make sure technical quality is maintained.
243
+
- But also, be pragmatic and accept that all systems have imperfections and some degree of tech debt.
Copy file name to clipboardExpand all lines: inclusive-language.md
+14-7Lines changed: 14 additions & 7 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,9 +1,16 @@
1
1
# Inclusive language
2
2
3
+
-[Inclusive language](#inclusive-language)
4
+
-[Context](#context)
5
+
-[Background](#background)
6
+
-[Details](#details)
7
+
-[Renaming the master branch in GitHub](#renaming-the-master-branch-in-github)
8
+
-[Further reading](#further-reading)
9
+
3
10
## Context
4
11
5
-
* This is part of a broader [quality framework](README.md)
6
-
* This guidance has been co-authored with the NHS Digital [EMBRACE network](https://digital.nhs.uk/about-nhs-digital/corporate-information-and-documents/staff-networks#ethnic-minorities-broadening-racial-awareness-and-cultural-exchange-embrace-) and the [Lesbian, Gay, Bisexual, Transgender, Queer and Allies (LGBTQ+) network](https://digital.nhs.uk/about-nhs-digital/corporate-information-and-documents/staff-networks#lesbian-gay-bisexual-transgender-queer-and-allies-lgbtq-)
12
+
- This is part of a broader [quality framework](README.md)
13
+
- This guidance has been co-authored with the NHS Digital [EMBRACE network](https://digital.nhs.uk/about-nhs-digital/corporate-information-and-documents/staff-networks#ethnic-minorities-broadening-racial-awareness-and-cultural-exchange-embrace-) and the [Lesbian, Gay, Bisexual, Transgender, Queer and Allies (LGBTQ+) network](https://digital.nhs.uk/about-nhs-digital/corporate-information-and-documents/staff-networks#lesbian-gay-bisexual-transgender-queer-and-allies-lgbtq-)
Copy file name to clipboardExpand all lines: patterns/architect-for-flow.md
+35-27Lines changed: 35 additions & 27 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,10 +1,18 @@
1
1
# Architect for flow
2
2
3
+
-[Architect for flow](#architect-for-flow)
4
+
-[Context](#context)
5
+
-[The pattern](#the-pattern)
6
+
-[Benefits](#benefits)
7
+
-[Caveats](#caveats)
8
+
-[Details](#details)
9
+
-[Examples](#examples)
10
+
3
11
## Context
4
12
5
-
* These notes are part of a broader set of [principles](../principles.md)
6
-
* This pattern is closely related to the [deliver little and often](little-and-often.md) pattern
7
-
* See also: [structured code](../practices/structured-code.md)
13
+
- These notes are part of a broader set of [principles](../principles.md)
14
+
- This pattern is closely related to the [deliver little and often](little-and-often.md) pattern
15
+
- See also: [structured code](../practices/structured-code.md)
8
16
9
17
## The pattern
10
18
@@ -16,39 +24,39 @@ One key consideration is how best to break the system down into independent serv
16
24
17
25
In high level terms, systems which are designed to maximise rapid, reliable delivery and operations:
18
26
19
-
* Are cost efficient: teams don't waste their time fighting the tools or working with difficult architectures
20
-
* Improve business agility: these systems allow teams to respond more quickly to changes
21
-
* Improve reliability: these systems are easier to understand, which leads to fewer failures and shorter recovery times
22
-
* Improve team happiness: engineers are happy when the tools they work with let them get on with what they do best
27
+
- Are cost efficient: teams don't waste their time fighting the tools or working with difficult architectures
28
+
- Improve business agility: these systems allow teams to respond more quickly to changes
29
+
- Improve reliability: these systems are easier to understand, which leads to fewer failures and shorter recovery times
30
+
- Improve team happiness: engineers are happy when the tools they work with let them get on with what they do best
23
31
24
32
In many cases, building a system as a set of independently running services/components has benefits:
25
33
26
-
* Multiple components enable parallel development work by multiple teams
27
-
* Teams can work at their own cadence
28
-
* Changes with each component are easier to reason about and test
29
-
* The best tools can be chosen for each job, rather than being hampered by a common set of technologies which need to be adequate for all parts of the system but may only suit some parts of the system well
30
-
* Concerns such as scaling, resilience, etc, can be tailored on a per-component basis — for example avoiding the waste generated by scaling a monolith for the benefit of scaling one small aspect of the system
31
-
* It is possible to isolate the impact of catastrophic failure of any individual component
32
-
* Self-contained components with clear boundaries of responsibility reduce hand-offs between teams
33
-
* Components with clear boundaries of responsibility are more easily replaced
34
-
* Components with clear boundaries of responsibility more likely to be reusable — note: this does not promote building "generic" components — rather, components that have a clear scope
34
+
- Multiple components enable parallel development work by multiple teams
35
+
- Teams can work at their own cadence
36
+
- Changes with each component are easier to reason about and test
37
+
- The best tools can be chosen for each job, rather than being hampered by a common set of technologies which need to be adequate for all parts of the system but may only suit some parts of the system well
38
+
- Concerns such as scaling, resilience, etc, can be tailored on a per-component basis — for example avoiding the waste generated by scaling a monolith for the benefit of scaling one small aspect of the system
39
+
- It is possible to isolate the impact of catastrophic failure of any individual component
40
+
- Self-contained components with clear boundaries of responsibility reduce hand-offs between teams
41
+
- Components with clear boundaries of responsibility are more easily replaced
42
+
- Components with clear boundaries of responsibility more likely to be reusable — note: this does not promote building "generic" components — rather, components that have a clear scope
35
43
36
44
## Caveats
37
45
38
-
* This pattern must not compromise quality: automation (including of quality control) is essential for safe implementation of this pattern
39
-
* Architectures with multiple moving parts are more complicated. While splitting a system into multiple components is often a good idea, "too many" components can cause more harm than good. There is usually a sweet spot for how many components to break a system down into — and for small or simple systems a monolith might be better. In distributed systems:
40
-
* There are more failure modes to test, since calls which go over the network can fail in more ways than simple method invocations
41
-
* Versioning becomes a more complicated concern, and additional effort is required to ensure component APIs are compatible as each changes independently
42
-
* Clean domain boundaries are essential for safe implementation of this pattern
43
-
* Comprehensive monitoring and alerting is essential for safe implementation of this pattern
44
-
* Components should be built because working in that way gives benefits, not purely because the components might be reused later: if they are later reused, that's even better
46
+
- This pattern must not compromise quality: automation (including of quality control) is essential for safe implementation of this pattern
47
+
- Architectures with multiple moving parts are more complicated. While splitting a system into multiple components is often a good idea, "too many" components can cause more harm than good. There is usually a sweet spot for how many components to break a system down into — and for small or simple systems a monolith might be better. In distributed systems:
48
+
- There are more failure modes to test, since calls which go over the network can fail in more ways than simple method invocations
49
+
- Versioning becomes a more complicated concern, and additional effort is required to ensure component APIs are compatible as each changes independently
50
+
- Clean domain boundaries are essential for safe implementation of this pattern
51
+
- Comprehensive monitoring and alerting is essential for safe implementation of this pattern
52
+
- Components should be built because working in that way gives benefits, not purely because the components might be reused later: if they are later reused, that's even better
45
53
46
54
## Details
47
55
48
-
* Split services vertically via [bounded contexts](https://martinfowler.com/bliki/BoundedContext.html) rather than horizontally via technology layers: for example, do not implement dedicated processes to update databases or configuration
49
-
* For components to be genuinely independent they need to only interact via their public APIs (e.g. not via a shared database)
50
-
* Components should handle the entirety of their bounded context, for example persistence, logic and presentation (though obviously not all components will involve all of these layers)
51
-
* This pattern applies to existing services as well as greenfield development projects — please see Martin Fowler's [StranglerFigApplication blog](https://martinfowler.com/bliki/StranglerFigApplication.html)
56
+
- Split services vertically via [bounded contexts](https://martinfowler.com/bliki/BoundedContext.html) rather than horizontally via technology layers: for example, do not implement dedicated processes to update databases or configuration
57
+
- For components to be genuinely independent they need to only interact via their public APIs (e.g. not via a shared database)
58
+
- Components should handle the entirety of their bounded context, for example persistence, logic and presentation (though obviously not all components will involve all of these layers)
59
+
- This pattern applies to existing services as well as greenfield development projects — please see Martin Fowler's [StranglerFigApplication blog](https://martinfowler.com/bliki/StranglerFigApplication.html)
52
60
53
61
TO DO: reference to the NHS UI toolkit (for presentation fragments)
0 commit comments