One of the most important ideas of agile software development is for me the short feedback cycle. Instead of working for weeks or even months at a problem on our own, we try to get feedback as fast as we can. That not only works with user stories; we can apply this idea to every task independently of its size.
I experienced a great example of this principle a few weeks ago. Using this example, I would like to give you an idea of how to put a principle into action. For the sake of brevity, I am using the format of a PAR statement (problem, action, result).
The problem
We had an error in the code coverage generator for the user group project. Instead of the correct value it only showed a coverage around 2%. The challenge was that this particular code coverage task only works in the big build pipeline with a runtime of 45 minutes. It brings us the greatest amount of certainty (by creating a full test environment in the cloud, end to end testing through the browser an running all data migrations, etc.), but it means we only get feedback once every 45 minutes.
The action
The pipeline we have cannot be modified that easily. However, since we run it in Azure DevOps we can create additional pipelines without much effort. Hence, I identified the necessary tasks, copied them from the big pipeline in my new pipeline and run the pipeline. I had to repeat the step a few times until I could reproduce the error in the code coverage report.
The result
The new pipeline took me less than 15 minutes to create and it runs in 3 minutes. Instead of once every 45 minutes I now could get feedback every 3 minutes – 15x faster or 15x more feedback than before. With this improvement I was able to quickly iterate on the problem and find the reason for the error within a practical time frame.
Food for thought
I hope my example gives you a chance to think about ways how you could get to feedback a lot faster as you currently do. Please leave a comment with your ideas so that we all have a chance to improve our work.