DevOps Foundation study materials
DevOps Foundation study resources

DevOps Foundation: Sharing, Feedback and Continuous Improvement

DevOps Foundation · Work through your exam, one topic at a time.

All guide sections

Sharing, Feedback and Continuous Improvement

The third way

Sharing, feedback and continuous improvement are the learning half of DevOps. The second way amplifies feedback from right to left - from production, customers and monitoring back to development - so problems are found and fixed quickly. The third way builds a culture of continual experimentation, where taking risks and learning from failure is expected, and where knowledge is deliberately pushed into the organisation.

Concepts a candidate must know

  • Feedback loops: automated test results, monitoring and alerting, user telemetry, incident reviews, customer feedback, and short release cycles that make feedback cheap.
  • Blameless postmortems and incident reviews that produce actionable, owned improvements rather than a search for a culprit.
  • Retrospectives with tracked action items; improvement is only real when it changes how work is done.
  • Sharing mechanisms: internal communities of practice, guilds, internal conferences, dojos and kata, pairing and mobbing, shared documentation, chat-ops transparency, open dashboards, and rotation between teams.
  • Knowledge as a public asset: documentation, runbooks and design records in version control, discoverable by anyone.
  • Continuous improvement frameworks: PDCA (plan-do-check-act), kaizen, and experimentation with hypotheses and measured outcomes.
  • Error budgets and SLOs as a structured way to decide when to invest in reliability versus new features.

Traps in questions

  • "The retrospective was held and everyone agreed it went well" with no actions or owners - a classic non-answer.
  • Feedback only at the end of a project, or only from managers, rather than continuously from users and systems.
  • Rewarding individual knowledge hoarding as "being indispensable"; sharing is the desired behaviour.
  • Treating failure as something to hide, which suppresses the information feedback depends on.
  • Assuming a tool (wiki, chat channel) creates sharing culture by itself.

Rule of thumb

Every improvement cycle should leave behind two artefacts: an owned action with a date, and something learned that others can find. If neither exists, the loop did not close.