Do you ever feel that others just don’t get what you meant or do the exact opposite of what you where asking for? Frustrating as it is, part of it can probably be blamed on you.
Enter feedback loops.
Being well aware that this is a universal theme, I will focus specifically on feedback loops in software development in this post. (Not excluding the possibility of writing multiple versions of this post.) Having spent some time in the ‘IT world’, I can cautiously conclude that non-functioning, chaotic feedback loops cause a lot of harm in many software development projects.
Every IT landscape, architecture, system, or codebase mirrors human behavior and organizational culture — including feedback loops. So if your communication and culture isn’t optimal, your software won’t be optimal. Meaning lost revenue, longer development and deployment time, poor performing teams, and other non-acceptable business risks.
The answer? Some serious reflection on both organizational structures and your IT landscape, architectures, and systems.
So what about those feedback loops?
Everything that we think of, develop or deploy is a direct consequence of our surroundings — or social context. So every architecture that we design, every line of code that we write is a reflection of human behavior and interaction. If you think doesn’t hold for your company, think again.
At the very heart of human interaction and organizational culture lies communication. The source of many, many failure (pardon my optimism here). If all goes well, communication results in a message being received, interpreted, and acted upon as intended by the sender. Effectiveness can be measured with feedback loops that — if effective — consist of:
- A sender that encodes information who sends it through a chosen medium;
- A receiver that decodes the message after which the receiver provides the sender with feedback.
These loops are especially important in software development, as timely feedback can mean clarity instead of confusion. Plus, feedback fulfills a psychological need: it increases intrinsic motivation and happiness.
One of the most simple feedback loops is the one between a developer and a system or codebase: you add or adjust the code and (automated) testing tells you how you work affected the system or codebase.
So far so good. But what if we add architects to the mix? Instant increased complexity. We see it all the time: architects designing a landscape or system in isolation and then handing it over to the ones who are responsible for the implementation. If architects are not involved in the implementation, it will create a distorted feedback loop. The developers will have a direct, closed feedback loop with the architecture and each other, but the architect might not receive any feedback at all (nor from the code, nor from the developers). Which can (read: probably will) result in a gap between the designed and implemented architecture. A simple solution here is to make sure architects are literally ‘in the loop’ and closely involved in the implementation of an architecture.
You thought this was getting complex? Now imagine we add other remaining stakeholders to the mix (designer, sponsor, product manager, UX experience specialist, supplier/vendor, the client, etc.). It’s tempting to create one giant feedback loop including all players, but that’s probably not going to help you. It will delay or diminish feedback between several players and you won’t be able to measure anything.
What might help, is to separate that one massive loop into multiple closed feedback loops that are easy to identify and measure. This requires some serious reflection on who reallyneeds to communicate with whom. The less loops you have, the smoother your process will be. Don’t overdo it, of course. You will need multiple loops and communication structures. I’m just suggesting you only keep the essential loops and make sure they are closed and measurable. This will also help keeping focus and prevents, for example, a back-end developer getting way too involved in design matters that doesn’t necessarily concern him or her.
Which brings me to a ‘small’ culture-related prerequisite: value congruence. Meaning that everyone involved has a shared sense of reality; shared goals, a shared vision of the business problem and the strategic solution, a shared definition of ‘done and a shared understanding of why they are doing what they are doing. Business Model Canvases and regular reflection on goals and progress can help here. During this reflection you can establish cross-team alignment by providing transparency and seeing and discussing progress and delivery of various teams. Which in turn, will provide context, feedback and satisfaction amongst team members.
So, even though it’s tempting to keep everyone in all loops and discuss everything with everyone, the key to high-quality teams and products is simplicity. Keep your feedback loops as simple and small as possible, and make sure your organisational structure (and culture) is something you would be happy to see reflected in your software architecture.
Evelyn van Kelle 