SCRUM - How Droptica continuously improves its work?

We recently wrote about  why SCRUM improves software development quality and why remote scrum teams are often a good choice. 

Today we will discuss a very important part of scrum which is often neglected, what leads to reduced preformance, delays and mistakes - Sprint Retrospective. 

What is Sprint Retrospective?

This is one of the meetings in the SCRUM methodology. The meeting takes place on a regular basis, at the end of each sprint. At our Drupal development agency, we hold a meeting once every two weeks. During the meeting, the development team analyses the previous sprints and deliberates about what can still be improved – how to eliminate errors and blockers, and how to speed up work.

How does the client benefit from this?

The meeting usually takes no more than 15-60 minutes. A Sprint Retrospective usually has anywhere from three to six participants, depending on the size of the team carrying out the given project. Other companies might implement this process in another way, shape or form. It's easy to calculate that this meeting can cost the client at least several man-hours. Is it worth it? 

Yes – without question! During each meeting, the team proposes improvements and agrees to implement some of them starting with the next sprint. In many cases, these improvements reduce the lead time. The change meeting is held once, and the improvement is applied continuously throughout the subsequent sprints. After a number of sprints, we can achieve pretty sizeable time and money savings.

How do we do Sprint Retrospective at Droptica?

For this purpose, we use a Google Docs – Spreadsheet. There are five columns in the document:

1. Date;
2. DROP – what we should stop doing;
3. KEEP – what we should keep doing;
4. IMPROVE – what needs to be improved;
5. ADD – what needs to be added.

During the meeting, each person from the development team proposes various improvements that they would like to see and suggests what should be removed, corrected, added, and so on. Once everyone has spoken, the team chooses which of the proposals they want to implement with the next sprint. We try to choose 1-3 suggestions and implement them, so as to avoid making too big changes. We also identify the change owner, who is responsible for implementing the specific change. 

Examples of improvements in software development and DevOps

Below, you can find a list of selected improvements suggested throughout several of our projects. 

• We run automatic tests more often in order to squish all bugs faster. This allows us to avoid unpleasant surprises a minute before the deployment;
• We will improve the speed of building a new version of the website on the test server by reducing the database size by about 90%;
• Before we start working on a task, we talk about business goals, as well as carrying out the tasks from the software development standpoint in order to maintain consistency of the whole application and to choose solutions that are optimal for the project;
• Code review should be carried out by at least two people;
• We use git-flow and each task is carried out on its own branch. All tests and code reviews are done on this branch. After these are carried out, we merge the branch with the main development branch; 

Examples of improvements regarding work organisation

• Every day we send a short message to the client (Product Owner) on Slack with a summary of what we have done since yesterday and what we are going to do today.
• We break up the tasks in Jira into smaller ones, so that one task takes no longer than 3-4 hours. We can then better follow the progress of the work and quickly react to delays. 
• If during a sprint it turns out that the task is more difficult than we had anticipated, we change the Story Points for the task. 
• We continuously update our documentation. We adhere to the principle that if a question is asked at least twice, it should be added to the documentation. 
• The computer used for video calls must always be connected to the Internet with an Ethernet cable – this removes the annoyance of dropped and lagging video calls.
• In many projects, we have also removed the deployment from DoD – usually, these deployments take place once every two weeks or once a month, sometimes even on the client’s side. When we have a weekly sprint, this should not block us from closing the task.
• Planning with taking support into consideration – on the basis of previous sprints we know how much time we spend on things that cannot be planned (for example hotfixes added by the client).

Additional Sprint Retrospective tools

Most of the time simple spreadsheet is enough to perform the Sprint Retrospective. However, recently we started to use external FunRetro application (FunRetro | Improve your team with fun sprint retrospectives). It helps to improve the Sprint Retrospective meetings. We encourage you to try, especially that the application offers a free version.

Summary

At Droptica, Scrum Retrospective gave us tangible effects. I highly recommend this way to objectively look back into the past to every team, even if they do not use SCRUM in project management. You can simply schedule a 1-2-hour meeting in the calendar once every two weeks and talk about what can be improved. You can achieve pretty significant results in just a few weeks. Try it for yourself!