Feedback Loops Feedback Loops


Feedback Loops

As mentioned in the previous Blog post, traditional software development consisted of multiple stages that were conducted in series.

Each of these steps, requirements gathering, analysis, development and testing could often extend for long periods of time.  This meant that the time between when the task was completed and when the determination of the quality or success of that work could be very long.  The individual performing the work may have lost some, or all, of the context of the task by the time they need to revisit it.  Additionally, it makes it very difficult to improve when the feedback is provided much later in the process. 

A key element to Continuous Delivery is to ensure that we tighten our feedback loops as much as possible.  This applies both at the macro level and at the micro level.  At a high level, we want to gather feedback from each release of our software and to be able to immediately use that information to determine what we should work on next.  This creates a feedback loop from the client directly to our product backlog.  We also want to ensure that we have these feedback loops at a lower level as well.  Our developers and testers should work hand in hand to ensure that the developer is immediately aware of, and can address, any quality issues as they are developing the software.  Having a tight feedback loop between the team members ensures that we catch issues early and are looking at quality throughout the process.

Incorporating Feedback Loops does not just apply to the software itself, but to the entire Agile Development process.  Every two weeks, after demonstration of the sprint deliverables, the teams conduct a Sprint Retrospective.  This is an opportunity for the team to explore what did, and did not, go well in the last two weeks.  It is a constant forum for focusing on improvement, and is a key feedback loop for the team.

Tight feedback loops have another benefit besides constant improvement and that is the willingness to experiment and try new ideas.  Due to the shorter duration of the development cycles, we can very quickly identify what is not working well.  This allows the teams to try out new ideas that might be helpful, while ensuring that the effectiveness of the change will be evaluated and re-evaluated every sprint.  The freedom to experiment, both with technology changes, as well as process changes, brings out the best in our team members and ensures that we can remain innovative and creative in meeting our client needs.

To ensure the timeliness of the feedback, our old manual methods and tools may not be sufficient. We need to review our process and automate as much possible. We will discuss the role that automation plays in Continuous Delivery in our next blog post.

For Part 1, click here: Agile Software Development