Generally claiming that a person is doing the method wrong when the method brings no percieved benefits raises a red flag on the general applicability and value of the methodology itself on the problem the person is trying to solve.
There is no one true way to organize development of software and generally shoehorning dogma without proof of value is counterproductive.
I think you can absolutely diagnose an hour-long daily standup as "wrong". Standups need to be limited to 10-15 minutes. That's one of the key tenants of standups: they need to be short and focused.
Yes, regardless of the process framework used having the team meet daily for an hour is pathological and probably is indicator of deeper issues. Which just doing agile "more by the book" wont fix.
Are you really can stand for hours at the standup meeting? :-)
Standup daily meeting must be short and focused. Moreover, standup meeting is for developers only. No project manager, no customer, no QA team. Just developers talking about their problems. Everything else deserves it own separate, hour long meeting once a week or two.
Just want to stress the importance of having stand-ups be developer-only. Do not let project managers, product owners, stakeholders, clients, and so forth become part of it. The developers won't be ready to start working when they take their seats because a lot was said in standup without actually saying much.
Eh, it's valid in this case. Ten minutes standup is formulated as being opposed to a full meeting. The full meeting was there first, standups are supposed to be different. If it's turning into the full meeting it's worth calling that out.
I'm sorry, but no, it doesn't. Sometimes people just do things the wrong way, and there's nothing that can be done other than to tell them they're doing things wrong.
> Generally claiming that a person is doing the method wrong when the method brings no perceived benefits raises a red flag on the general applicability and value of the methodology itself
Agree completely. When incredibly common complaints about a methodology are raised and the response is "you're doing the method wrong" you start to err towards dogma and a "No true Scotsman" approach to management.
Sticking to any technique, including agile, no matter what and with no modification is a symptom of a problem. Projects are unique, there's no one size fits all way to manage them.
Yes, everyone in there knows that scrum meetings should be short, but somehow those meetings take long, because everyone thinks their questions needs answers and their dependabcies definitely must be resolved.. so, an hour it goes.
Our meeting format was for each person to say a) What they worked on, b) What they were about to work on, and c) If they needed help with anything. Our rule was that you could ask for help as long as you were just scheduling a time to meet after the stand-up. It worked really, really well.
Then we got a new scrum master whose desired format was to talk about each item on the Kanban board each day, even the ones that weren't being worked on.
This is really bad and a major failure on the part of the scrum master. The point of this meeting is to help the team sync on what they are doing and what they plan to do.
It should take 10m at most. Any issues (blockers, dependencies, etc) should be taken to separate ad-hoc discussions to let the team get back to work.
If there is no room for syncing up and every issue is to be taken offline, one should question if it makes sense the stand ups should be kept in sync. In my team we do standups asynchronously over Slack, it's a great and non obtrusive way of updating each other and we achieve the same thing.
The standup performs an important social function of making everyone involved in the work of the team. People have to face each other, feel accountable to, and feel supported by the group.
And of course there's no room for synching up: The morning standup is meant to facilitate those synch-up meetings, synch-ups that don't have to involve everyone.
>>> The standup performs an important social function of making everyone involved in the work of the team. People have to face each other, feel accountable to, and feel supported by the group.
This is a fantastic description. And it goes a long way towards explaining why standup (even if I'm not directly involved) leave me feeling so uncomfortable.
You are right, problem is in project manager head, which abuses standup for status updates because of lack of understanding of purpose of standup meeting, or because of lack of discipline (developers may provide infrequent updates in git/jira). It's hard to debug development process by email. However, if developers will do their standups properly, then their development process will fix itself. (Or project manager will fire the most active one. ;-) )
There are either too many people in the room, or people are talking too much, and probably about the wrong things.
And, if they are doing standups wrong, I question how much else they are cargo-culting.