More on this book
Community
Kindle Notes & Highlights
Read between
December 13 - December 22, 2020
5: Information Bubbles
ANTIPATTERN 6.3 Fixed Mindset to Risk
1: Conflicts Grow between Risk and Compliance
2: One Size Really Doesn’t Fit All
3: Big, Up-Front Risk Planning
PATTERN 6.1 Safety within Safety
Edmonson, a leader in the study of psychological safety, has described psychological safety’s four dimensions as:33 1.Attitude to risk and failure: the degree to which it is permissible to make mistakes. 2.Open conversation: the degree to which sensitive and difficult topics can be discussed openly. 3.Willingness to help: the degree to which people are willing to help each other. 4.Inclusivity and diversity: the degree to which you can be yourself and welcomed.
PATTERN 6.2 Organize Safety by Value Stream
1: The Cross-Functional, Long-Lived Safety Team
2: Safety Teams Are Aligned to Value Streams
Individual Safety SMEs in each Safety team represent their Safety domain to the value stream. If there are gaps in personal knowledge, the Safety SMEs can call in help from their colleagues elsewhere, learning and broadening their own knowledge in the process and across the Safety community and increasing the resilience of the organization by reducing key person SME dependencies.
3: Safety Authorities
When functional, role-based silos pivot into Safety teams, Safety authorities are the communities of Safety SMEs who share a common discipline and are the accountable advisory experts within the organization (hence authority).
the Safety authority continues to be responsible for clearly articulating control objectives within the organization’s policies and standards, as well as articulating risk appetite suited to context. Prescriptive, one-size-fits-all, lowest common denominator approaches should be avoided, allowing the value stream aligned Safety team to “right-size” the controls suited to context (minimal viable compliance [MVC]).
4: The Risk Catalog
Safety SMEs in a Safety authority collaborate with the Ways of Working team to translate risk statements from policies and standards into risk story templates that explain the risks, the control objectives, the acceptance criteria, and the common risk mitigations. Risk story templates communicate the control objectives and controls of the organization to the product team.
PATTERN 6.3 Intelligent Control
1: Continuous Engagement
2: Set the Safety Engagement Level
3: Risk Stories and Continuous Testing
Control requirements are not fixed: Control Requirement = Control Objective + Context
4: Risk Awareness
5: Evolutionary Artifacts
Artifacts will naturally improve and evolve over time and do not require duplication for every outcome or OKR. Relevant artifacts typically include: •product vision •architecture vision •architecture wiki •product roadmap •threat model •lean test strategy •operations run book
6: Candidate Release Validation
Virtual Andon Cord
7: Active Leadership Support
Value stream leadership has a key role to play in maximizing the value from this pattern, including: •Taking responsibility for risk and actively promoting the risk agenda across teams •Partnering with Safety authority leadership to ensure Safety teams have capacity, including potentially co-funding, if that is the best way to deliver Better Value Sooner Safer Happier (remember: impediments are not in the path, impediments ARE the path) •Partnering with the Safety team as part of the value stream extended leadership to focus on the presence of positives: to keep the discussion on risk alive
8: Risk Metrics
Examples of key risk indicators in the delivery process include: •Total products in the value stream with inflight business outcomes. Are there any persistently not engaging with Safety teams? Why is this? •Products in the value stream that are any persistently flagging low health with Safety teams? Why is this? •Products in the value stream with risk stories persistently left unresolved for an extended period? Why is this? •Products in the value stream with implemented change requests (CRs) in a period—how many CRs were uncorrelated to a validated release certificate? Why is this?
9: Tooling
ANTIPATTERN 7.1 Going Faster Leads to Going Slower
The decisions should be intentional and made together by the Value Outcome Lead, Team Outcome Lead, and Architecture Outcome Lead.
ANTIPATTERN 7.2 Agile Hollow Shell
ANTIPATTERN 7.3 Misalignment of Teams and Architecture
ANTIPATTERN 7.4 Tools over People
enterprises often focus on the tools that support automated build and deployment, often mislabeled as “CI/CD,” when most teams using it are practicing neither continuous integration nor continuous delivery, and certainly not continuous deployment.
Michael Bolton and James Bach, proponents of the Context-Driven school of testing, warn against the dangers of this approach. They distinguish testing, which they describe as an essentially human activity like programming, from checking, the potentially repetitive task of setting up, acting, and asserting behavior that is often performed by manual testers and that can be automated in software.13
PATTERN 7.1 Go Slower to Go Faster
There are at least four types of work: (1) new features, (2) failure demand (fixing defects), (3) risk stories (as per Chapter 5), and, most importantly to this chapter, (4) improvement stories. Mik Kersten uses the words Features, Defects, Risks, and Debts to refer to these four types of work in his Flow Framework.16
PATTERN 7.2 Continuous Technical Excellence
In order to have agility with a solid technical core, a small, shared Software Engineering Center of Excellence (CoE) (aka Guild or Practice) and a voluntary, open-to-all Community of Practice (CoP) work well, per Pattern 4.1. The CoE is not a Center of Employment—quite the opposite. It is a small team that is there to support the engineering specialists in the organization who are aligned to value streams, own the software engineering principles for the firm, advise on practices, determine the minimum viable guardrails, catch bubbled up impediments, remove those impediments from the teams,
...more