There's a lot going on here, as evidenced by the length of many earlier answers. I'll try not to duplicate them too much, but some overlap is inevitable.
The most important thing to say is that Scrum is a technique to help great teams. It will not magically turn a mediocre team into a great one, and in particular, it won't automatically cause a group of individuals to become a team.
The situation described does sound like you have a bunch of developers that have not learned to work together as a team, and have not been provided with any guidance or coaching to help them towards that state.
There's an assumption that having "something to report" at Stand-Up is important. That might be exacerbated by having line-management present in the meeting, and wanting to demonstrate individual productivity. When Scrum is implemented well, the best thing to be able to say is very short, such as, "I'm on track with what I committed to, and expect to finish it tomorrow." Reporting tickets moved is pointless, because that's already done by the team's information radiators (sprint board, build/test monitors, etc)
What can you do, as a Scrum Master or other team member?
Read The Five Dysfunctions of a Team by Patrick Lencioni. I enjoyed the Manga Edition, despite having no other graphic novels on my shelf; it was a nice change from traditional formats. This book is the best explanation I've found of how high-performing individuals can undermine each other's efforts rather than working together and supporting each other. And, importantly, what you can do to help.
Share the book with your allies - other team members feeling the same frustrations and wanting to do something about it.
Speak up in your Retrospective. And make sure that the actions you agree in Retrospective actually happen - perhaps by volunteering yourself. I find it helps if Retro actions can be written as tickets so they can be prioritised and tracked along with the project work (remember that the Team owns the sprint backlog, unlike the product backlog owned by the PO).
Use the Daily Stand-Up for its intended purpose (coordinating, not reporting), and gently guide other team members in the same direction. Good questions include:
- "Who needs this level of detail? Can you discuss with them outside of Stand-Up?"
- "Is that something I can help with?"
- "How does that affect whether we'll achieve the Sprint Goal?"
- "Can we get together to develop the tests without having to wait for the implementation to be completed?"
Remember that the Stand-Up is the backstop for uncovering problems. If something you say comes as a surprise to other team members, think how you could have shared it earlier with the people affected.
Lead by example in asking for help. This is a demonstration of trust in your team members, and you're likely to find this reciprocated when others could use your help in the areas where you are the expert.
What can you do, as a Line Manager?
I don't have direct experience here, but do have observations of behaviours I've seen with successful teams. My suggestions should be considered as experiments to perform - do them for a sprint or two, then assess whether they worked. If they don't have the desired results, see if you can understand why, and modify them to come up with a new experiment to try.
The Five Dysfunctions of a Team, as mentioned above, is essential reading for someone managing a team that should be working in unison.
Ensure that the Scrum Master is able and empowered to improve team performance. That means providing adequate training, time and incentive to make it all work well. Many managers seem to think that they can simply nominate one of the developers to also be Scrum Master and that's enough. Similarly, many nominal "scrum masters" are also expected to be full-time developers, so can't do more than the bare minimum of ensuring that the Scrum ceremonies take place.
Stand back from watching (or worse, interfering in) the team meetings. You don't need to be at the Stand-Up, and almost certainly should not be at Retrospective. These meetings need to be safe environments for the participants to speak the unvarnished truth, and your presence is likely inhibiting that, consciously or otherwise. If you need updates on progress, you should be able to get that information from the team's information radiators, and consult with the Product Owner for any clarifications or for the "gut feel" on the Sprint Goal.
Reward team achievements, not individual ones. If developers are incentivised to put "their" tickets ahead of other ones, that means that time contributing to anything else is seen as a drain on their efforts. Work with the Scrum Master to foster a culture where the name on the ticket can be seen as the coordinator and "go-to person" for that work, not necessarily the sole contributor. In any case, make it clear that you don't see "tickets completed" as indicating the worth of a developer.
Make it clear that you value predictability more than velocity. Your customers (internal and external) are more upset when a feature that they were promised doesn't appear than when they are told well in advance that it's not achievable in combination with their other features. Velocity probably will increase eventually, but not until the team is consistently delivering their commitments, sprint after sprint.
A good team will hold each other accountable for their commitments to each other, and for the team's commitments to its stakeholders - and it's the team's delivery that you need to care about. Of course, a group of developers that is still becoming a team won't yet have that culture of accountability, but that's not something you can impose. Instead, work with the Scrum Master to develop the team in that direction, and be prepared for this experiment to take several sprints to get where it needs to be.
User your regular conversations with each team member (you are having these, right?) to understand their contributions better, and be sure to recognise achievements that aren't visible on the information radiators, such as sharing knowledge to help other team members or improving the product architecture to make upcoming work easier. This is also your opportunity to pick up on personality conflicts within the team and help the developers understand them and work towards resolving them. And it's a good time to help the developers understand where their peers' strengths and interests lie, which helps them know who they can ask or offer help to combine relevant expertise.