In this post, I’m going to do my best to explain what SCRUM ceremonies are and how we work with them.
Stop calling meetings ‘meetings’, aka: resisting change
Are you still working with waterfall methodologies? Is your organisation unclear whether Agile will work for them? Looking back over my most recent past, we started out with Agile around 2013 in the Middleware Department where I was working, when hardly anyone worked in Agile mode.
We had the opportunity to attend the CAS 2014 (Agile Conference Spain) in Barcelona, where we learned how to improve our day-to-day operations. As you can imagine, that’s when we began teaching ourselves through the various projects we were working on.
Here’s a photo from those early days, when we had our projects marked using Post-Its on a physical board. We decided to stop contributing to the deforestation of the Amazon rainforest and now we use virtual boards with TargetProcess.
We tried with a number of different tools, including JIRA, Rally and Mendix, before deciding on TargetProcess. In the end, we agreed with the development teams that it was the best option to implement the new working methodology.
So that’s how the Project Managers became either Team Leaders of development teams or Scrum Masters responsible for supervising the different ceremonies that form part of the Agile approach.
What SCRUM ceremonies are and how we work with them:
This was the meeting (oops, ceremony) we had the most fun doing. During the Sprint Planning, we decide what will be developed according to the priority set by the Product Owner and the estimate of the time/effort made by the Scrum Team.
In this stage, we tried various techniques to plan the tasks the team would be able to develop during the sprint defined (2 to 4 weeks). We started out using Story Points (1, 2, 4, 8, 16, 32, 40, 80) to determine the cost of each of the user stories.
Then we tried with T-shirt sizes (XS, S, M, L, XL, XXL) and finally we also tried Planning Poker, whereby each of us laid down a poker card to estimate what they considered would be the cost of each user story and thereby reach agreement.
In the end, we settled on story points and took 1 point as the reference value, which is what it took for us to edit a .properties file with the modification of a literal to be used later in our Java framework.
During these meetings, the most important thing was to reach an agreement between what the Product Owner (PO) wanted and what the team was actually going to be capable of developing. The role of the Scrum Master was to ‘rein in’ the PO, given that absences have to be taken into account due to flu (or coronavirus these days), holidays, etc. As you may have already observed, this deducts a small percentage of the team’s actual capacity during the duration of the sprint.
In our case, what we had the most difficulty refining was the dailies. These are everyday stand-up ceremonies taking less than 15 minutes, during which each person explains what they had been doing the previous day, what they are going to do today and if they have come across any obstacles to achieving the task scheduled.
These types of meetings allow you to identify the procrastinators who are always working on the same task daily after daily, as well as those who progress at light speed and those who really have some kind of difficulty finalising their task.
Once again, the Scrum Master assumes the essential role of ensuring that the daily takes no longer than 15 minutes. At times, we got into technical details and ended up continuing for as long as 45 minutes, with many of the team members who had a different type of role (remember that in Agile the teams are multidisciplinary) dropping out of the meeting.
In order to plan the Sprint, what the Scrum Team needs is for the PO to have left the User Stories prioritised in the backlog. Trust me, this is not as easy as it sounds.
The PO can prioritise at the start of any Sprint, so that the Sprint Planning ceremony is more user-friendly and quicker based on the Backlog Refinement.
Sprint Review or Demo
This is the ceremony that determines whether you are headed in the right direction or not. It’s the only one in which all the stakeholders must be present, as it shows the result of the Sprint and should confirm that the development is as was expected or, on the contrary, whether any changes need to be made for the next Sprint in order to make those changes as soon as possible.
Sprint Retrospective or Retro
This was also a fun meeting. During the Sprint Retrospective we used Post-its to carry out a post mortem analysis of what we had done best and needed to continue fostering and what we had done the worst and needed to modify for the following sprints in order to not make the same mistakes.
I still have the Post-Its that three of my colleagues (Alberto, Ana and Alfredo) devoted to me in one of those meetings after a very tense period of our project, during which they credited my role as scrum master as being the “one who stops the sh*t from hitting the fan”.
Things don’t always work out and situations may arise where upper management says: “I need this by yesterday”, meaning that we end up failing to comply with what we had planned in the sprint. I still clearly remember the words of our manager when he said: “Be my guest, go and tell the technology director you’re not going to do this because you have to finish your sprint.” Today this is not happening any more 😊
Since I really like the concept of RESILIENCE, we learned from this and ended up creating a board that was a hybrid of Scrum and Kanban (Scrumban) with a high priority lane for tasks that had to be dealt with as soon as possible, by the entire team if necessary.
Luckily, today the context is different and we have other tools, training and most importantly: a corporate culture with total support by Management and everyone working under the Agile approach.
So… are you still working in waterfall mode or are you ready to progress to the Agile model?