Agile Development: My Experience as a Scrum Master

At around 27th of March 2021, I was promoted (partly against my will) to become the scrum master of my dev team at PPL class. As they often say: “With great power comes great responsibility”, which did not help my confidence at all when I was assuming office. This is also the same time I got a part time job as a software engineer at Dekoruma. I quickly realized that working two project at once is not going to end up well. So, I ended up taking a more laid back role in the team. This is still by no means an easy task, but I think I’ve gave it my best shot.

As a leader, you are responsible for the output of your team. While it is true that leaders are not expected to take a big chunk of the actual labor that regular developers take, they are expected to ensure that those labors are done and contributes something to the overall product. Stockholders mostly cares about their products more than anything else. Therefore, progress without results is equal no progress at all. I tried to keep this in mind during my whole 3 week terms as a scrum master.

My job started just after the 2nd sprint planning ended. We have picked two tasks (PBI) to be done by the next 3 weeks. I called my members for our own development planning, and we started discussing how we can approach the problem.

Our team’s responsibilities for the next 3 weeks

To simplify, our team is tasked with three things:

1. Remodel the current account database to store ‘district’ and ‘sub district’ instead of only ‘area’, and remodel all of the related webpages (Sign-up page, account list page, etc.) accordingly. (PBI-5)
2. Implement a feature to generate an overall diagram of TBC case count. (PBI-6)
3. Resolve several bugs found during the last sprint’s review.

Overall, all of these tasks were not too difficult to implement. So, the main obstacle for this sprint was going to be to overcome the tendencies to work dangerously close toward deadlines. Deadliners usually attract bad code designs created in haste without long term planning.

Another obstacle was communication. All three tasks involved work on both back end and front end repository. Therefore, it was important to ensure that the developers working on either side can understand how to use endpoints created by the other. Any miscalculations discovered late on the project can take a few days to repair. It was important for us to get it right in one go.

After considering the two points above, I decided to do our initial planning phase with several goals in mind, in accordance to the Agile Manifesto:

• Individuals and Interaction: Ensure that the solution has been thoroughly discussed by the end of the initial planning. For example, during our planning on PBI-6, we tried to address all possible ambiguities before starting the team division (e.g. Do we perform the diagram rendering on the client side or the server side? What endpoints will be used by the client side to retrieve the necessary data? What query parameters are accepted? etc.). This discussion is done without any It was necessary — I thought — to discuss these things up front to minimize confusion.
• Working Software (with shorter timescale): Track all of the important dates (Individual Reviews, Progress Report, Sprint Review) and confirm a set of deadlines beforehand. This was may main preventive measure against deadliners. By creating checkpoints and setting expectations on each of them, I hoped that our progress would be more consistent each week. One of the principles behind the Agile Manifesto is “Deliver working software frequently”. By ensuring that progress are made for each checkpoint, productivity may increase.
• Add some buffer to perform quality checks and refactoring before any presentation. For each checkpoint, I mandated that a pull request should be created at least 3 days before the actual deadline to allow for more comprehensive code review.
• Customer Collaboration: Noted that there should be a deliverable for our progress report. This way, I had hoped to increase stakeholder’s feedback on our work, since this is the only time we got to present our results besides sprint review.

Results of our initial planning phase. It is a bit cryptic, but as Agile manifesto said: “Working software over comprehensive documentation”

Lastly, since we were working on an Agile mindset, I restated to the entire team that there won’t be a lot of direct interventions from me as a scrum master, and that I trusted them to do their job as per our specified deadlines.

And so begins the first half of the sprint. To be honest, it went better than expected. It only took a single reminder a day before the first deadline to ensure that all pull requests are created on time. It allowed more time for reviews and manual integration tests before our progress report.

The second half of our work were a little less than expectation. We ended up submitting all pull requests 2 days before the sprint review. Still, our cautious deadline schedule means that it was not the end of the world and we were still able to iron out the final result and rehearse on our presentation a bit.

Finally, the date of our Sprint Review came. Personally, I think our performance was pretty good. We were able to present the main requirements of our tasks and most of our works were accepted. However, there were some slip ups, such as missing validation error message on our web interface and missing diagram title.

Based on the sprint retros, I think my leadership during these short sprint is quite satisfactory. My colleagues mentioned the lack of overwork and good planning to be the main props of the 2nd sprint. There were a few hiccups as mentioned at sprint review. We all agreed that it was caused by not enough quality assurance and the lack of stakeholder’s feedback.

After some reflection, I found several lessons that can be taken:

• Garner as many stockholders’ input as possible. Our team did not use the progress report effectively. For our next sprint, we are determined to complete our main assignments before our progress report so that more feedback can be given by then.
• Settle all issues from the start. Anything that are not discussed/planned beforehand is a potential for disaster. The lack of such things in these sprint reduces the overwork needed.
• Discipline builds slowly over time. Agile development requires trust, and there is no way to gather the required trust other than ensuring the integrity of everyone during the course of development. It is imperative for a scrum master to uphold the promised expectations and create an example. Each successful checkpoint and meetings creates trust, and each unsuccessful ones diminish it.
• Give time for evaluation. It is easy to lose track of your main goal. Doing an evaluation during checkpoints will allow all members to picture their progress on the general picture and make team decisions easier.

Overall, I find my time as scrum master during these short three weeks to be quite an interesting journey. Honestly, it went better than expected. It created more trust between me and my teammates, and give a good management framework for the next scrum master. Hopefully, a stronger leadership will bring a better result based on the lessons learned from my experience.