Daily scrum meetings

Hi Jason - Here's some advice that I hope you will take to heart. 

• Investigate the Sprint Goal, and it will help your team with FOCUS in the Daily Scrum.  The three optional questions mentioned in the Scrum Guide (what I worked on yesterday, what I worked on today, what impediments do I have), all end in?  The Development Team is updating each other on an update of progress towards the Sprint Goal.  The Sprint Goal is your Development Team's north star, which can give them laser focus, if used properly.
• Your Scrum Master should teach the Development Team to keep the Daily to within 15 minutes.  Ask yourself why 15 minutes and not an hour?  Time-boxing is a gift - use it!
• The Daily Scrum is first and foremost for the Development Team.  Anyone else, including the Scrum Master and Product Owner, is OPTIONAL.   This is where we take the training wheels off around self-organization, and where the Scrum Master turns the Daily Scrum over to the Development Team to run.  This is their meeting, their time to focus on what the most important work is to meet...the Sprint Goal.

Instead of focusing on PROJECTS, try to focus the team on one PRODUCT.  One Product per Product Backlog.  Without that your Scrum Team will be challenged to come up with a Sprint Goal.  Notice I didn't type SPRINT GOALS, it is singular.  That will give your team the deserved focus they need.

You are correct, multi-tasking is an enemy of focus and productivity.  Two words: Spring Goal!

Did I answer your question?

Scrum on!

@Chris,

If a team wants to be agile but cannot focus on a single product as in the case of the teams I deal with, what is their solution? 

Let me elaborate on our situation; our team is a middle layer team, multiple departments or functions within our organization use our APIs or services to retrieve info from other source systems. We have at best taken ownership of several similar APIs and divided ourselves into multiple scrum teams, even then, we cannot say that we have a single product, as our services could be considered our product(s). If we were to form individual teams for each web service, we would need several 100 scrum teams. Now, we want to be agile, our upper management has asked to use scrum. Our sprints are currently done with the goal of meeting project deadlines or release dates. So for ex: multiple project teams have asked us to integrate their applications with our APIs, We identify when they want these to be released and then we group all the projects that we've accepted based on the release date. So in this case lets say we have 6 projects utilizing several of our services and all these projects want to go live in December. How do we/Can we formulate a sprint goal? Does it mean we cannot start work on projects for January or February the next year?

In our specific situation, what would you advice we do?

I believe this is the reality of many teams on the ground and they follow many absurd practices in order to be on the "Agile" bandwagon. What really happens is, every organization has their own flavor and way of executing scrum or calling something that is not scrum, scrum.

Now, we want to be agile, our upper management has asked to use scrum. Our sprints are currently done with the goal of meeting project deadlines or release dates.

That's a very common situation to find yourself in. Do you think that meeting project deadlines or release dates is a good reason to adopt Scrum though?

thanks Chris 

To elaborate more, we have 3 products. Essentially, different applications... there is some integration but essentially they are three different things.

Each product has its own backlog which is managed by JIRA. There are people working on multiple products at the same time. 

Whats happening is that essentially we have an hour long meeting a day to discuss the backlog and progress for all products/ backlogs. With a lot of people joining these calls.

My opinion is that we should 

- for each product, identity high priority items first and then define a sprint for each product 

- try and have dedicated people working on each sprint (to avoid people working on too many items at once) 

- have three separate meetings for 15 mins each day for each sprint 

What think and any other suggestions?

Whats happening is that essentially we have an hour long meeting a day to discuss the backlog and progress for all products/ backlogs. With a lot of people joining these calls.

My opinion is that we should 

- for each product, identity high priority items first and then define a sprint for each product 

- try and have dedicated people working on each sprint (to avoid people working on too many items at once) 

- have three separate meetings for 15 mins each day for each sprint

Is there a possibility for the team members to self organize into three Scrum Teams, around each product and Product Backlog?  And would there a Product Owner for each product?  The Product Owner would then order the Product Backlog to optimize value of each Scrum Team.

Dedicated Scrum Teams focused on their own product does seem like it would reap benefits and provide focus, I like that idea.

This may help with the ability to form a Sprint Goal, give focus, and cut down your Daily from an hour to 15 minutes.  So yes, each Scrum Team will have separate Daily Scrums for 15 minutes.

Our sprints are currently done with the goal of meeting project deadlines or release dates.

So what if you met all of your deadlines, and no one wanted to use your product.  Would that be a good goal?

So in this case lets say we have 6 projects utilizing several of our services and all these projects want to go live in December. How do we/Can we formulate a sprint goal? 

You won't be able to create a Sprint Goal if your Scrum Team has to support 6 projects with different APIs.  If it was one API that would be different.  This is the challenge with component teams (vs feature teams).  Component teams have to deal with dependencies and integration.  Scrum prefers feature based teams, where a "done" Increment of working software can be created.  

@Chris, In my experience so far I've honestly not seen any team within my organization that adheres to this definition and neither do I see new scrum masters questioning this. This obviously means one of two things, that these scrum masters are not knowledgeable or they just don't want to challenge the status quo that exists in many places. In some of my responses here, I've mentioned that I've interviewed candidates and I was really shocked that their answers to basic questions are far from what is advised in the scrum guide. For example, just as Jason mentions, there is no adherence to a timebox. Things are customized as per the need. 

What do you think is causing people to formulate a sprint goal as achieving a release date? Why is that a collective set of APIs cannot be considered a product? Why is it that if multiple projects call the 'n' APIs (let's call these 'n' APIs our product) that my team owns and we make changes to those specific APIs it cannot be considered a goal. The goal is to enhance these services so that the requirements of the 6 projects are met by the specified release date?

Could you direct me to a resource where I can learn more about Component and Feature teams? The words integration and dependencies are common words I hear on a daily basis :)

Where in the scrum guide does it say that scrum prefers feature teams?

Does it mean component teams cannot use scrum?

In the meantime, I came across this old post 

https://www.scrum.org/forum/scrum-forum/5563/feature-teams-vs-component-teams

>> Where in the scrum guide does it say that scrum prefers feature teams?

It doesn't mention 'functional', but mentions cross-functional.

From the Scrum Guide: The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master. Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team. Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team. 

>> Where in the scrum guide does it say that scrum prefers feature teams?

Sorry meant to say it doesn't mention 'feature' teams.

I believe the Scrum Guide is clear on the need for Feature vs Component teams.

Just a small example from the Scrum Guide:

The purpose of each Sprint is to deliver Increments of potentially releasable functionality that adhere to the Scrum Team’s current definition of "Done".

The goal of each sprint is to create something potentially shippable (and therefore usable) by an end customer.   This also facilitates empirical learnings on whether the Scrum Team is focused on the right thing, and delighting the customer.

Component Teams are not designed around production delivery of customer features; instead, they are remnants of a phased approach (i.e. - waterfall), where work is handed off from one group to another and possessing all of the dependency and integration issues present with such an approach.