The Second Way of DevOps: Feedback

In the previous article, we talked about Flow as mentioned in the book The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win. We’ll be continuing by talking about the second way, Feedback. Feedback is important in our lives and in our relationships as human beings. Let’s explore how it is helpful in improving our software systems.

Complex Systems Are Scary

In complex software applications that don’t leverage Agile and SOLID practices, we usually see tightly coupled components. This makes it quite difficult to isolate the components for modification or testing, which can result in unpredictable behavior when problems occur. Then there are the situations where doing the same thing twice may not necessarily lead to the same result... the low coupling, high cohesion types of situations.

You may be thinking “What’s wrong with non-isolated components?” Consider the Three Mile Island accident, or the Northeast Blackout of 2003. Tightly-coupled components are hard to test, diagnose and repair.

Increasing Safety Within Complex Systems

The book The High-Velocity Edge: How Market Leaders Leverage Operational Excellence to Beat the Competition makes some good points regarding the idea of “increasing the safety” within a complex system. No one is perfect, and in the sense that software is created by humans, that means that our software isn’t perfect either. However, we can increase the “safety” of our software. The book outlines that “safe systems are close to achievable” when the following conditions are met:

• Seeing problems as they occur
• Swarming and solving problems as they are seen to build new knowledge
• Spreading new knowledge throughout the organization

Seeing Problems As They Occur

One of the things we can do to increase the ability to see problems as they occur within complex systems is to test design and operations assumptions. Invalidating incorrect assumptions will lead you down a path of correcting problems quicker, increasing your organization’s agility and the ability to internally learn & innovate. Your goal should be fast feedback and fast forward loops at all stages of your value stream.

Swarm & Solve Problems To Build Knowledge

Containing problems as they occur helps you to then diagnose & treat the problems so that they should not reoccur. Swarming – getting a team together to tackle the problem – enables learning. By swarming, the knowledge gained can be shared more efficiently. This prevents the loss of critical knowledge within the organization.

Spreading New Knowledge Throughout Your Organization

We all gain some level of knowledge when we create, we interact, and we problem solve. Why is it then that we tend to horde that knowledge within our organizations? Sharing of the knowledge we learn through avenues such as pair programming, lunch ‘n learns, and knowledge bases help us to not build silos, but instead build up the collective knowledge of the organization. This helps other teams within the organization... when they have to tackle a similar problem, they have prior knowledge that they can leverage to help them solve their current problem.

The Plan-Do-Check-Act Cycle

First proposed by Walter Shewhart and later popularized by William Deming, the PDCA cycle became a widespread iterative framework for continual improvements of products, people, and services. It has also become an essential part of the lean management philosophy. An effective use of PDCA is creating a continuous quality improvement process within your organization. The “Check” part of PDCA is where we gather and/or leverage feedback within the system to influence the “Act” part of the cycle.

Pushing Quality Closer To The Source

What else can we do with the feedback we produce in our processes? We can use things such as peer reviews to increase the quality of our code, our design or our implementation. Doing things such as automating quality checks and testing as much as possible increases the trust & safety of the system you are working in. The automation collects feedback for us and allows us to concentrate on the “hard” problems instead of the mundane & repetitive. When quality becomes the responsibility of all members of the value stream, that pushes it closer to the source. Lastly, when the developers share responsibility for the quality of the systems that they build, they not only improve outcomes, but also accelerate learning as a collective mind instead of individual silos.

Using Feedback to Optimize for Work Centers Downstream

Feedback isn’t just about us communicating more within our processes within the value stream. We also should have feedback from the systems we interact with. This feedback then helps us to make better decisions on how to resolve problems, or how to make business decisions that affect our system within the organization. For example, take the idea of Designing for Operations. In an approach such as this, we design in application & platform monitoring and alerting strategies that give us insight into how the system is performing (or not in the event of a failure). This also requires that we prioritize non-functional requirements, such as stability, testability, configurability, security and scalability as highly as features.