Reflection loops of Agile Practices

The agile way of working has now come upon us with full strength; some projects with poor results and others with excellent results. Since the agile way includes elements of self-improvement, any poor results should soon become good results and finally, excellent results. As a Software Engineer, I really like this way to work since it provides me with some great tools.

In the pre-agile world, I could sometimes feel that my team and I would at times would drift away from the solution we were supposed to create. The time to market is putting pressure on the deliveries, and a complex technological surrounding forced us to work in a speed that left no time to correct bad input values in requirements. When thinking about this I also came to an insight that the agile practices I have selected to work with, give me a scheduled time to reflect.

Reflection loop 1: Self

Start by looking at Test Driven Development or TDD. When we implement this in both unit testing and automated functional testing, the practice will force us to reflect on and validate the requirements as a first step. So before starting to write a single line of code, we make sure that our requirements are testable since otherwise we cannot write our automated tests for the feature. The reflection is done by the test writer him- or herself and is done within a very short time frame.

Reflection loop 2: The pair

Pair programming is my next selected practice. It is seldom implemented to 100% since it appears to cut the production speed in half. And that is true!
It is true - if all developers

• …never write any poorly designed code
• …never introduce any bugs
• …and always are up to date with the architecture of the rest of the development department.

If you have this situation in your teams: Congratulations!

When pair programming actually is done, it will give the benefit of forcing the developer to reflect on the design and solution of the problem. If the design is incorrect or the solution seems unclear, the navigator or co-pilot will interrupt with a question. In order to answer, the developer must of course have a clear thought of the solution or think about it for a while. The reflection is done together with the team mate and perhaps a few times during the day.

Reflection loop 3: Stand up meeting

When I look at the stand up meeting with reflection in mind, I see that in order to get the reflective mindset in the team it is best if my team members are all focused on the same task. When they have different tasks, the interest between the team members decreases and I end up with sub tasks being forgotten or issues being missed. Done properly, with same goal in mind and with an attitude to help each other, I find that reflection is done in the whole team.

Reflection loop 4: Demonstration

When we do demonstrations from our team, we invite the product owners, the architects and the other teams that work in our product. It is an excellent way to get feedback on the completed task. Can we consider it done or not. Are there any issues that have arisen from our assumptions and limitations that need to be handled? The one thing I want to improve on is to hold demos more often, for any type of change that can be demonstrated:

• Test cases - to verify with stakeholders that the requirements are interpreted correct.
• Architectural changes – to make our surrounding teams understand how the latest code works.
• Working code – the normal demonstration

Reflection loop 5: Retrospective

We hold our retrospective once a sprint as normal. And this is the best practice of all because it allows our team to constantly improve in a pace that fits us. It also provides feedback and learning to the department in terms of how we can make all teams work more efficient.

Summary

To summarize, I find that the practices I have chosen to follow will allow me and my team to reflect in a number of ways, starting from the smallest feedback loop up to the largest.
This is also a lesson that I think is worth sharing, to find reasons behind the agile practices that you choose to follow. Reasons are of course several, but bring them up to discussion within your own team and see that it will be a lot easier to follow practices since there is a common understanding of why you do the things you do.

Joachim Nilsson, Capgemini, Technology Services, Sweden