Effective communication isn’t just about sending messages; it’s about knowing they landed, were understood, and acted upon. In agile software teams, short feedback loops are one of the most powerful ways to reduce misunderstandings and build alignment. Here’s why they matter and how to build them—both inside and outside the development team room.

“The hardest part of any project is communication.” ~Lynn Brownlee

Why Communication Breaks Down

Miscommunication has been with us since childhood. Anyone remember the game of telephone? Everyone stands in a circle, someone starts a message, and each person whispers what they heard to the person next to them. When it makes it around the circle, it’s almost always a completely different message! Why is that?

Let’s think about playing telephone in our work environments. Just like in childhood, messages get distorted as they pass from person to person, and as more and more media, feedback, and interference are added to the mix, the challenge becomes greater, especially for remote workers. Nowadays, we talk in memes and black and white messages. We even seem to favor having our camera off instead of on during meetings, which greatly diminishes non-verbal feedback.

At the same time that our current communication mediums diminish our messages, they also increase distraction. Has anyone been called on in an online meeting just to unmute and ask, “Could you repeat that question?” An example I’ve seen while working with one of our clients comes to mind. A comment was made during an online meeting (with cameras off), and the individual who needed to engage did not respond – radio silence. The conversation moved on (after a brief pause) until much later, the person caught on and said something to the effect of, “Were you talking to me back there? Sorry, I missed that. Someone came to my door.”

Beware! The Illusion of Communication

“The single biggest problem in communication is the illusion that it has taken place.” Attributed to George Bernard Shaw

Communication is a broad topic, with many books, papers, suggestions, tips, and techniques published in any and all forms imaginable. If one of the biggest challenges to and problems with communication is the illusion that it has occurred, then we should work to employ methods that give us best possible chance for communication to actually happen.

Had the person who answered the door instead of actively listening to the discussion not realized they missed something, the team would have walked away with the illusion that they had communicated effectively. The person talking didn’t realize they were not heard, and the person who had stepped away missed out on an important piece of information without even realizing it. The rest of the team assumed that what was said was heard and that everyone was on the same page.

Every individual there could have left with the illusion that proper communication had taken place, which could have had dire consequences for productivity, effectiveness, and the success of the entire team. To make our communication more effective, especially in the context of an IT team, it should be planned, consistent, expected, and focused.

What Feedback Loops Are and Why They Matter

Feedback loops involve collecting information, reviewing and analyzing it, and disseminating or acting on it. A key principle to remember is that short feedback loops often mean fewer misunderstandings and faster course correction. When possible, prioritize creating short loops rather than longer ones. Another thing to remember is that feedback loops come in all shapes and sizes. Some are formal and structured, and others are informal and personal. Some are rather obvious, and others are quite hidden, shadowed by other processes.

With this in mind, you probably grasp that “Feedback Loops” is not a narrow topic! Search for “Agility and Feedback Loops,” and you’ll find hundreds, if not thousands, of illustrations from simple, rudimentary sketches to highly detailed diagrams with well-documented points of interest. So, where should you start?

Where to Begin: Designing for Real Teams

I’ll answer that the same way I answer most questions around agility and communication: it depends. If we aim to build an ideal Scrum team, with a fully engaged and empowered Product Owner working closely with dedicated development resources as an autonomous, self-directed unit focused on optimal delivery, we can design effective feedback loops around our delivery cadences.

However, in my experience, fully engaged and empowered, autonomous, self-directed teams are very hard to come by. Instead, most real-world teams deal with legacy environments, outside management influences (including micromanagers), corporate cultures, reporting expectations, deadlines, resource constraints, and/or lack of trust between individuals. Those things and more are what make up the elements of “it depends.”

So, where do you start? I’d suggest starting with the fundamentals from the Agile Manifesto.

These four principles are the basis for feedback loops. Add to these principles an Agile adage of “Sense and Respond,” adopt this very simple feedback loop as a mantra, and I promise you, things will start to happen.

This simple diagram can lead to significant improvements when adopted and applied. Yes, there can and will be roadblocks. Yes, there will be fits and starts and bumps along the way. But just like a company that wants to be in business for a long time has to invest in innovation (be it of products, processes, or technology), the same applies at the team level. A team should invest time and energy in continuous improvement. Some of these improvements should be focused on developing quick, short feedback loops and improving communication whenever given the opportunity.

Why short feedback loops? The shorter the gap between feedback cycles, the less the chance of divergence in understanding. Scrum teams have daily standups and some will have weekly demos, backlog grooming sessions, sprint planning, and feedback sessions. All these feedback loops are designed to help folks stay in sync and to build and maintain team alignment. The higher the team alignment, the higher its functioning will be.

Inside the Scrum Room

Believe it or not, applying the principles of feedback loops within the context of a scrum team is the easy part! The Agile cadences themselves are indeed feedback loops, and when those practices are followed and participated in, the team has a higher chance of alignment. While it may sound easy, it requires discipline, commitment, and an understanding that sticking with the practices will reap rewards.

As a team, go through a few sprints, follow the disciplines, then review your feedback loops. Are they effective? Are they too much or too little? Should more emphasis be put on some and less on others? Simply discuss, learn, and adjust when and where needed.

Outside the Scrum Room

I have seen time and time again that some of the most critical adjustments need to be made to feedback loops outside of the scrum room. These aren’t talked about very much within the Agile community, but in my experience, they are as important as, or even more important than, what’s happening inside the scrum room. This is where I have seen many Agile efforts fail, and it all comes down to communication and feedback loops.

When Agile Works… But Only Inside the Scrum Room

Think through this scenario. You are part of a scrum team, and the department and company have decided to dive full-on into adopting Agility. A scrum room is set up with empowered product owners, agile training has been invested in, resources have been dedicated, and the team is set up with whiteboards, sticky notes, and everything needed to start up a project. You even have an agile coach to lean on! The team has defined stories with a definition of done/completed story pointing, and you have even put down some working software to build upon.

It hasn’t been an easy journey, but it’s working. You are learning, velocity is increasing, and everyone is all in. Inside the room, things are going great! Everyone is fully engaged and doing well. The Scrum Master, Coach, and entire team are all excited about the progress.

Unfortunately, that euphoria may not translate outside the room. The head of sales may not feel confident that the product they committed to and sold is going to be ready on time with the features promised. They may be putting pressure on the CIO to provide concrete evidence that the project is on time, and, “Oh… can it do this additional feature that was promised but not communicated?” The CIO may be worried about the resource commitments because there’s another project with a higher priority, and, “Wouldn’t it be easy to steal someone from the scrum room or just a part of someone to work on this other priority?”

They can see the reports on velocity, story points, and burn-down, but while everyone in the room nods and agrees and smiles, outside the room (and up the organizational structure), they don’t understand what those terms mean. Let’s face the facts, if you are not in the room, some of those metrics just don’t mean much, even when the terms are understood. As an example, I once had a Senior Application Director state, “To me, Agile is a four-letter word, and I don’t want to hear it again.”

This is just to point out that Agile/Scrum has short, effective feedback loops to make sure everyone is aligned to the project, but that alignment is active within the team, inside the room. One of the biggest challenges lies with the audience outside the room.

Building Feedback Loops for Leadership and Stakeholders

Time and effort by the Scrum Master, possibly a PM, a business leader, and a technical leader, need to be applied to feedback loops outside the room. What does delivering 42 story points mean? Are we adhering to established architecture? Are we focusing on the right functionality? Are we managing risks that have yet to be resolved?

Many of the questions you ask and the issues you address will ultimately be specific to the company and culture in which you are situated. Here are a few thoughts on what “outside-the-room” factors you might consider.

• Maintain a “risks and issues” register. Share and review it with management outside the room.
  • A shared risk or issue means it’s no longer sitting solely on the back of the project teams. Now, it’s owned by everyone it was shared with!
    
• Set up frequent demos for a broader audience outside the room (in addition to internal demos).
  • Consider that some departments may need to see more demos than others. I’m on a project now where we do a weekly demo for the team. One of the product owners takes screenshots every week to show her team of end users. Then, she brings their feedback back to the scrum room.
    
• Create a high-level functional map.
  • Consider including the story point value for each of the larger functionality groups so terms like velocity and burn down have a visual anchor for reference. Be creative!
  • A visual representation could provide a massive amount of relief or peace of mind to folks outside of the scrum room. I bet you’ll be surprised who and how frequently certain individuals come by to review it.
    
• Publish the DEV URL, so anyone can see the current state of what is being done.
  
• Set up a technical overview with the architecture and infrastructure group(s) to make sure they are aware of what is being done and why.
  
  • If temporary solutions were established early on, clearly call those out and share the plan to address them.

Bottom line here is that time and thought have to be given on how to engage and report to the management structure outside the Scrum team. We must build feedback loops that will provide our friends outside of the scrum room with relevant information, in their language, and in a way they can understand. Here’s a hint: terms “Fibonacci story points,” “relative sizing,” “burn down,” and “sprint velocity” may or may not resonate with folks in that environment! Adjust your communication accordingly.

When Things Go Wrong

“Bad news doesn’t age well” ~Lynn Brownlee

Here I go again, bad news ages kinda like milk left out in the sun. Much like managing risks and issues, care has to be given on how things are shared. Every organization is different, and every person in the organization is different. How, where, and when to share information (especially bad news) needs to be well thought out.

Agility Principle #4, “Responding to change over following a plan,” creates more feedback loop needs. If a team takes on new functional capabilities, how is that being communicated, especially to folks outside of the room? How are surprises minimized so that alignment is maintained? Embracing change is a vital paradigm shift that comes with agility, but it also comes with a communication responsibility that should be effectively addressed.

The Big Takeaways

Back to my original statement, the hardest part of any project is communication. Feedback loops are the heartbeat of healthy communication in agile environments. Whether you’re building trust within a Scrum team or aligning with external stakeholders, short and intentional communication cycles are key. Take some time, put yourself in the shoes of some of the folks outside the room, and ask, “What would I want to know if I were in their role?”

I use the following simple feedback loop on a current project. It’s a very small, well-defined project, but with a company we are working with for the first time. (This is great, return clients are our norm!) Working with the development team, we created a set of high-level stories, developed a sprint plan, and documented everything in a spreadsheet. We conduct weekly demos and can track a burn-down of both story points and contract hours. We could have created an Azure board or Trello board, but the spreadsheet is working just fine and is easily understood by this client.

Every week, I conclude the meeting with this simple and concise feedback loop. I ask, “Are you getting the information you need? Can I provide anything additional to help you understand where we are in this project?” It does wonders.

Start small, stay consistent, and don’t wait to share the hard stuff.