The goal of Agile software development is, well, to be agile. This means you should be able to react fast. This requires feedback. In this blog post, we are going to explore various areas where feedback is relevant.
Context
We all know the famous path with deviations:
Software development can look like that. You would like to hit a target, that is here a functionality offered to the user. There is an ideal path (dotted path) on which you deliver the intended functionality on the first try without problems underway. This is not realistic. There are always deviations from the ideal path, e.g., missed requirements, bugs, bad design that needs rework, etc.
The goal is to keep those deviations to a minimum and to detect them early. The earlier they are detected, the cheaper they are to fix.
#1 Exploration before going into details
Depending on the risk, it makes sense to explore certain things before starting an implementation and going into details. Is this API you don’t really know well, really delivering what it should? Hit it via Postman or any other API client to check.
#2 Defining expectations
If a user story is started, it often makes sense to define the high-level expectations in tests. In this context, you should put each acceptance criteria of the story into the cheapest test to prove that the acceptance criteria are fulfilled. If you have covered that, you basically know, when you are done with your story and have reached the defined goal.
It is important to use the cheapest, i.e. simplest, test possible because you want early feedback. It doesn’t make sense to check acceptance criteria in an expensive and cumbersome UI test if it can just be validated in a simple unit test.
#3 Compiler and Linter
Depending on the technology there is immediate feedback when typing code. Because the compiler and linter in a modern IDE show that red squiggly line underneath code that is not as it should be. This is fast feedback and without it, we would lose a lot of time.
#4 While doing TDD
TDD is all about feedback. The most important aspect is not the feedback about whether your code works. In my opinion, the crucial part is the feedback about the design of your code. Is it easy to use and to test? Do I need to set up a lot for my test? Does someone understand what the code is doing from the tests? This is early feedback within seconds or minutes.
#5 Build
The build is the most obvious one. Building software and running all the tests is usually done anyway. Depending on the project this might already happen locally on the developer’s machine or only later on an external CI/CD system. It gives you feedback and answers the question if the whole system is still working. This depends also on the scope of the build. You have to make a trade-off. Building the whole system gives you full feedback about any side effects. Building only part of the system is faster.
#6 Integrate
Integrating your code changes with the main branch shows you if your changes still work in a larger context. Also, this might be the version that is usually deployed onto a dev or test system where further tests are conducted. These tests give you additional feedback.
Important here, is the feedback the other way around. If I build something, I would like to prevent it from being broken by others. Therefore I have to provide tests around my new code. Those tests should provide other developers (and myself in the future) feedback. This feedback should help others to not break my code.
#7 Pair programming
Pair programming gives you very immediate feedback. It provides a feedback loop possibly as short as the compiler and linter (depending on technology). The scope of the feedback is not only the code’s functionality but also the design. This makes pair programming valuable. Design errors that are hard to correct can be spotted early in the context they are created.
#8 Pull Request
This is the feedback I do not like, but in some contexts, it might still be a good idea. Pull request comments are added asynchronously, late, and out of context. It is usually hard to spot design errors in pull requests. Other feedback mechanisms are preferable.
#9 Users
A feature is useless if users do not want to use it. Similarly, if a feature does not work as expected by the user its value decreases. Users are one of the most valuable feedback sources in agile software engineering. At the same time, they are usually distant from the developer. It is important to integrate the user in the overall feedback loop to also get early feedback for this case. Spending two weeks on a new feature that is useless for the software’s user is a lot of waste. Therefore, users should be included in the software development cycle early and often. On the other hand, it can also mean that software should be delivered early and often.
#10 Monitoring and analytics
Finally, data does not lie. While monitoring should provide us with data about the performance and errors of our features, analytics gives us an idea about how our software is used. This can provide us with feedback more objectively.
We see feedback in agile software development is crucial! A Lot of places where we do not really think about feedback are important. It helps us to deliver the right features and the features in the right form.