Same client but multiple teams. One stand-up or smaller stand-ups?

Since you have your PSM1 certification, I'm sure this will be a refresher for you. But you asked so I'll give you my opinion.

1. In the Scrum Guide, it states this about the Daily Scrum

The Daily Scrum is a 15-minute event for the Developers of the Scrum Team. To reduce complexity, it is held at the same time and place every working day of the Sprint. If the Product Owner or Scrum Master are actively working on items in the Sprint Backlog, they participate as Developers.

The Developers can select whatever structure and techniques they want, as long as their Daily Scrum focuses on progress toward the Sprint Goal and produces an actionable plan for the next day of work. This creates focus and improves self-management.

The Product Owner and Scrum Master can attend the Daily Scrum if the Developers are ok with it, but they should not interrupt or provide any updates.  They would be observers only.

2. As indicated above, the Daily Scrum is for the Developers.  The purpose is to discuss the progress towards the Sprint Goal and to plan their activities for the day to further their ability to achieve the Sprint Goal.  



Unless all of your teams are working towards the same Sprint Goal and working from the same Sprint Backlog, I do not see that combining them all into one event would be beneficial.  I will point out this statement from the Scrum Guide

The fundamental unit of Scrum is a small team of people, a Scrum Team. The Scrum Team consists of one Scrum Master, one Product Owner, and Developers. Within a Scrum Team, there are no sub-teams or hierarchies. It is a cohesive unit of professionals focused on one objective at a time, the Product Goal.

A Product Owner and Scrum Master can work with multiple teams but that does not mean that combining the Scrum Events is a good idea. 

Do you guys agree that PO should be optional for stand-ups

The Product Owner has all the rest of the working day to collaborate with the Developers. Why does he or she wish to be there in precisely those 15 minutes which are meant for the Developers to stand aside and refocus themselves?

We have a client with 3 different projects.  1. Data platform (2-3 resources). 2. Web (4-5). 3. Power Bi (1)

How many products are there? If the most important project isn't the Sprint which all team members collaborate on, why not?

Would you keep these separate or combine them into 1 stand-up and break out in separate meetings for non stand-up related convos? 

It sounds as though collaborative activities are exceptional and must be planned as meetings. Why?

RE: Daniel - "A Product Owner and Scrum Master can work with multiple teams but that does not mean that combining the Scrum Events is a good idea." That's good to know.  I should have given more context to this as well.  We have a strict budget for PO (Scrum M)/ PM (15h a week per SOW).  Yet they have 1.5 hrs blocked for stand-ups for 3 separate projects.  They use first 15m of each block for stand-up and use the rest to go over any questions or any other sync.  I suggested combining all 3 into 1, to reduce their time in meetings, so they can get more work done outside of meetings.  Also keep in mind there's weekly client calls, sprint planning prep, sprint planning / retro so they need to be very efficient with their time.  I understand that stand-ups should be for devs only but due to the nature of company (agency), it's pretty important that scrum master is present and lead - especially because some teams are new to scrum.  Any additional thoughts on combining meeting now that you know this? 

RE: Ian

"The Product Owner has all the rest of the working day to collaborate with the Developers. Why does he or she wish to be there in precisely those 15 minutes which are meant for the Developers to stand aside and refocus themselves?" Because we have some PO's at our agency where they want to be top of everything and per above, time / budget is limited for PO / PM. 

How many products are there? If the most important project isn't the Sprint which all team members collaborate on, why not? - 3 products. 

"It sounds as though collaborative activities are exceptional and must be planned as meetings. Why?" - That's what the PO prefers.  We have some PO's that always want the ball, want to use time after stand-ups to go over anything else like scope, questions, etc, and to be frank, they don't know how to not let the scrum master and team run the sprints. 

Actually my opinion has not changed after you gave new information.  However, I have added to that opinion.  The "strict budget" makes me question whether the organization is actually committed to using the Scrum framework and to be agile at all.  This seems very micromanaged and procedure heavy.   Those kind of "budgets" do not allow for the ability to adapt to new information.  What if Product A is suddenly faced with some legislation that requires a lot of Product Owner involvement while Product B is business as usual.  Your statement indicates that the Product Owner has to spend 15h on each.  What if a product does not require 15h of their time? 

Your response to @Ian indicates that the Product Owner's organization is not willing to allow or is willing to trust the rest of the Scrum Team to self-organize.  I see a very command-control culture in place.  

I see a lot of opportunity for the Scrum Masters in your organization to fulfill some of the responsibilities for which they are accountable.  From the Scrum Guide, emphasis added by me:

Scrum Masters are true leaders who serve the Scrum Team and the larger organization.

The Scrum Master serves the Scrum Team in several ways, including:

• Coaching the team members in self-management and cross-functionality;

• Helping the Scrum Team focus on creating high-value Increments that meet the Definition of Done;

• Causing the removal of impediments to the Scrum Team’s progress; and,

• Ensuring that all Scrum events take place and are positive, productive, and kept within the timebox.

The Scrum Master serves the Product Owner in several ways, including:

• Helping find techniques for effective Product Goal definition and Product Backlog management;

• Helping the Scrum Team understand the need for clear and concise Product Backlog items;

• Helping establish empirical product planning for a complex environment; and,

• Facilitating stakeholder collaboration as requested or needed.

The Scrum Master serves the organization in several ways, including:

• Leading, training, and coaching the organization in its Scrum adoption;

• Planning and advising Scrum implementations within the organization;

• Helping employees and stakeholders understand and enact an empirical approach for complex work; and,

• Removing barriers between stakeholders and Scrum Teams.

Your organization is using terms from the Scrum framework.  They may even be using some of the events and artifacts from the Scrum framework for their intended purpose.  But it does not sound like the Scrum framework is being used for the purposes intended. Again from the Scrum Guide

Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems.

In a nutshell, Scrum requires a Scrum Master to foster an environment where:

1. A Product Owner orders the work for a complex problem into a Product Backlog.

2. The Scrum Team turns a selection of the work into an Increment of value during a Sprint.

3. The Scrum Team and its stakeholders inspect the results and adjust for the next Sprint.

4. Repeat

And one more statement from the Scrum Guide to wrap up this post. 

Scrum is free and offered in this Guide. The Scrum framework, as outlined herein, is immutable. While implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices.

To paraphrase, just because you use the words does not mean you are benefiting from the Scrum framework. 

RE: "What if Product A is suddenly faced with some legislation that requires a lot of Product Owner involvement while Product B is business as usual." Great question. We do whatever is necessary to get the user stories created in Devops and take the hit on budget.  

Thank you for the link to the guide.  I am sharing it with our team.