Sooner Safer Happier: Antipatterns and Patterns for Business Agility
Rate it:
Open Preview
43%
Flag icon
5: Information Bubbles
43%
Flag icon
ANTIPATTERN 6.3 Fixed Mindset to Risk
43%
Flag icon
1: Conflicts Grow between Risk and Compliance
43%
Flag icon
2: One Size Really Doesn’t Fit All
43%
Flag icon
3: Big, Up-Front Risk Planning
44%
Flag icon
PATTERN 6.1 Safety within Safety
44%
Flag icon
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.
44%
Flag icon
PATTERN 6.2 Organize Safety by Value Stream
44%
Flag icon
1: The Cross-Functional, Long-Lived Safety Team
44%
Flag icon
44%
Flag icon
2: Safety Teams Are Aligned to Value Streams
44%
Flag icon
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.
44%
Flag icon
45%
Flag icon
3: Safety Authorities
45%
Flag icon
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).
45%
Flag icon
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]).
45%
Flag icon
45%
Flag icon
4: The Risk Catalog
45%
Flag icon
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.
45%
Flag icon
PATTERN 6.3 Intelligent Control
45%
Flag icon
1: Continuous Engagement
45%
Flag icon
45%
Flag icon
2: Set the Safety Engagement Level
46%
Flag icon
3: Risk Stories and Continuous Testing
46%
Flag icon
Control requirements are not fixed: Control Requirement = Control Objective + Context
46%
Flag icon
46%
Flag icon
4: Risk Awareness
46%
Flag icon
5: Evolutionary Artifacts
46%
Flag icon
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
46%
Flag icon
6: Candidate Release Validation
46%
Flag icon
46%
Flag icon
Virtual Andon Cord
46%
Flag icon
7: Active Leadership Support
46%
Flag icon
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
46%
Flag icon
8: Risk Metrics
47%
Flag icon
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?
47%
Flag icon
9: Tooling
47%
Flag icon
47%
Flag icon
ANTIPATTERN 7.1 Going Faster Leads to Going Slower
48%
Flag icon
The decisions should be intentional and made together by the Value Outcome Lead, Team Outcome Lead, and Architecture Outcome Lead.
48%
Flag icon
48%
Flag icon
ANTIPATTERN 7.2 Agile Hollow Shell
49%
Flag icon
ANTIPATTERN 7.3 Misalignment of Teams and Architecture
49%
Flag icon
ANTIPATTERN 7.4 Tools over People
49%
Flag icon
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.
50%
Flag icon
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
50%
Flag icon
PATTERN 7.1 Go Slower to Go Faster
50%
Flag icon
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
51%
Flag icon
PATTERN 7.2 Continuous Technical Excellence
52%
Flag icon
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