How to Create DevOps Feedback Loops

When discussing DevOps, you’ll constantly hear “create,” “amplify,” “multiply,” and many other “-ly” words about feedback loops. But what exactly is a feedback loop? Let’s start with a few definitions:

Per dictionary.com, feedback is “the path by which some of the output of a circuit, system, or device is returned to the input.” Short and to the point.

Wikipedia, which we know to the be the absolute authority on all things, has a lengthier definition: “feedback occurs when outputs of a system are routed back as inputs as part of a chain of cause-and-effect that forms a circuit or loop.”

Of the two definitions, I think Wikipedia’s more closely aligns with what we want to accomplish with DevOps – namely, we want some cause and effect to occur that then creates a circuit between Dev and Ops. Essentially, what happens during operations should go back and affect how you carry out the development.

Back to the main point of both definitions – feedback involves getting part of the output back to the input. In our case it’s getting information from Ops, i.e., how things are running (output), to Dev, i.e.., the people that created it (input).

But even better than understanding the concept of feedback loops is knowing how to create them. First let’s go over the three most common traps people fall into when creating feedback loops, then we’ll address how to sidestep them and cover tips for creating feedback loops the right way.

3 Traps to Avoid When Creating Feedback Loops

One Meeting to Rule Them All

At its core, DevOps is about organizational change, and you can’t change organization’s culture through one hour-long meeting per week. What in your life have you ever truly improved by dedicating just one hour a week?  Now think of how often we try to change things at work with a weekly one-hour meeting. (I’m not responsible for any alcohol consumption this self-reflection may have caused.)

Failure to Train Teams on How to Provide Feedback

How many of you have ever been trained on soft skills around providing constructive, meaningful feedback? This is maybe one of the most common and devastating traps. We take a group of people that aren’t exactly known for their innate social skills, put them in a room together, and just assume it’ll work out. There’s a reason silos exist: they’re easier. They consist of like-minded individuals, similar projects, common challenges, and shared vocabulary – none of which require much of a stretch. We have to teach our teams the skills to give more meaningful feedback so it’s easier for them to interact with people outside their bubbles.

Lack of Action from Feedback 

The point of the feedback loop is to lead teams to action. If no action is taken, it’s not a feedback loop at all  – it’s a megaphone.

By no means is this an exhaustive list of traps, but it at least identifies the most common and impactful ones I’ve seen. Now let’s cover the tips for creating feedback loops.

4 Tips for Creating Feedback Loops

It’s a System, Not a Single Loop

As I mentioned in the first trap, many organizations try to foster organizational change by simply adding another weekly meeting to the schedule. While there is value in having a regularly scheduled meeting with the various stakeholders from Dev and Ops, this shouldn’t be the only component of the overall feedback loop system. Here’s what you should include as you get started:

• Meetings:
  • Weekly touchpoint: Schedule and manage agenda for half hour, should focus primarily on updates and any items not addressed through another component.
  • Sprint Retro: Have individuals from different teams participate in the other team’s retro, to see what they are learning and what they are missing, etc.
• Change Management
  • Review: Was Ops included in the review? If that’s only done at Approval, it’s too late.
  • Deployments: As part of every deployment, it should be asked – what can we do to make this a standard (i.e., drive the risk down to acceptable level), then can we automate it?
  • Early Life Support (ESL): Have joint teams work together on go-live support and, if possible, have them co-locate in the same conference room, or in a portion of the Service Desk
  • Post Implementation Review (PIR): For failed and successful changes. Many orgs only do this for failed, but there’s a lot of value to be gained from asking “why did this one succeed?”, or, even better, “how do we make it better?”  For example, we successfully deployed the new version during the maintenance window last night – great, how do we get to a place where we can deploy during office hours without disrupting the business?
• Shadowing:
  • @ Ops: Have Developers and Infrastructure spend time shadowing members of the Service Desk – -see how they work, what improvements could be made, and what tools could be created and provided to them. This can be done in conjunction with ESL.
  • @ Developers: Have Service Desk and Infrastructure sit in on a few daily scrums of the Development teams. Let them see what they experience and are asked to complete. It doesn’t really make sense to have them sit there and watch the dev team code, but it’s good for them to see developers work on the type of things they get asked about and how much of a demand those things are on their time.

Take Notes and Create System for Tracking

Have someone take notes for each of these meetings. The only thing worse than not having a good idea is not writing a good idea down. It doesn’t need to be 20 pages, single-spaced, just enough to track and drive each actionable activity – description, who owns it, and timeframe – boom, done. It’s also nice if you rotate this duty, both to spread the love around and to help with engagement and empathy within the group. Also, don’t let someone subscribe to the “broken dish” philosophy; if someone is bad at taking notes, then they just need more practice and shouldn’t get out of doing it. Who knows, maybe their hatred of doing it will lead to innovations – text-to-speech notes, a Slack channel for to-do’s, etc. Along those lines, you need to keep a list of all the improvements that have been suggested and their current status. This can be with as much structure as you see fit. At a minimum it needs to help reduce duplication, provide transparency, and show wins (completed items).

Allow for Ad-hoc Loops

Its O.K. if a developer stops by and asks the sys admin what they think about a potential automation step. In fact, that’s exactly what we hope is happening. This is a great sign that your organization is starting to work this way rather than forcing them in to interact. Sometimes management wants to tightly control all aspects of the team, but you have to loosen up the reigns some. Yes, this will lead to some failure and delays, but that’s all part of learning. You need to maintain enough structure that these are minimized and have a low impact but allow for this grow within your organization.

Provide Training and Coaching

So I tried to gear the Tips to have more information than just “avoid the traps,” but this one is worth calling out. You need to provide your team with training and ongoing coaching on providing feedback. That’s where the regularly scheduled meetings come in handy: you can do immediate follow-ups afterwards to provide words of encouragement on how someone provided feedback or coaching on how they could improve their feedback. Along these lines, if you manage a team, a team members ability, or inability, to provide feedback should be a performance metric. Are they contributing? Are they contributing in a meaningful way? Are they communicating outside of their group? Are they embracing and supporting the system components listed in Tip 1? If not, you need to address it. At a minimum you should have individual, bi-weekly meetings with your direct reports to get their feedback and to provide your feedback. Coaching and feedback training is part of the overall system. Are we as individual contributors getting better?

Hopefully these tips help you get started with establishing feedback loops within your organization.