Alternative to the "3 Questions"

The Daily Scrum isn't for talking about what the team accomplished or what they are proud of. The team can talk about these things at the Sprint Review and/or Sprint Retrospective, as appropriate.

The Daily Scrum is for checking and revising the plan to accomplish the Sprint Goal. Assuming that the team has a set of Product Backlog Items that are well aligned with the Sprint Goal, the question becomes how to get those Product Backlog Items to done. If the team has a board (and many teams do), then "walking the board" from right to left (where right is "done" and left is "to do") and figuring out how to get the tasks or PBIs into the next workflow state (or closer to being done) is one of the most efficient techniques that I've seen.

Why would a Scrum Master be asking any questions at the Daily Scrum? : )

Agreed, the three infamous questions are no longer prescribed. Although I am in the camp that is glad they were removed, many forget what three words the three questions ended in: the Sprint Goal.

If your team is not using a Sprint Goal, I suggest starting there - it isn't an optional piece of Scrum yet so many leave it out. Having a shared purpose is known to be one of the intrinsic motivators of knowledge workers, which we can relate back to goals. Every element of Scrum serves empiricism, and the Daily Scrum is no exception. A Sprint Goal focuses on value. It unites a team and gives them a reason to celebrate at the end of the Sprint.

Then teach everyone about the purpose of this event: Developers inspect their progress towards the Sprint Goal and adapt their plan for the next 24 hours. The plan is their Sprint Backlog. In other words, the Daily is a planning meeting for the Developers. No one else. Scrum Masters and product Owners are optional.

Once the Developers understand the purpose, take it to the team and ask them for ways they want to run this planning event without your facilitation. Trust in the self-managing capabilities of the Developers rather than provide them the answer. This is a great place to take off the self-management training wheels.

Step back as a Scrum Master and observe. If things need to be adjusted, reveal that in the Sprint Retrospective.

All the best!

Coaching the Developers to walk the board and come up with a plan for the next 24 hours is indeed more likely to prove helpful. Otherwise, the only thing a Scrum Master ought to be doing at their Daily Scrum is edging closer to the door.

How do you engage your team and get them excited to participate in the scrum? How do you get them to divulge what they've accomplished, what they're proud of, what they need help with? 

Short answer is I help them understand the real benefit of using a short timebox to plan and then let them do it all by themselves.

The first thing I always tell my teams is that I will show up to the Daily Scrum from time to time to observe.  I make it clear to them that the event is their own for the purpose of coordinating the work they will use to accomplish the Sprint Goal.  They can decide how they want to use that time.  I remind them that the event is supposed to no more than 15 minutes in length and used solely to adapt their plans for accomplishing the work. 

I will show up for most of the Daily Scrums in the beginning to "nudge" them to stay on the right track.  But then I start to pull away. After the developers are working well together, I may show up for 1 Daily Scrum a month.

What most of the teams have done is use the 15 minutes to discuss anything that came up the previous 24 hours that could impact their work.  There are no specific questions, just "anyone have something that we all need to know?".  They spend their event time discussing that and making sure everyone knows what the others are going to be working on until the next time that they meet.  Often they will "table" some discussions for after the timebox if they feel that they need to have longer discussions and the people that would be interested can attend while others can go about their work. 

@Lauren Wright, I can relate to your situation.

The purpose of the Daily Scrum is to inspect progress towards the Sprint Goal. Therefore, something as simple as taking a confidence vote by asking "Are we still good to achieve our Sprint Goal?" should suffice. The discussions that organically follow should allow the Developers to plan accordingly to ensure that they can commit to meeting the Sprint Goal.

Also, the Scrum Master doesn't have to ask the question(s). You can teach them how to do it or even suggest it as an approach. The more important thing is for everyone to be aligned on what the purpose of the event is and giving them the freedom to be creative from there.

"The purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work.

...The Daily Scrum is a 15-minute event .. same time and place every working day of the Sprint.

...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."

- 2020 Scrum Guide.

So nothing in the Scrum Guide about the three questions that were invented by an Agile coach and widely adopted.  Likely for its simplicity and structure to focus on the Sprint goal.  The issue many teams, including some of my own, has been to treat the event as a routine and default to a status meeting where not much useful information is shared in terms of things affecting the sprint goal.  I see the issue as either apathy towards Scrum, Devs not properly exposed to what is expected, and the lack of intent to share important information with peers.  Intent in any Scrum event is needed for such events to result in their intended purpose.  So the issue in my opinion is not the 3 question format, though I do not object to new approaches or experimentation.  Teams need to really grasp the purpose of Daily Scrum and our role as Scrum Masters is to guide teams to focus on on sharing relevant information on how their progress to meet Sprint goals, and any related issues to the team.  One of my early smaller teams that were all onsite were able to simply report where they are in terms of the Sprint goal and quickly share important insights or impediments in free form--no 3 Qs.  It worked for them.  Not as easy to pull off with large remote global teams.

So ...

1. Stop asking the questions, you should not talk or even be there every day. Let them figure it out.

2. If everyone works alone, make sure people work together instead

3. you need (2) before there will actually be real conversation

4. you could try the "Walk the board"-technique, and mostly talk about how items on the right of the board can be finished. And see who can help achieve that as soon as possible.