Incorrect scrum meeting format not allowing for enough participation from developers

Question

I recently starting working on a project team for a company that is transitioning to Agile methodologies, and that means daily scrum meetings. The scrum masters, however, tend to hold their meeting format by going over task names and asking for progress so they can document it themselves. This leads to a lot of lengthy discussions on those tasks during the scrum between management employees sorting out details about that task while the developers sit and listen. These meetings go over the allotted half hour every single time.

To my best knowledge, the scrum meeting is supposed to be a brisk, 15 minute meeting where each developer answers the following questions:

1. What did I do yesterday?
2. What will I do today?
3. Am I experiencing any blockers?

This should set a progress benchmark for and amongst the developers.

However, these meetings seem to be geared toward bookkeeping for management purposes, and do not give adequate room for developers to set benchmarks amongst each other as the scrum meeting format encourages. Instead, the meeting is conducted by the scrum master listing issue numbers for the task names with the following question:

1. What's the progress on this?

This is generally followed by a discussion which starts as clarification between the scrum master and developer, then ends up as a discussion between management employees trying to sort out details about the relevant story. Because of this, and the nature of multiple developers being assigned to the same task while only one reports on the progress of the task, not all developers are able to participate in the meeting.

Notes to consider before my question:

• I have experienced this issue on multiple teams within my project.
• None of the tasks that my colleagues or I receive on this project are assigned through the issue docs. They are all sent by email, without a reference to an issue number that the scrum master simply lists off during the meeting.
• I am working as a contractor, so I do not have the same leverage as a full time employee of this company would.

My question is, how/who do I approach raising this issue to the project team?

I do not want the scrum master or anyone in management to feel like I am essentially telling them how to do their job, but I also feel that this change needs to happen, as these meetings are very inefficient and ineffective for the developers and multiple members of the development team have expressed similar concerns.

Edit: I should have noted, these meetings are over the phone. We're in around 3-4 different locations total, one of which is not in the US. None of the scrum masters or managers I've had in this project were in my location.

Answer 1

As you stated in your question:

a company that is transitioning to Agile methodologies

I've been working in a company in the same track, the managers hear about the wonderful thinks that Agile provides (mostly the ability to ship faster) and instruct the development team to adopt the methodology. But at the same time, they don't like that the developers spend 15 to 30 minutes every day in scrum meetings.

So maybe the scrum master want to do the meetings as the process says, but their manager want o expect a different result that bends the scrum master into that format of meeting.

Or maybe the scrum master never receive any kind of training (you can read online about implementing scrum but is not easy for everyone to do it).

You can use your position as a contractor (if you have previous experience) to start to make recommendations, no to tell everyone that they are doing it wrong because you don't know the whole picture.

I will talk first to the scrum master in private, to know why the meetings are this way, and then see how can you help (if its possible) without saying that he/she is doing it wrong, maybe you can tell him/her about how you experience the benefits of following the normal format of the meetings in other companies/projects.

Answer 2

You may be in a situation where you just need to have an honest conversation. This can be done tactfully, but it sounds like there are some fundamental parts of Scrum that they do not understand.

No reason to approach it rudely ("You guys suck at this"), but a tactful sharing that there are better ways ("Can I share a way of doing this that I've seen work really well before?") might be the way to go. Sprint Retrospective is an awesome place to bring it up, since that is supposed to focus on improvements to the team working process anyway.

You also mention the problem that Scrum Masters have to report on task progress. This is, of course, problematic. The fact that people come there with needs directly in conflict with the purpose of the meeting creates a structural conflict that has to be resolved in the system (in other words, it isn't a people problem).

Finally, you said that they are in the process of transitioning. There are two things to consider with that fact. First, a lot of transitioning companies actually look for contractors who have experience because it's a way to inject new ideas into the group. You may find them more welcoming of your experience than you expect. Second, they'll be more open to some ideas than others. If you offer a suggestion and they don't take it, hold onto it for later. I can't count the number of teams I've seen fight an idea tooth and nail only to love the same suggestion a few months later.

Answer 3

In my opinion, morning standup meetings are currently the bane of the tech industry for the simple reason that managers (product, project or engineering) turn them into status report meetings. The companies I have been at have all had that problem. Even a brisk 15 minute meeting can turn into a grind when some developer begins droning on: "then I added an api endpoint, then I added a new email, then I added new css...", meanwhile the manager is intently staring at them and nodding their understanding. It is a waste of time, money, and dev sanity.

The underlying problem is that managers are incentivized to get status reports. They have no incentive to properly run a morning scrum meeting.

Since I wouldn't advise you to quit over this, the only answer is to grin and bear it. You can try talking to the managers about this, but you'll likely get, at best, vague promises of change but with likely no real change.