Amplify Feedback Loops - The DevOps Second Way

It's been a while, but this article leads on from my previous post - The Andon Cord and DevOps - The First Way. The values included Never passing a known defect to downstream work centers and always seeking to increase flow.

The second way is all about building in and amplifying feedback loops. This should include both internal and external customers. We want loud and clear feedback as quickly as possible from anyone that could give a perspective on the quality of the product.

These feedback loops need to be kept as short as possible, since it's not going to be quick and easy to test and give feedback on a product increment that's taken 9 months to build.

Automated Feedback could come from automated build systems, automated UI tests, continuous code quality tools such as SonarQube (including code coverage, code smells or critical code issues), and even SAST and DAST tools to inspect the code itself (either statically, or dynamically at runtime) and flag potential security risks.

Quality Assurance Engineers may be running manual test suites, automated regression tests, performance tests and various other non-functional tests that all ensure that quality criteria is being adhered to and the definition of done is being met.

Product Owners will have a view on how their requirements that are fed into the team are being met. Ultimately they will adjust how they communicate software requirements to the team based on previous mis-understandings or assumptions. Again, this all helps speed up the delivery of the end product in the long run. This feedback is also important from a team morale perspective, since the product owner able to communicate how the product has been received by stakeholders (and potentially users too).

Operations can exist either as a function of the product team itself or as an outside entity. Communication about how the product is performing (both in a product environment and lower environments) is critical, and the faster the team developing the product gets this feedback the easier it is to react to any issues. Is the product difficult to monitor? Are logs being written to the correct location? Is there a performance degradation since the last release?

Feedback can also be gathered not just on the product itself, but on the development process. This is addressed sometimes by a scrum retrospective, but feedback can be gathered outside of this ceremony. Where were there problems with test data? Which pieces of functionality took an unexpectedly long time to complete? Where did we have problems understanding requirements? By using this state of constant self-analysis, we can improve not just on the product but also how the product development lifecycle takes place.

By shortening and amplifying these feedback loops, we're allowing developers to continue with the task at hand without context switching. This means they're kept more productive, that customer value is kept the focus and that everyone is on the same page in terms of the requirements at hand and how.