Tips for Virtual Daily Scrums

I will discuss Tips for Virtual Daily Scrums in this article Remote work is now common for many Agile teams. This makes virtual Daily Scrums, or standups, vital for teamwork. However, doing your daily Scrum remotely brings unique challenges. Some of those can be, time zone issues and keeping people engaged. Here are practical tips designed to help your remote Daily Scrum be productive and follow Agile principles. To read more about techniques that can help any Daily Scrum please use this article.

Keep it Short

A Daily Scrum should last no more than 15 minutes. In a remote setting, it’s easy to lose track of time. To stay efficient:

• Use a timer to signal when time is up.
• Ask team members to be brief and focus on key updates.
• Move detailed discussions to a separate meeting after the Daily Scrum.
• Encourage team members to come prepared

Encourage Asynchronous updates

Not all updates need to be done in one single meeting. It helps if the team updates their regular activities in an asynchronous manner. Some examples of such updates can be updates via team WhatsApp /slack channel or via the Project Tracking tool like JIRA/Trello or ADO. One point to keep in mind is to share the information only via secured approved channels Some of the benefits can be

• Cater to Different Work Styles and Time Zones
• Provide Context and Detail
• Create a Documented Record of Progress
• Focus Live Standups on Discussion and Problem-Solving
• Offer Flexibility and Choice

Choose the Right Tools

Good collaboration tools help ensure a smooth experience for participants. Consider these areas for tools:

• Video Calls: Zoom, Microsoft Teams, or Google Meet.
• Asynchronous Check-ins: Jira status / team slack or MS team channels
• Virtual Collaboration Tools: Miro or MURAL for visual collaboration. Even a shared presentation or sheet works
• Time Zone Coordination: a global calendar

Make sure everyone knows how to use the tools and that they work well.

Set Clear Meeting Rules

Remote meetings can get messy without clear rules. So, set ground rules, such as:

• Turn on cameras for better engagement (if possible).
• Mute mics when not speaking.
• Avoid multitasking during the standup.
• Use hand raising or chat for organized speaking turns.

Respect Time Zones and Cultures

Distributed teams often span different time zones. To address this:

• Rotate meeting times to share the burden.
• Use asynchronous updates for teams in far time zones.
• Foster a culture of empathy and flexibility.

 Keep it Lively

Virtual meetings can be dull. So, keep energy levels high:

• Start with an icebreaker or a fun question.
• Use GIFs or emojis in the chat.
• Celebrate small wins and achievements.

Interactive meetings improve participation and morale.

 Review and Adjust

Continuous improvement is vital for Agile success. Regularly ask the team:

• Is the Daily Scrum working well?
• What changes are needed?
• What improvements can we try?

Gather feedback and try new formats to optimize remote standups. In summary, remote Daily Scrums are crucial for distributed Agile teams. By setting clear rules, using the right tools, and keeping people engaged, teams can make their standups valuable for collaboration. Try these tips, adjust as needed, and keep improving your approach.    

The post Tips for Virtual Daily Scrums appeared first on World Of Agile.

Common Misconceptions

Most people consider Daily Scrum is presumed to be a Status Meeting where Scrum Master takes status from the teams. One of the most common reasons for this is because people have used Project Manager as an entity for years and assume that Scrum Master is a renaming of Project Manager role and Daily Scrum to be a new name for “Status Meeting”.

What is Daily Scrum Really?

• Daily Scrum is not a Status Meeting. Daily Scrum is a inspect-adapt forum for the Developers to make a plan for next 24-48 hours by checking if the Sprint Goal is being met or not
• Developers sync up daily so that the plan for next 24-48 hours is effectively done
• Updating the Sprint Backlog should be the main goal of the Daily Scrum. This optimizes the probability of meeting the Sprint Goal
• Daily Scrum is a effective forum for improving communication and collaborations between Developers

Recommendation about Scrum Master’s Role in Daily Scrum

• Scrum Master may facilitate the Daily Scrum to ensure it gets over in 15 minutes and people do not make it a detailed discussion forum. However, Scrum Master is not considered the compulsory participant of Daily Scrum.
• Scrum Master’s role is to make the team independent and help them becoming self-managed team. Therefore, Scrum Master should teach the Developers to run the Daily Scrum effectively by doing a quick sync up and updating the Sprint Backlog
• Once the team becomes self-managed and know how to get the Daily Scrum completed within 15 minutes, Scrum Master should change his/her stance to an observer stance. That means the team has to talk to each other without Scrum Master’s intervention
• Scrum Master should teach the Developers to keep the status transparent through various tools and techniques such as Burn Up Charts, Burn Down Charts, Scrum Boards. This avoids a lot of wasteful status discussions in the Daily Scrum
• Once the Scrum Master feels that the Developers are managing on their own, the Scrum Master should purposely skip a couple of Daily Scrum and find out if the Developers still keeps doing the Daily Scrum on their own. If the Developers also skip the Daily Scrum, just because the Scrum Master was not there, then Scrum Master should treat this as an opportunity to coach the team again
• If Scrum Master notices that Product Owner is conducting reviews of Product during the Daily Scrum, then, Scrum Master should coach the PO not to do it and create another forum where the review of the product could be done
• Similarly, if Scrum Master notices that the line managers are wasting the time of Developers by taking status, then Scrum Master must intervene and prevent the line managers from doing this
• Sometimes, one of the Developers wastes a lot of time of others during the Daily Scrum trying to dominate the forum by showing off on his/her skills. Scrum Master’s job to facilitate and ensure that everyone gets equal chance during Daily Scrum. There are many facilitation techniques which could be used. For example, tossing the ball every 60 seconds to the next person to speak, introducing friendly penalties (buying a drink for everyone, doing 10 push-ups) for exceeding the time allocated to speak etc.

Conclusion

Thus, Scrum Master is not a mandatory participant of Daily Scrum. “Not Mandatory” does not mean that Scrum Master is always Absent in Daily Scrum. Scrum Master’s role is to make the team independent so that they can manage the Daily Scrum to inspect and adapt and optimize the probability of meeting the Sprint Goal. Once the team becomes independent, it is better for the Scrum Master to take a step back and take observer position.

The post Myth – Scrum Master being the Mandatory participant of Daily Scrum appeared first on World Of Agile.

It is a common mis-conception that Scrum is only useful for small projects.

The real fact is that Scrum is used for solving complex problems. Complex problem is a problem where there are “unknowns” about requirements or the solution.

For solving complex problems, the decisions have to be taken based on what has been done in the recent past. It is extremely difficult to base your decisions based on long-term assumptions. This way of solving problems is called Empiricism or Empirical process control. Scrum is a framework based on Empirical Process Control Theory and therefore, used for solving complex problems.

A complex problem may be big or small. Therefore, the size of the problem has nothing to do with usage of Scrum or other frameworks/methods. A few examples of massive complex problems

• Merger or separation of a bank – When two banks merge or separate, there are a lot of unknown factors on the products in the resultant merged or separated bank. For example, one bank may be a risk-taking bank have an investment product based on a mix of equity, commodities, and derivatives, whereas, second bank might have a more conservative approach based on fixed-deposits, company-fixed-deposits of blue-chip companies and debt market involving only government securities. Now what would be the product applicable for the new merged bank? Would both products be offered by the new bank or would they be another combination product, or if the merged bank carries the image of the conservative bank then should it even offer the risky product? There are a lot of unknowns here. Would the image of a new merged bank be conservative or risk taking? Would the customers of the risk-taking bank accept the conservative products? Would the customers of the conservative bank accept the risky products or accept a risky profile of the new merged bank? This is an example of an unknown scenario. Unless things are tried out, there is no way you could take decisions. As a business, you may try various combinations, but the answers are possible only after trying different products and taking feedback from customers.
• Development of a medicine or vaccine for an unpredictable disease – The whole world grappled with the Covid-19 pandemic in 2020. The solution to solve this problem was two-fold – either develop a vaccine to prevent the disease or develop a medicine to kill the virus if anyone gets infected. Both were big unknowns. How the infections spread was unpredictable and also how the disease affects the patients was also unpredictable. Scientists and researchers had no option but to use the trial-and-error approach based on the past knowledge of various viruses. However, the majority of the decisions were based on what was the result of the trails done on various animals and eventually on human beings. Again a complex problem where decision can only be taken based on what has been done in the recent past. The decisions cannot be taken based on long-term planning.

Naturally, the approach for solving these kinds of problems is to shorten your planning horizons, try out things, if things do not work then try something else, if things work then try something else to make the solution stronger. So isn’t Scrum a way of solving such problems? Scrum shortens the planning horizon to maximum one month, then uses the inspect-adapt cycles (at the bare-minimum) through Sprint Reviews, Daily Scrums and Sprint Planning. The implementation of the Product Backlog is in-fact a way of adapting the requirements as you move forward and as more is known about the problem you are solving.

Therefore, it is a myth that Scrum is for small projects.

Conclusion

The size of the project has nothing to do with the use of Scrum or not.

• Scrum is based on Empirical Process Control Theory.  Empiricism asserts that knowledge comes from experience and making decisions based on what is observed.
• Scrum combines four formal events (Sprint Planning, Daily Scrum, Sprint Review and Sprint Retrospective within a containing event, the Sprint) and three Artifacts (Product Backlog, Sprint Backlog and Increment) to implement empiricism. These events work because they implement the empiricism pillars of transparency, inspection, and adaptation.
• Thus, Scrum is being used for solving complex problems (unknown requirements or unknown solutions) for small as well as large projects where constant inspection and adaptation is necessary and decisions have to be taken based on what is observed. Scrum Team observes what is happening based on the feedback received and adapts to the changes.

The post Myth about Scrum only being useful for small projects appeared first on World Of Agile.

Common Misconceptions and Negative implications

Most teams conduct Daily scrum as a status meeting. When this happens, following negative implications result

• Developers start thinking that this is Scrum Master’s forum
• Developers don’t take accountability
• Developers lose interest and start saying “there is nothing to status report every day”

Recommendations:

• Primary intention of Daily Scrum is to Inspect and Adapt. This is supposed to be a forum where the Developers finds out if things are going in the right direction. If they are not, then it is time to discuss the same and adapt as soon as possible. If required, the scope needs to be adjusted, decisions need to be taken so that the Developers comes back on track.
• It is good to keep the “Sprint Goal” at the centre when the Daily Scrum discussions are on. This is not about day-to-day tasks. This event is about knowing if we will be meeting the “Sprint Goal” or the business objective.
• Daily Scrum should be an opportunity for the Scrum Master to help the team become self managed.
• The three questions (while they are not compulsory in Scrum) actually are mis-understood by most teams. The three questions are not about “What did you do?”, “What are you going to do?”, “What are your impediments?”. The tree questions are about Sprint Goal and not about what tasks you are doing . So the correct 3 questions are

1. What did I do yesterday that helped the Developers meet the Sprint Goal?
2. What will I do today to help the Developers meet the Sprint Goal?
3. Do I see any impediment that prevents me or the Developers from meeting the Sprint Goal?

• Daily Scrum is also an important opportunity for collaboration for the Developers. Scrum Master is actually a facilitator in this forum. Scrum Master’s job is to make sure
  • The Daily Scrum happens
  • Negative things which happen regularly are prevented
  • To make sure that it finishes off on time within 15 minutes and teams are free to go back to work.
• The only mandatory participants of Daily Scrum therefore are the Developers members and not Scrum Master and Product Owner. PO if at all joins,  his presence is limited to clarifying scope. 

The post Myth about Daily Scrum being a status meeting appeared first on World Of Agile.

The 3-Question format is the most popular format for Daily Scrum. The 3 questions focus on 3 things

1. What did I do yesterday which helped the team get closer to the sprint goal?
2. What will I do today which will help the team get closer to the Sprint Goal?
3. Are there any impediments which will prevent my team to get closer to the Sprint Goal?

While the first part of the question is very clear on what I did, what will I do and are there any impediments, there are some points I would like to make with respect to the second part of the question – i.e. about the goal.

• It is very important that the Developers understands what is the purpose of Daily Scrum. The purpose is NOT to give status to Scrum Master or to the senior-most in the team. The purpose is to prepare a plan for next 24 hours. If the purpose is plan, then the objective to achieve the Sprint Goal takes a paramount importance.
• When the Developers thinks about the Goal all the time, the focus changes from just the activities to achieving the Sprint Goal.

So the 3-Question format has all the ingredients required to make the Daily Scrum effective and many teams have been using this to their advantage. However, the Developers miss out is on few of the following things when they change the format to a plain discussion format.

• They keep reporting the status – as if the accountability is of the Scrum Master and not theirs.
• They don’t keep the goal in front and keep discussing the activities
• They keep discussing the details instead of focusing on keeping the discussions short and sweet. You can always discuss details later
• They don’t have the updated Sprint Backlog in front when they are discussing
• They don’t get to the plan for the next 24 hours and just spend 15 minutes “talking something”

To summarize, it is not necessary to do the Daily Scrum in the 3-Question format. Development can choose any format that they want. However, the essence of the Daily Scrum must not be lost in trying to change the format of Daily Scrum to a plain discussion format.

The post Is the 3-Question format compulsory in Daily Scrum? appeared first on World Of Agile.

Daily Scrum is an event for the Developers of the Scrum team to communicate, collaborate, inspect and adapt towards the product goal and optimize the probability of meeting the Sprint Goal.

Developers are the only mandatory participants of the Daily scrum. Scrum Master and Product Owner are mandatory only if they also play the Developer accountability in the day-to-day work.

Constraints set on Daily Scrum by the Scrum Guide

Daily Scrum is NOT a status meeting

Daily Scrum is NOT a status meeting. This is a coordination and planning opportunity for the developers to prepare a plan for the next 24 hours. During the Daily Scrum, the central aspect is the Sprint Backlog. The developers evolve the Sprint Backlog by making sure that the updates are done to the Sprint Backlog which optimizes the probability of meeting the Sprint Goal. The status is infact an input to daily scrum. The developers usually use tools and techniques such as burn-down charts, burn-up charts, scrum boards to display the status visibility. These become input for discussions during the Daily Scrum and not really discussed in detail.

Maximum 15 minutes

The constraint set on the Daily Scrum is that it should not exceed 15 minutes regardless of the length of the sprint. Such a constraint exists because Daily Scrum should be detailed status meeting and should be a quick meeting to communicate and collaborate, identify blockers and optimize the probability of meeting the Sprint Goal.

Developers are the only compulsory participants of Daily Scrum

This is not a Scrum Master’s forum to take status. Neither is it for a Product Owner to conduct a product demo. This is an opportunity for developers to connect every single day to optimize the plan for the next 24 hours. This constraint is also put up so that the developers get into a habit of “self management”. The developers know that Scum Master is not going to allocate any work to them. It is up to the developers to allocate and monitor their own work.

Daily Scrum should be done at the same place and same time every day

Daily Scrum’s intent should be to increase the cadence on a daily basis. The “same place and same time” constraint is set so that the developers have a regularity of communicating, connecting and making sure they fine-tune the day-to-day plan and optimize the probability to meet the Sprint Goal

Handling Daily Scrums – Few suggestions

• Using the 3 questions effectively in a round-robin format: The Three question format which were there in the Scrum Guide prior to 2020 were a guidance and never compulsory. However, they became a de-facto standard for daily scrum throughout the world. However, the three-question format was widely misunderstood. Most people truncated the questions (by forgetting the “Sprint Goal” part of the questions) and naturally they became questions to be asked by the Scrum Master. The real questions (in the earlier version of Scrum Guide) were about the Spint Goal. The tone of the Three-questions should be as follows
  • What did you do yesterday, which helped you and your team come closer to the Sprint Goal?
  • What will you do today, which will help you and your team come closer to the Sprint Goal?
  • What are the impediments, which are hold you up from meeting the Sprint Goal?
• Identifying blockers: The focus of the Daily Scrum should be to identify impediments so that they can be resolved. Listing them down as a list and tracking it every Daily Scrum could be a good idea. It would be a better idea to have those who have impediments speak first instead of going round robin.
• Detailed discussions should be done after the Daily Scrum : The developers should avoid doing detailed discussions in the Daily Scrum. The developers should meet after the Daily Scrum to discuss the details.
• Face to face: Daily Scrum should have all the developers face to face. Face to face does not mean co-located. It is now a norm to be working remotely either from home or from different locations. “Face to face” can be achieved with video calls with cameras ON. It is better that developers communicate either via video calls such as zoom calls or meet in person
• Facilitation by Scrum Master or anyone else: If the environment is very chaotic or in a multi-geography or multi-cultural environment, it would be better if an official facilitator can be appointed to make sure Daily scrum becomes optimal.
• Scrum Master to be present if the team is immature: In the initial days when the Developers do not know how to make this event fruitful, the Scrum Master should be present to teach the team on how to conduct Daily Scrum
• Everyone Stands during Daily Scrum : This is another format which people use to keep the Daily Scrum short. All the team members stand up and talk so that it keeps reminding them that they need to go back to work quickly.
•  

The post Daily Scrum appeared first on World Of Agile.

Scrum Events are mandatory opportunities given by Scrum to Inspect and Adapt. The reason they are mandatory is that Scrum is a inspect-adapt way of solving complex adaptive problems. If we do not use the minimum opportunities then a fundamental aspect of Scrum is compromised. These events are specifically designed to enable critical transparency and inspection. Failure to include any of these events results in reduced transparency and is a lost opportunity to inspect and adapt.

Scrum Events create regularity and minimize the need for meetings not defined in Scrum. All events are time-boxed events, such that every event has a maximum duration. Once a Sprint begins, its duration is fixed and cannot be shortened or lengthened. The remaining events may end whenever the purpose of the event is achieved, ensuring an appropriate amount of time is spent without allowing waste in the process.

There are 5 Events in Scrum

• Sprint – which is container of all the other events
• Sprint Planning
• Daily Scrum
• Sprint Review
• Sprint Retrospective

Following is the summarization of all events

The post Scrum Events appeared first on World Of Agile.

Did you know that the concept of Daily Stand-up meeting was there long back in the manufacturing world much before we IT guys were even born?? It was called Short Interval Management (SIM) and has Japanese roots.

Short Interval Management is a shop floor exercise that engages team members to assess whether they are still on track. The term “Short Interval” means many times in a day as required to solve problems. One of the key component of SIM is the regular “Daily StandUp meeting” which is held at the same time at the same place every day. The meeting is always held on the Shop Floor (“Gemba”) instead of in conference rooms. The other standup meetings during the day are called just “Stand-up meetings”.

The meetings focus on 2 key elements “Looking Back” and “Looking forward”. (Remember the “What did I do yesterday? What will I do today? Do I have any impediments” of Daily Standup in Scrum?)

The post Short Interval Management (SIM) appeared first on World Of Agile.