Invest in quality: Difference between revisions
No edit summary |
No edit summary |
||
Line 36: | Line 36: | ||
*[[Technical leaders as coaches, mentors and community leaders]] | *[[Technical leaders as coaches, mentors and community leaders]] | ||
*[[Shared context improves decisions]] | *[[Shared context improves decisions]] | ||
*[[Favour Teams with broader Business Domain | *[[Favour Teams with broader Business Domain Competence]] | ||
*[[Maximise Team autonomy]] - ''Contending'' | *[[Maximise Team autonomy]] - ''Contending'' | ||
*[[Favour Teams with broader Solution Accountability]] | *[[Favour Teams with broader Solution Accountability]] | ||
*[[Limit Team Mental Workload]] - ''Contending:'' | *[[Limit Team Mental Workload]] - ''Contending:'' | ||
*[[Maximise team empowerment and localised decision making]] - ''Contending:'' | *[[Maximise team empowerment and localised decision making]] - ''Contending:'' |
Latest revision as of 22:16, 21 May 2024
Description
At scale, it is even more essential that we continuously invest time and effort in the quality of the emerging integrated product so that the team of teams can maintain a sustainable pace.
Quality is a complex concept that can include many dimensions, most of which are "Internal" in that customers should be unaware of them, at least until there is an issue at which point they become "External":
- Extensibility - the product's openness to extension and ease with which new or modified capabilities can be added.
- Simplicity - how far the product is from the minimum essential level of complexity required to satisfy required capabilities.
- Maintainability - the ease with which the system can be maintained in an optimum running state.
- Operability - the ease with which the dynamic state of the product can be understood and managed.
- Debug - the ease with which unexpected and undesired product behaviours can be investigated and root causes discovered.
- Testability - the ease with which functional and non-functional product capabilities can be validated.
- Functionality - how well the developed features support the intended outcomes of the product.
- Deployability - the ability to build and deploy the emerging product to any given target environment.
- Reality simulation - how closely target environments simulate the intended or actual production environment.
- Understandability - the cognitive load experienced when learning and comprehending the product.
- Performance and load characteristics - how the emerging product conforms to the intended performance and loading requirements.
- Security - how well the product conforms to the required levels of security.
- Resilience - how the product behaves in failure scenarios and the ease with which it can be recovered to an operational state.
- Standards conformance - how the product conforms to applicable standards, including those for how it is crafted and operated.
Rationale
One of the twelve Agile Manifesto principles states: "Continuous attention to technical excellence and good design enhances agility".
We know from painful experience that an Agile team that trades shortcuts on quality for additional speed cannot sustain the apparent increase in output. They soon suffer additional friction adding new capabilities and spend greater proportions of their time remediating issues. Over the longer term, the team delivers less capability with poorer quality than if they had continuously attended to the quality of the product.
As we scale, the quality problems created by one team impact not only the originating team but also their fellow scaled teams. In addition, due to the challenges of scaling and the additional complexity of the product, there are pressures to compromise many of the dimensions of quality. This leads to delayed feedback, greater rework and longer and less predictable timescales for delivery.
Related Principles
- Minimise unnecessary complexity
- Maximise the Scope of Product Increment
- Regular small changes: Scale the number of changes rather than the size
- Amplify Speed and Quality of Learning Cycles
- Collective responsibility for complete product development
- Support autonomy with clear boundaries
- Product solution design is driven from within development teams
- Technical leaders as coaches, mentors and community leaders
- Shared context improves decisions
- Favour Teams with broader Business Domain Competence
- Maximise Team autonomy - Contending
- Favour Teams with broader Solution Accountability
- Limit Team Mental Workload - Contending:
- Maximise team empowerment and localised decision making - Contending: