This post is part of the series “Z2A: From zero to agile”.
The daily meeting
The first procedure that I like to introduce in a new team moving to agile is the daily meeting.
It is very easy to apply and explain: most of the projects already have a sort of weekly (or oftener) status meeting where all the team members (and often various stakeholders) sit together and everyone reports about his or her week. It’ s usually not very efficient because it can become very long – one hour or more – and boring (people tend to go into details: in a week a lot can happen). At the end you just get a bunch of people tired and a long list of actions, to-dos or issues to clarify.
Therefore my first action would be to change the meeting from the weekly frequency to a daily one and slightly change the topics discussed. Sometimes I do it twice or thrice per week at the beginning, so that the people can get used to the new rhythm.
The most important things in the regular meeting are the regular frequency (best daily), that it is time-boxed (i.e. a fixed duration, to avoid that things drag on) and that the entire team participates.
At the beginning you could plan just two weeks to learn each other (a sort of pre-sprint), using maybe maintenance tasks or preparation tasks.
Let’s have a look at the characteristics of the meeting in details.
It’s important to have a regular schedule because this enforces a rhythm to the team and makes it a habit.
If you do it quite often (for example daily, strongly suggested) you can limit the discussions, since things to discuss are limited to max one day time span.
It should be fixed, in order not to drag on discussions. The best is to keep it very short.
If you do it daily, then you can manage it in 15 minutes, a duration that is not hindering the normal workflow. if you meet e.g. three times per week than it could be a bit longer but in any case you should keep it below 30 minutes.
Doing a stand-up meeting helps to keep the meeting very short, as after 15 minutes the average person is tired of standing 🙂 and it means you can keep it everywhere, no need to book a meeting room (but preferable the place should not change, you can even have it every day in your kitchen).
Flex time can make very difficult for a team to get together for a daily Scrum every day. However, having a daily meeting and having it at the same time and in the same place each day help a project establish and maintain its rhythm.
I prefer morning meetings. But you can decide the best time that works for you.
Disadvantage of afternoon scrums: you have to try to remember what you told people yesterday about what you will be doing today.
Disadvantage of morning scrums: you have to try to remember what you did yesterday so that you can report this.
My opinion is the first disadvantage is worse, since the most important thing is what you are going to do, not what you did.
Every one can attend the daily meeting but an important rule is that only the team member (the so-called pigs) can speak and not the stakeholders (the so-called chickens). This should be a firm rule, if one day you allow a chicken to make a comment that seems useful (even if the chicken is the CTO who was just passing by) you cannot avoid that another chicken the next day will make a comment and soon you will have a lot of people doing any kind of non useful comments.
When run well the daily Scrum will always be of value to every pig.
Sometimes a pig is coming really late and cannot make it or sometimes there will be specific deadlines that are so urgent and so imminent that you may be tempted to skip a daily Scrum.
And that’s not all that bad. It’s when the situation becomes chronic or when too many pigs miss meetings that the situation begins to smell.
Scrum suggests that everyone answers to three questions:
what I did yesterday, what I will do today and if something is in my way, blocking my work.
I find these quite useful, independently if you follow Scrum or some other methodology.
Stick to these questions and then you won’t extend what was supposed to be a 10 to 15 minute meeting into a half-hour or more.
If a discussion starts: remind the team members to focus on answering the questions.
If the people say I’m just fixing bugs and tomorrow I will do the same, ask which bug exactly.
The team members should not report to the project manager but to the entire team.
Sometimes the daily meeting begins to feel as though it exists solely for the project manager. You’ll see him or her furiously scrawling notes about who committed to what work and why some other task wasn’t completed.
There are two main purposes of the daily meeting and neither is to provide status information to the project manager. The first purpose of the daily meeting is to provide a coordination mechanism for everyone on the project. Once a day it can be very useful for everyone to hear where everyone else is.
The second purpose of the daily meeting is for each team member to make commitments in front of his or her peers. When a developer answers the “What are you going to do today?” question she is making a commitment to her peers, not to the project manager. At the next meeting if that commitment has not been fulfilled it is not the project manager’s role to say, “Tsk, tsk, Lucy, yesterday you told us you’d be done.” If Lucy said she’d be done and isn’t she probably feels bad enough. She knows what she told her peers and she knows if she didn’t finish because of whatever reason.
This works because it’s not a usual project status report hierarchically built but it’s a peer motivation. The team members will feel ashamed if they report to their peers too many days in a row that they were not able to complete the tasks they committed to.
You will soon notice an increase in volunteerism within the team. They’re taking an interest in each other’s tasks and are more ready to help each other out.
And the meetings let the team take advantage of the group’s experience and ideas to solve the problems and clear the obstacles.
Final hints for the meeting
Stick to the topics of the sprint. It’s very easy to get off topic and extend what was supposed to be a 10 to 15 minute meeting into a half-hour or more. If a discussion starts: remind the team members to focus on answering the questions and that the meeting is time-boxed.
At the beginning, just to learn – let’s say the first two weeks – you can use maintenance or preparation tasks, then when the iteration is prepared, you can switch. If you use maintenance tasks the risk is that people say they’re just fixing bugs and tomorrow will do the same; then ask which bug exactly and append an exact tasks list (will see the kanban board for examples) in the meeting room.