The scent of coffee filled the meeting room setting an appropriate atmosphere for the Daily with our distant teammates. Soon a check from the other side will be heard: “Can you hear us?”. The same moment, video will present a well lit room with the rest of the team.
Firing up the mini PC with already connected peripherals is a much easier exercise compared to the early days of plugging them into a notebook and guessing which combination of cameras, microphones, displays and speakers from the drop-downs is the correct one. Routine is the best teacher. Through it we also learned the best way to conduct these online meetings.
“Yesterday” we looked into distributed collaboration. Today we’ll talk about the meeting routines in distributed development. We hope to help you overcome any impediments encountered on the way to your goal with practical examples from our projects.
Good distribution of knowledge on all sides of the distributed team is one of the keys to the success of the setup. During the feasibility phase stories are spread across the team and different members are responsible for resolving the implementation details to a state where they are ready for implementation. Before the planning session the team holds a set of refinement meetings where stories are prioritized by business requirements and implementation “readiness”.
During sprint planning the product backlog items that should be implemented in the sprint are revisited. The items chosen by a product owner are split into more concrete tasks and overall implementation is discussed within the team. It may also happen that during the discussion the team realizes that the implementation is over- or underestimated. This is why the team often revisits the estimate.
Our typical setup for sprint planning is that the on-site part of the team shares the screen with the list of items selected for the sprint. After a concrete item is explained (either by an on- or off-site team member), the whole team is consulted for opinions and re-estimation, if needed.
After the items are revisited, the total estimated effort is compared against the team capacity for the sprint. If the estimated effort exceeds capacity, items for removal are discussed with the product owner.
In order to support good planning, each team member should have the up-to date calendar with vacation plans upfront. In distributed teams it’s not possible to have a physical board with absences planned for the next sprint, so it is good practice to have everything online.
In one of our projects we use SharePoint calendar to keep track of our absences for the upcoming period. During sprint planning, this calendar is used to calculate the capacity of the team and all the team members are asked to revisit their absences for the next sprint.
If the application on which the team is working reached the production phase and the release plan is in place, it is a good idea to have an ‘iteration’ planning meeting as the first part of the first sprint planning. If the iteration planning is taking place and not the whole team is in the same place, then you could try the following:
The iteration planning involves product owner and BAs and the scope of the iteration is explained from the business perspective. The on-site part of the team shares the screen with the list of items for the upcoming iteration. This meeting has a moderator who is from the team and the questions are asked to the business for further clarification. Sometimes it happens that off-site part of the team is not actively involved in this meeting, but is rather in ‘read-only’ mode. Some of the reasons for this may be a bad connection or the lack of time.
In general, both parts of the team should be actively involved in this discussion as much as possible. This because no, or less additional meetings are needed afterwards. In case the off-site part of the team is too often in a ‘read-only’ mode during release planning, this should be discussed during retro sessions (or earlier) so the problem is addressed.
Daily and second daily
Daily meeting is the point where we synchronize on our daily work during a fixed amount of time. It is very important, especially in the distributed environment, since the whole team is not sitting in the same room. Usually each team member explains briefly what she/he did since last meeting and on which tasks one will work during the day. In addition, possible changes in the sprint backlog are explained and team members who planned to leave the office earlier that day let other team members know about it.
Distributed daily meetings have a procedure in themselves since it is hard to fit all the content of the regular daily plus the overhead and some off-topic talks (and they always happen, don’t they… at least you have to ask what is the weather on the other side) in the designated time-box (usually 15 minute window).
Moderation of the daily meeting could be delegated to the off-site part of the team, which balances the effort on both sides. In addition, the moderator could be changed after each or a number of sprints, so that all members of the off-site part of the team may take this responsibility. Otherwise, it can always be one person.
In one project we tried different formats of the daily meeting:
- In the beginning of the setup the meeting focus was more on people and the work they did.
- After that we tried to focus more on people in the first part of the sprint and more on the remaining items themselves as the sprint was nearing the end: the in-progress or testable items were explained by the people working on them with any inputs regarding impediments or expectations on when the items will be finished.
- Our current setup is that we focus on sprint backlog items in our daily meetings during the whole sprint. The moderator is iterating through the items of the sprint backlog and the team members that are currently working on the item update the team about the progress. After the backlog is iterated, the moderator calls for a quick round on any additional updates.
In another project, the setup is different:
The daily is always moderated by the same person, usually the Scrum Master. He shouldn’t have a big role, but usually defines who starts the meeting, and then closes the meeting. The easiest way to progress through the meeting, since we are not sitting in the same room, is that the person who finishes his part says who should go after him. This avoids confusion and makes the meeting go much faster.
You should try to find the meeting format that fits your project best, but also adjust it over time.
If the sprint end is quite tight, especially if some higher risk items are not implemented as scheduled, a second daily is a good opportunity to check the progress and to plan redistribution of capacity or to have information on the items that cannot be delivered as early as possible. This is to communicate the issues to the product owner. It is very important for the off-site part of the team, since they have to propagate any impediments from their side to the rest of the team as soon as possible. Since two parts are in distant locations, it may happen that impediments are not communicated on time. Regarding the format of the second daily, we use the same as for the regular one.
One of our teams even has an “after daily” meeting:
After the daily, once in a while, we even have a short coffee break to chat about a topic which is interesting for the whole team.
In the next part we are continuing with other sprint meetings.