Feedback & Transparency
The precondition for successful agile delivery is transparency. It makes process data and technical variation visible – and fuels continuous improvement.
Feedback – automated or face-to-face – is needed to distinguish good from bad decisions. It is the basis for learning about the technical and functional environment.
Core Ideas
Favor direct feedback in short cycles
Getting feedback to experiments or solution ideas should be motivating and casual – easy. Instead of governance approaches or board-meetings we favour participative approaches of communication. Having community events or meetups helps to spread ideas, but also to sharpen ideas and carve out what works for many. Blogs invite people to comment and low-key peer-to-peer evaluation workshops can also help.
Make your process and solution visible
Progress, status information and solution health have to be visible. Keeping everybody informed is the first step towards a healthy feedback and improvement culture. This includes classic information radiators, like kanban boards, burndown charts or build status screens. Other important ideas include having a physical big picture of the architecture, an architecture wall or principles on posters
Establish validated learning
Looking beyond the soft feedback of communication mechanisms, we aim for focused (possibly quantifiable) feedback for product qualities. The term fitness function stems from evolutionary computing and tries to subsume all kinds of quality attribute feedback. Exploratory tests on usability as well as metrics for maintainability, monitoring features for reliability, load tests for scalability and so on. Chaos Engineering and continuously testing actual qualities of the whole system was the big hype, the topic of fitness functions is bigger than that.
Sector Rating Aspects
These are aspects that can be used to assess your performance and maturity in this sector. For a detailed explanation please have a look at our how to page.
| Aspect | Adoption Lifecycle |
|---|---|
| Information Radiators are extensively used (process and solution oriented) | Late majority |
| Diversity is important and supports an open communication culture | Late majority |
| Continuous Delivery practices like Deployment Pipelines give direct technical feedback to developers | Early majority |
| Quality related tests are automated and performed regularly (Performance-, Load- and Stress-Tests) | Early majority |
| Communities of Practice are used to present new ideas or deviations from the default technology choices (guilds, brown-bag sessions, meetups, …) | Early majority |
| Assess products / services used and employed by their fitness, usefulness, modernity, … (e.g. tech radar, Boston Growth Matrix | Early majority |
| Techniques to increase actively taking responsibility are used (e.g. Circle of Influence and Control) | Early adopters |
| Liberating Structures are used to collaborate and share knowledge (e.g. TRIZ, 25/10, CrowdSourcing, MinSpecs) | Early adopters |
| Acceptance Test Driven Development (ATDD) / Behavior (Business) Driven Development / Specification by Example practices are common | Early adopters |
| Fitness Functions are established for important quality attributes (Chaos Engineering, Security-Tests, …) | Innovators |
Connections
- Empirical Process Control: Establish regular and detailed feedback and transparency.
- Responsibility: Enhance awareness of and identification with test results and feedback through a sense of responsibility.
- Technical Excellence: Improve the creation and delivery of software in order to better automate and regression test your processes and results.
