As an iterative and incremental method to software development, Agile is a big advocate of collaboration. The objective is to gain acceptance and satisfaction from business stakeholders, end users, and partners through the prompt and constant delivery of operational software that delivers the expected business value and meets user expectations.

One fantastic way the Agile development process aids a good amount communication and collaboration is through feedback loops. Continuous feedback helps development teams because they can avoid spending a large amount of time building solutions that are not right for the team and also helps the wider team stay in the loop of what is to come. But the question remains: How and when should we incorporate feedback loops? Should this be during or after sprints? Read our article to find out more.

What is a feedback loop in an Agile process?

A feedback loop is a business process where the outputs of a system or sprint are circled back and used as inputs for the betterment of the business. For example, if it is an e-commerce website, you might find that one of your products sells far better than another and decide to cease selling one and invest your capital into the other.

Feedback loops help you to make data-driven decisions and are often the difference between a business that grows and one that doesn’t. Many businesses use feedback loops in an unofficial capacity. By that we mean that they look at the top line data and make decisions based on what they see without any real structure in the form of testing and learning. They probably don’t even realise they’re doing it.

Feedback loops come in the form of frequent meetings, proven tactics, automation tools, and other methods to keep an open flow of communication and collaboration.

Feedback loops are built into the Agile development process to:

• Uphold communication throughout the development process rather than just after
• Gain continuous feedback (good and bad) from different teams
• Detect areas for improvement early on
• Increase software developer productivity
• Accelerate the development lifecycle
• Satisfy stakeholders, end users, team members and partners by producing the highest quality software possible

The importance of feedback loops both during and after sprints

Most businesses don’t do feedback loops properly, and they don’t do them often enough. Feedback loops should be used both during and after sprints because the more data you gather about what is working the better business you will be. It makes sense, doesn’t it, when you put it like that?

Let’s use a real-life learning example. Imagine now you’re learning to play the piano. Typically, you will sit in front of the piano, press a key and you hear that note instantly. But imagine, if you pressed the key and you heard that sound a week later? How long will it take in the second scenario for you to master the skill of playing a piano? An awfully long time, we’d say!

In an ideal context, we would like feedback to be ‘instant’. That’s how we learn best. The further you are removed from ‘instant’, the more you compromise on learning, improving and closing the gap between what’s required and your goal.

Bringing back technology into the equation, the longer you are building something without asking for feedback, the more you compromise on your product. In a business setting, imagine if you were to incorporate feedback loops into a development sprint. The feedback loop is essential both during and after sprints to continue learning. They’re teaching you how to reach your final destination through the path of least resistance, with the best possible outcome in mind.

However, we understand incorporating feedback into your development process isn’t an easy task. Even though we ‘see’ how this makes sense, it is not always straight forward to understand how it can be embedded to increase speed, creativity and agility without the need to compromise on it.

The answer lies in your continuous integration and delivery model and the hierarchical structure of your organisation. Once you get it right, incorporating feedback and creating market leading products and services becomes an inevitable part of the process.

Agile: Feedback Loops in Scrum Framework

Scrum is an Agile framework which helps teams work collaboratively. In the Scrum framework, teams work in something called sprints, which are periods of time in boxes of one to four weeks. During each sprint, there are a several types of meetings where feedback can take place:

• During the daily stand-up meeting which allows teams to share the status and identify challenges to the project
• During the sprint review meeting which means gaining feedback from the product owner, stakeholders and end-users.
• In the project retrospective, which allows the development team to relay back on what has worked well and what could be done better for their Agile projects in the future.

Thus, recurrent feedback from business stakeholders and end users holds the development team focused and accountable on the solution’s envisioned goals. Feedback loops also allow the team to adapt changes later in the development process, especially as new or refined requests materialise.

Feedback loops in e-commerce versus feedback loops for internal software solutions

Feedback loops in e-commerce are relatively easy to understand. You analyse your activity, make a change, market it to customers, feedback on the conversions you have, and then implement any changes as a result. Most companies are doing this without thinking too much about it.

Where feedback loops become a little more complicated and problematic is when we consider them on the backend of our operations. That’s because we need to gather feedback from internal users or employees in order to determine what works best. It isn’t as easy as analysing conversions here. We may need to take qualitative feedback into account.

This is never truer than when we’re launching something new. A new product or process, like a CRM or content management system. These are huge projects, and developing and launching them without any sort of feedback loop is a terrible idea. What if you launch and you find that it isn’t fit for purpose? How many hours of work – how much money – do you think would be wasted?

We split these major development projects into sprints, so it can feel natural to incorporate feedback loops into these stages of the development, but we’d recommend you gather data more frequently than that. That’s the best way to make sure your product is fully fit for purpose in the end.

How to gather feedback for back-end systems

The easiest way to gather feedback for back-end systems is to incorporate demonstrations into your development process; some within sprints and some shortly after they have finished.

This might make planning for future sprints more difficult than it would be if there were fewer feedback loops, because you’ll have to be Agile enough to change your plans if you need to. You’ll need to factor this in.

The psychology of iterative feedback

Iterative feedback methods start with a requirement or assumption that forms a base for the project and then test it, revise it, and create the next version. It gives developers the chance to tweak as they develop, improving the product as you go. This is considered Agile.

Taking in feedback and learning all the time helps development teams and clients feel certain that they are producing a solution that is going to be the greatest solution possible. This helps team morale. Involving your team in the development of a product also helps them to feel appreciated and valued, because you’re showing them you need them, and their input and knowledge about your business is appreciated and useful.

This is especially true where your business is not e-commerce, because your employees and their feedback through demonstrations and trial periods are all you have to inform your feedback loops and help inform the next stage of your development. Getting feedback for your efforts and then doing something about it next year is not the best use of your time or the impact it has on the business. Why learn if you aren’t going to implement? Why invest if you aren’t going to improve your processes? This learning mind-set is an important part of Agile, and it won’t only benefit you here, when you’re developing something new, but in every part of your business.

How to make comprehensive feedback loops and iterative design work for you

There are good and bad ways to do this. In an ideal scenario, you will have the following landscape in place,

• clear major requirements,
• permission and the ability to evolve functionality over time,
• time, so that feedback loops can be incorporated properly and without rush,
• innovative technology is being learned as the project evolves,
• goals that are flexible and subject to change as things move on.

You may not have all of these elements, but the more you have the better your development project will suit an Agile way of working and more regular feedback loops.

The pros of regular feedback loops

The advantages of working with regular feedback loops and iterative development are:

• issues and defects dealt with early,
• easily measurable progress,
• changes happen naturally and are easier to implement,
• risks are identified early,
• a functional and operation product is developed with every feedback loop, then improved upon,
• the specific requirements of users are being regularly checked upon and adapted to.

The cons of feedback loops

• more resources may be required,
• project management is likely to be more intense,
• no guaranteed end date,
• this way of working must be implemented by a highly skilled team.

Digital DOM

Digital Dom can help you to incorporate Agile processes into your software development projects by delivering large scale and high performing systems to help you increase the speed of innovation and decrease time to market.

For more information on how we can help, speak to a dedicated member of our team by filling in the form on our ‘Let’s Talk’ page, or email hello@digitaldom.io.