looking east

Agile software development is a process which requires constant tuning. At Exoweb, we take every sprint as an opportunity to reflect on and improve our performance. In the sprint review meeting, we discuss the last sprint, analyse the velocity and burndown charts, discuss problems and their solutions, and find ways to avoid past errors. For the current sprint, the Ringier team has decided to make the following adaptations to the development process:

• distribution of responsibilities among all team members
• improved automated testing
• pairing for ticket design

The team will be experimenting with these changes during the current sprint and then decide in the next sprint review meeting if the adaptations have actually solved the discussed problems.

The Process

Every ticket which has been committed to the code repository, has to go through two independent review processes: the code review, and the demo review. The code review is done by the other developers in the team, suggesting improvements and tweaks, in order to ensure code quality. The demo review is a process in which the developer demos the ticket features to the project manager and the on-call developer who are then responsible for closing the ticket and preparing the demo for the sprint meeting.

The Changes

For the current sprint, we have decided to adapt the demo review process. We now assign two developers to each ticket: the maintainer and the tester. While the maintainer remains responsible for the actual implementation of the features, the tester will be writing automated tests and demo the ticket in the sprint meeting. The tester will thus replace the on-call developer in the demo review. Additionally, with the automated tests being written by someone else, tester and maintainer have to agree on the ticket design before starting to write their codes. And while writing the code, the maintainer will be able to use the tests as a benchmark.

The Reasons

With every sprint, the complexity of a project grows, and even small changes can produce major damage in the existing code if no precautions are taken. While the importance of automated tests is often underestimated in the beginning of a project, it becomes increasingly important when the project advances, as even seemingly minor changes might have unexpected side-effects.

So far, programmers were responsible for writing tests for their own code. This means design, implementation, and testing was done by a single person. As the team has previously decided that they preferred code reviews over pair programming, design problems were only discovered in the code review. We thus hope that above adaptations will lead to better design decisions, cleaner code, and less bugs which turn will reduce the need for refactoring after code reviews and increase the team’s velocity.