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

any-decision-record-template.md

@@ -1,4 +1,4 @@
-# ADR-XXX: ADR (Any Decision Record) Template
+# ADR-nnn: Any Decision Record Template
 
 >|              | |
 >| ------------ | --- |
@@ -10,7 +10,7 @@
 
 ---
 
-- [ADR-XXX: ADR (Any Decision Record) Template](#adr-xxx-adr-any-decision-record-template)
+- [ADR-nnn: Any Decision Record Template](#adr-nnn-any-decision-record-template)
   - [Context](#context)
   - [Decision](#decision)
     - [Assumptions](#assumptions)

continuous-improvement.md

@@ -1,5 +1,26 @@
 # Continuous improvement
 
+- [Continuous improvement](#continuous-improvement)
+  - [Quick start](#quick-start)
+  - [Improvement Kata](#improvement-kata)
+  - [Plan-Do-Check-Act improvement cycles](#plan-do-check-act-improvement-cycles)
+  - [Benefits](#benefits)
+    - [Maintain and improve processes](#maintain-and-improve-processes)
+    - [Control technical debt](#control-technical-debt)
+    - [Improve reliability and operability](#improve-reliability-and-operability)
+  - [Identifying improvement opportunities](#identifying-improvement-opportunities)
+    - [1. Process or practice](#1-process-or-practice)
+    - [2. Technical debt](#2-technical-debt)
+    - [3. Reliability and operability](#3-reliability-and-operability)
+  - [Prioritising](#prioritising)
+    - [Prioritising tech debt](#prioritising-tech-debt)
+  - [Acting](#acting)
+  - [Making time](#making-time)
+  - [Measurement](#measurement)
+  - [What does this mean for me as a less-technical person?](#what-does-this-mean-for-me-as-a-less-technical-person)
+  - [What does this mean for me as a technical person?](#what-does-this-mean-for-me-as-a-technical-person)
+  - [Closing remarks](#closing-remarks)
+
 Continuous improvement is the practice of iteratively reviewing processes and impediments and making incremental changes to reduce waste and increase quality.
 
 ## Quick start
@@ -33,10 +54,10 @@ The [Improvement Kata](https://www.atlassian.com/agile/agile-at-scale/using-impr
 
 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:
 
-* **Plan**: Identify an opportunity and plan for change.
-* **Do**: Implement the change on a small scale.
-* **Check**: Use data to analyse the results of the change and determine whether it made a difference.
-* **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.
+- **Plan**: Identify an opportunity and plan for change.
+- **Do**: Implement the change on a small scale.
+- **Check**: Use data to analyse the results of the change and determine whether it made a difference.
+- **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.
 
 At any one time, you may have several improvement initiatives in progress.
 
@@ -48,9 +69,9 @@ Continuous improvement has significant benefits for teams.
 
 Improving processes:
 
-* Reduces waste, leading to improved efficiency and productivity.
-* Improves quality and reduce error rates.
-* Leads to happier people and improved engagement, retention, and recruitment.
+- Reduces waste, leading to improved efficiency and productivity.
+- Improves quality and reduce error rates.
+- Leads to happier people and improved engagement, retention, and recruitment.
 
 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.
 
@@ -68,13 +89,13 @@ Where things like this are missing or need improvement, it is not tech debt &mda
 
 The benefits of improving these areas are:
 
-* Service has fewer bugs.
-* Performance is more reliable.
-* Services are more available.
-* Services are more secure.
-* Incidents are less severe.
-* Incidents are detected earlier.
-* Incidents are fixed more quickly.
+- Service has fewer bugs.
+- Performance is more reliable.
+- Services are more available.
+- Services are more secure.
+- Incidents are less severe.
+- Incidents are detected earlier.
+- Incidents are fixed more quickly.
 
 ## Identifying improvement opportunities
 
@@ -88,29 +109,29 @@ The [Lean principles](principles.md) give some useful areas to consider.
 
 Examples include:
 
-* The way stories are analysed or elaborated.
-* The way code is written or reviewed.
-* The tools and techniques for testing.
-* Communication and collaboration mechanisms within and between teams.
-* Team structures.
+- The way stories are analysed or elaborated.
+- The way code is written or reviewed.
+- The tools and techniques for testing.
+- Communication and collaboration mechanisms within and between teams.
+- Team structures.
 
 ### 2. Technical debt
 
 Examples include:
 
-* Code which needs to be refactored.
-* Technologies which should be replaced.
-* Areas with insufficient, inefficient or ineffective testing.
+- Code which needs to be refactored.
+- Technologies which should be replaced.
+- Areas with insufficient, inefficient or ineffective testing.
 
 ### 3. Reliability and operability
 
 Examples include:
 
-* Automated build and deployment pipelines.
-* Monitoring dashboards.
-* Automated alerts.
-* Application logs.
-* Automated security testing.
+- Automated build and deployment pipelines.
+- Monitoring dashboards.
+- Automated alerts.
+- Application logs.
+- Automated security testing.
 
 ## Prioritising
 
@@ -181,45 +202,45 @@ Other teams find it too difficult to determine relative priorities between featu
 
 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:
 
-* Deployment frequency
-* Lead time for changes
-* Incident rate
-* Mean time to recover
-* Team happiness
+- Deployment frequency
+- Lead time for changes
+- Incident rate
+- Mean time to recover
+- Team happiness
 
 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:
 
-* Features
-* Bug fixing
-* Operability
-* Tech debt
-* Other improvement work
+- Features
+- Bug fixing
+- Operability
+- Tech debt
+- Other improvement work
 
 ## What does this mean for me as a less-technical person?
 
 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.
 
 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:
 
-* Can you observe handoffs between "teams-within-a-team"? How could you help reduce or avoid them?
-* Do you have no understanding of what a part of the team is working on? How could that be made more visible?
-* 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?
+- Can you observe handoffs between "teams-within-a-team"? How could you help reduce or avoid them?
+- Do you have no understanding of what a part of the team is working on? How could that be made more visible?
+- 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?
 
 ## What does this mean for me as a technical person?
 
 If you are an Engineer or Tester, continuous improvement will help you:
 
-* Reduce waste and spend more time delivering value for users.
-* Implement features and fix bugs more quickly and safely.
-* Spend less time on menial or repetitive work.
+- Reduce waste and spend more time delivering value for users.
+- Implement features and fix bugs more quickly and safely.
+- Spend less time on menial or repetitive work.
 
 You have an important role to play!
 
-* Make sure you understand the user needs well enough to have an informed conversation about the relative priority of the functional work items.
-* 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.
-* Play an active role in backlog refinement and planning, ensuring that operability and reliability work is adequately represented.
-* Be bold and make sure technical quality is maintained.
-  * But also, be pragmatic and accept that all systems have imperfections and some degree of tech debt.
+- Make sure you understand the user needs well enough to have an informed conversation about the relative priority of the functional work items.
+- 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.
+- Play an active role in backlog refinement and planning, ensuring that operability and reliability work is adequately represented.
+- Be bold and make sure technical quality is maintained.
+  - But also, be pragmatic and accept that all systems have imperfections and some degree of tech debt.
 
 ## Closing remarks
 

inclusive-language.md

@@ -1,9 +1,16 @@
 # Inclusive language
 
+- [Inclusive language](#inclusive-language)
+  - [Context](#context)
+  - [Background](#background)
+  - [Details](#details)
+  - [Renaming the master branch in GitHub](#renaming-the-master-branch-in-github)
+  - [Further reading](#further-reading)
+
 ## Context
 
-* This is part of a broader [quality framework](README.md)
-* 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-)
+- This is part of a broader [quality framework](README.md)
+- 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-)
 
 ## Background
 
@@ -38,8 +45,8 @@ git remote set-head origin -a
 
 ## Further reading
 
-* [inclusivenaming.org](https://inclusivenaming.org/word-lists/)
-* [Internet Engineering Task Force](https://datatracker.ietf.org/doc/draft-knodel-terminology/)
-* [Python](https://bugs.python.org/issue34605)
-* [GitHub](https://github.com/github/renaming)
-* [NCSC](https://www.ncsc.gov.uk/blog-post/terminology-its-not-black-and-white)
+- [inclusivenaming.org](https://inclusivenaming.org/word-lists/)
+- [Internet Engineering Task Force](https://datatracker.ietf.org/doc/draft-knodel-terminology/)
+- [Python](https://bugs.python.org/issue34605)
+- [GitHub](https://github.com/github/renaming)
+- [NCSC](https://www.ncsc.gov.uk/blog-post/terminology-its-not-black-and-white)

patterns/architect-for-flow.md

@@ -1,10 +1,18 @@
 # Architect for flow
 
+- [Architect for flow](#architect-for-flow)
+  - [Context](#context)
+  - [The pattern](#the-pattern)
+  - [Benefits](#benefits)
+  - [Caveats](#caveats)
+  - [Details](#details)
+  - [Examples](#examples)
+
 ## Context
 
-* These notes are part of a broader set of [principles](../principles.md)
-* This pattern is closely related to the [deliver little and often](little-and-often.md) pattern
-* See also: [structured code](../practices/structured-code.md)
+- These notes are part of a broader set of [principles](../principles.md)
+- This pattern is closely related to the [deliver little and often](little-and-often.md) pattern
+- See also: [structured code](../practices/structured-code.md)
 
 ## The pattern
 
@@ -16,39 +24,39 @@ One key consideration is how best to break the system down into independent serv
 
 In high level terms, systems which are designed to maximise rapid, reliable delivery and operations:
 
-* Are cost efficient: teams don't waste their time fighting the tools or working with difficult architectures
-* Improve business agility: these systems allow teams to respond more quickly to changes
-* Improve reliability: these systems are easier to understand, which leads to fewer failures and shorter recovery times
-* Improve team happiness: engineers are happy when the tools they work with let them get on with what they do best
+- Are cost efficient: teams don't waste their time fighting the tools or working with difficult architectures
+- Improve business agility: these systems allow teams to respond more quickly to changes
+- Improve reliability: these systems are easier to understand, which leads to fewer failures and shorter recovery times
+- Improve team happiness: engineers are happy when the tools they work with let them get on with what they do best
 
 In many cases, building a system as a set of independently running services/components has benefits:
 
-* Multiple components enable parallel development work by multiple teams
-* Teams can work at their own cadence
-* Changes with each component are easier to reason about and test
-* 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
-* 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
-* It is possible to isolate the impact of catastrophic failure of any individual component
-* Self-contained components with clear boundaries of responsibility reduce hand-offs between teams
-* Components with clear boundaries of responsibility are more easily replaced
-* 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
+- Multiple components enable parallel development work by multiple teams
+- Teams can work at their own cadence
+- Changes with each component are easier to reason about and test
+- 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
+- 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
+- It is possible to isolate the impact of catastrophic failure of any individual component
+- Self-contained components with clear boundaries of responsibility reduce hand-offs between teams
+- Components with clear boundaries of responsibility are more easily replaced
+- 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
 
 ## Caveats
 
-* This pattern must not compromise quality: automation (including of quality control) is essential for safe implementation of this pattern
-* 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:
-  * There are more failure modes to test, since calls which go over the network can fail in more ways than simple method invocations
-  * Versioning becomes a more complicated concern, and additional effort is required to ensure component APIs are compatible as each changes independently
-  * Clean domain boundaries are essential for safe implementation of this pattern
-  * Comprehensive monitoring and alerting is essential for safe implementation of this pattern
-* 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
+- This pattern must not compromise quality: automation (including of quality control) is essential for safe implementation of this pattern
+- 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:
+  - There are more failure modes to test, since calls which go over the network can fail in more ways than simple method invocations
+  - Versioning becomes a more complicated concern, and additional effort is required to ensure component APIs are compatible as each changes independently
+  - Clean domain boundaries are essential for safe implementation of this pattern
+  - Comprehensive monitoring and alerting is essential for safe implementation of this pattern
+- 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
 
 ## Details
 
-* 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
-* For components to be genuinely independent they need to only interact via their public APIs (e.g. not via a shared database)
-* 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)
-* 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)
+- 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
+- For components to be genuinely independent they need to only interact via their public APIs (e.g. not via a shared database)
+- 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)
+- 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)
 
 TO DO: reference to the NHS UI toolkit (for presentation fragments)