Nowadays, the vast majority of companies use Agile (agile methodologies), including the vast majority of Scrum. So let's take a closer look at this issue - after reading this post you will learn how to make meetings effective even without a Scrum Master. You will refresh yourself on the goals of the various parts of Scrum and see alternatives to the daily stand-up, where it is easiest to lose focus.
Scrum - it seemingly looks simple, we have defined forms of various types of meetings and how they should be conducted. However, it looks a little different in every company, and even in every team. The one thing that all these forms of Scrum implementation have in common is the possible lowering of developers' morale due to the number of required meetings. So are they all necessary?
Planning
Before we start a sprint, we need to plan it, i.e. to gather a set of defined and estab- lished tasks, and know what needs to be done within them. It is good if the whole team actively participates in this meeting, with priorities in the back of their minds. Usually the tasks are estyimated, while they do not always have well arranged dependencies between them - it may turn out that the sprint will start, and our task X, however, we can not start, because we forgot that we need to do task Y first. How to remedy this? In the next part of the article will be described Scrum meeting "grooming / refinement". - during it (but not only then!) you should remember to set dependencies between tasks.
You should also control the proportion of team members - if a project has 2 frontend developers and 5 backend developers, then it would not be a good idea if most of the story points come from frontend tasks. Also, keep in mind that at any time a sudden high-priority bug may "pop in" to be fixed. So, if we have potentially 100 story points available (according to the calculations adopted in a given team - each may have a different version), it would make sense to leave a margin of 10-15 story points for "unforeseen contingencies".
Stand-up / daily
Stand-up, also called daily, is a basic meeting, conducted daily. Each member of the team tells:
- what he did yesterday
- what he will work on today
- whether he has any difficulties with it.
At first glance it looks cool - every day everyone has a chance to get "in sync" with the rest of the team regarding where we are in the project and whether we can help someone with their problem. However, what does it look like in reality? In practice, most team members prepare in their heads what to say and wait their turn, ignoring the statements of the others (otherwise they might forget the statement prepared in their heads). If the order of speaking is random and members choose the next
person, most team members only pay attention to who has already spoken and who hasn't (if the next person is chosen what has already spoken, it will come out that we haven't listened). So what are the possible alternatives to this meeting?
Stand-up story focused
Instead of focusing on the person, in this approach we focus on the story, or a particular shuffle in our sprint. During the meeting, the focus shifts to each task in turn, and then each team member can comment on it
- whether they worked on it, whether they intend to work on it, whether the task is blocked by something else, whether unforeseen difficulties arose, etc. With this approach, there is a better chance that the team will have a better idea of the context of the current state of work after each meeting.
Daily-bot e.g. on Slack
You can approach the topic in yet another way - instead of holding meetings at all, you can use bots on instant messengers (Slack is the leader in such integrations). Then such a bot asks team members at the same time every day the standard 3 questions, i.e. what they did yesterday, what they are going to do today and if they have any problems. There are several advantages to this approach:
- you can think calmly about how to describe your report, and you don't have to repeat it over and over again in your head
- You can glance at the status of the other team members at any time, as the saved reports will be made available on a dedicated channel
Demo
The idea behind Scrum is to be able to periodically deliver some increment of value to the customer. After each sprint, it makes sense to present the work delivered throughout the sprint. However, it's easy to fall into the trap of only showing changes to the UI, that is, what the target user can see. Of course, this is necessary, while it is also worth telling about any changes that are not visible at first glance - perhaps some technological changes, repayments of technical debt, improvements in application performance or a slew of other non-functional things. Then the presentation of such values should be adapted to the level of knowledge of the customer (or his representative, most often the Product Owner) - if it is a technical person, we can afford to describe exactly what has been done. However, it's worth bearing in mind that the main goal of companies is to make money (and not to make the world a better place, as they sometimes have on their website), so it would be a hit idea to translate the results of technical work into specific, measurable metrics - e.g. instead of:
We did the overdue refactoring, now there is cleaner code.
A better statement would be:
Thanks to the refactoring done, the code has become more readable and easier to make further changes, so that more functionality can be implemented in fewer "men days."
Grooming / Refinement
Sometimes (and even often), the shuffles taken into a sprint during planning, need to be gently modified or better understood by the team. Perhaps tasks for future sprints need to be reviewed and discussed together. This meeting has been scheduled for these purposes. Then it is also important to establish the links between the shuffles - and especially to know which task is blocked by some other.
Retro
Retro, a meeting where the team discusses their thoughts on the previous sprint, can take many different forms, although the most common is that everyone tries to write out / say what went well and what went wrong (and whether we can fix it in the future). I presented this meeting as the last one, because, although also valuable, in my opinion it is not so necessary, especially if the sprint went quite "typical", and each team member would have to make an effort to come up with an opinion.
Summary
In this article I have presented and described the various meetings in Scrum. However, in order for them to pass smoothly and effectively, it is required that each team member knows what they are about and sticks to the accepted form. Of course, the details can (and even should) be tailored to a particular team - like the alternatives I proposed to typical stand-ups. Then it turns out that you don't even need a Scrum Master, and the team can be effective, cyclically deliver some value, and developers don't feel the excess of unnecessary meetings.
