Skip to content

Commit 9d68cf5

Browse files
iw-ezequieliw-ezequielandyblundellregularfry
authored
Rationalise section 1 of the principles. (#158)
Consolidation of some, and deletion of what could be duplication --------- Co-authored-by: iw-ezequiel <ezequiel.gomez@infinityworks.com> Co-authored-by: andyblundell <andrew.blundell@nhs.net> Co-authored-by: Alex Young <alex@blackkettle.org> Co-authored-by: Alex Young <alex.young12@nhs.net>
1 parent d9b9621 commit 9d68cf5

File tree

1 file changed

+10
-24
lines changed

1 file changed

+10
-24
lines changed

principles.md

Lines changed: 10 additions & 24 deletions
Original file line numberDiff line numberDiff line change
@@ -16,39 +16,25 @@ Our principles guide the way we work and interact with each other. They are base
1616

1717
### 1. Eliminate waste
1818

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.
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:
2020

21-
**Inventory &mdash; partially done work**, e.g. plans and designs, code. Limit work in progress (WIP) and use a pull-based approach.
21+
- **Inventory &mdash; partially done work**, e.g. plans and designs, code shelved halfway. Limit work in progress (WIP) and use a pull-based approach.
2222

23-
**[Inventory &mdash; unnecessary resources](practices/cloud-services.md)** [ARCHITECTURE-SUSTAINABILITY](https://digital.nhs.uk/about-nhs-digital/our-work/nhs-digital-architecture/principles/deliver-sustainable-services), e.g. server over-provisioning, complicated tools where simple ones would do. Adopt a "just enough, not just in case" mindset.
23+
- **Inventory &mdash; [unnecessary resources](practices/cloud-services.md)** [[ARCHITECTURE-SUSTAINABILITY]](https://digital.nhs.uk/about-nhs-digital/our-work/nhs-digital-architecture/principles/deliver-sustainable-services), e.g. server over-provisioning, complicated tools where simple ones would do. Adopt a "just enough, not just in case" mindset.
2424

25-
**Overproduction &mdash; building unnecessary features.** Start simple and basic, get feedback and iterate.
25+
- **Overproduction &mdash; planning or designing in excessive detail.** Requirements change, therefore use a "just enough, just in time" approach to both. Detail should be added as you move to the right in the [cone of uncertainty](http://www.agilenutshell.com/cone_of_uncertainty).
2626

27-
**Overproduction &mdash; planning or designing in excessive detail.** Use a "just enough, just in time" approach to both.
27+
- **Overproduction &mdash; overengineering**, i.e. building unnecessary features, unwarranted levels of code perfection or quantities of tests, or premature optimisation. Start simple and prefer explicit logic to implicit. Be pragmatic and balance effort now with saved effort or risk in the future. Remember [KISS](http://principles-wiki.net/principles:keep_it_simple_stupid) and [YAGNI](https://www.martinfowler.com/bliki/Yagni.html) and see the caveats in [structured code](practices/structured-code.md).
2828

29-
**Overproduction &mdash; overengineering**, i.e. building unwarranted levels of code perfection or quantities of tests. Be pragmatic and balance effort now with saved effort or risk in the future. Remember [KISS](http://principles-wiki.net/principles:keep_it_simple_stupid) and [YAGNI](https://www.martinfowler.com/bliki/Yagni.html) and see the caveats in [structured code](practices/structured-code.md).
29+
- **Overproduction &mdash; reinventing the wheel.** Solving the same problem repeatedly in an organisation, or building when you could reuse or buy [[ARCHITECTURE-REUSE]](https://digital.nhs.uk/about-nhs-digital/our-work/nhs-digital-architecture/principles/reuse-before-buy-build). Make sure there are effective ways to share knowledge between teams to avoid this.
3030

31-
**Overproduction &mdash; reinventing the wheel.** Solving the same problem repeatedly in an organisation. Make sure there are effective ways to share knowledge between teams to avoid this.
31+
- **Extra Processing &mdash; due to delayed integration** making merging / reconciliation and testing harder. Use [continuous integration](practices/continuous-integration.md) with frequent merges. When combined with Test-Driven Development, this will allow bugs to be detected early when they are cheap to fix.
3232

33-
**[Overproduction &mdash; building when you could instead reuse or buy](practices/cloud-services.md).** [ARCHITECTURE-REUSE](https://digital.nhs.uk/about-nhs-digital/our-work/nhs-digital-architecture/principles/reuse-before-buy-build) Remember to consider all these alternatives.
33+
- **Hand-offs** (“Transportation” and “Waiting” in Lean terminology) &mdash; excessive passing of work between individuals or teams. Develop multi-skilled individuals and cross-functional product teams. Apply the [Shift Left](https://www.testim.io/blog/shift-left-testing-guide/) principle to testing and other areas of your SDLC.
3434

35-
**Overproduction &mdash; premature optimisation for reusability.** Before making something reusable, first make it usable. Prefer explicit logic to implicit. Excessively generic systems create accidental complexity. [KISS](http://principles-wiki.net/principles:keep_it_simple_stupid) and [YAGNI](https://www.martinfowler.com/bliki/Yagni.html) and the caveats in [structured code](practices/structured-code.md) again.
35+
- **Context switching &mdash; due to too much work in progress (WIP) or poorly segregated work.** Limit WIP explicitly. Focus on optimising lead time. For project vs. support work, implement time-slicing or rota systems to allow focus and prevent reactiveness.
3636

37-
**Overproduction &mdash; premature optimisation**, e.g. for performance or scale. Design with both in mind, but not excessively so. Defer optimisation until testing shows it is necessary. Start simple, test, iterate.
38-
39-
**Extra Processing &mdash; due to changing requirements.** Use just enough, just in time approach to understanding requirements and deliver small iterations in a build-measure-learn loop.
40-
41-
**Extra Processing &mdash; due to delayed integration** making merging / reconciliation harder. Use [continuous integration](practices/continuous-integration.md) with frequent merges.
42-
43-
**Extra Processing &mdash; due to late testing.** When testing is done after implementation, especially if long after, bugs become more time consuming to detect and fix. Use test driven development and [continuous integration](practices/continuous-integration.md).
44-
45-
**Hand-offs** (“Transportation” and “Waiting” in Lean terminology) &mdash; excessive passing of work between individuals or teams. Develop multi-skilled individuals and cross-functional product teams.
46-
47-
**Context switching &mdash; due to too much work in progress (WIP).** Limit WIP explicitly. Focus on optimising lead time.
48-
49-
**Context switching &mdash; due to poorly segregated work** (e.g. project vs support). Identify different classes of work and create separation with time-slice or rota systems to avoid reactive work from destroying productivity.
50-
51-
**Defects** due to not understanding requirements properly or bugs leaking through. Use approaches described in the next section.
37+
- **Defects** due to not understanding requirements properly or bugs leaking through. Use approaches described in the next section.
5238

5339
### 2. Build quality in
5440

0 commit comments

Comments
 (0)