Yeah, these are all common dysfunctions in teams getting started with Agile.
You see these a lot in cargo-cult style adoptions. They understand that they need to do these practices, but they don't understand why. The end result is that they try to pervert them to serve their own purposes (e.g. daily stand-up as a status meeting for managers) and lose the real value. Then they complain that "Agile doesn't work here".
I have seem teams use end of day stand-ups. The problem with those is that they tend to devolve into status updates pretty quickly.
Team members report on what they did that day, but seldom think about the things they are going to get done next and the things that are preventing them from getting started on the next thing, which in my opinion, are the more important things to focus on.
Since you are a manager, I might suggest that the Agile and Scrum the daily stand-up isn't for you. While I appreciate your need to know what's going on with the team, in Agile and Scrum, the daily stand-up isn't there to provide status to managers.
The purpose of the meeting is for the team to get together and co-ordinate the work that needs to be done in order to meet their Sprint goals. So while you may be able to get status information out of that, it's more important for team members to use that time to figure out how to meet their goals.
In addition, status should be obvious in Agile teams. This is why you usually see things like cards on walls and burn down charts. If status isn't obvious to everyone, you may want to see if there are other ways the team can make that information highly visible.
> Since you are a manager, I might suggest that the Agile and Scrum the daily stand-up isn't for you
I definitely agree with this. Standups/scrums have become much more productive since management stopped attending. It's hardly a "status" meeting any more -- sure, we talk about what we're working on, but there's a lot of jumping in by other team members with suggestions, help, or "I was going to do something similar, let's coordinate after the meeting".
The daily stand-up as a status meeting is a common anti-pattern and one I often have to coach teams out of.
While yes, you may be able to derive status from a daily stand-up meeting, that's not the point.
The point is for the team to co-ordinate their work and figure out how they're going to get things done. Done well, it has more in common with a planning meeting than a status meeting.
I actually have a whole course on how to have good stand-up meetings.
Wow that is entirely wrong. You don't figure out how you are going to get things done in a 10 minute meeting. You quickly call out where you are and if you are stuck, so people know who to needs help, or who can give help, or what needs to be done that no one is doing yet.
You don't figure out how you are going to get things done in a 10 minute meeting.
Sure you do, at a very high level. "Milo is doing the SYNAPSE adapters, Stinky is working on the compression drivers, Lisa is doing the UI stuff and Teddy is fixing the build system."
That can be covered in 10 minutes, and then the individuals involved can (and should) go off and hold whatever independent meetings - if any - are required for their specific tasks.
In Scrum that's where the Scrum Master comes in. It's their job to facilitate the meeting to ensure that those conversations are continued after the meeting.
A good team will often find ways to achieve these things without requiring the Scrum Master to step in.
Are you all working on different projects/features? That's usually a symptom of teams that aren't really teams. They sit together, but work in completely different worlds and do not really need to communicate together.
Teams have a shared goal that they're trying to accomplish together. If you have a team, you are very concerned about what everyone else is working on and struggling with since it will affect where you can help and what you should be working on.
That's why Agile teams are small teams. If you're team is too large then you'll end up fragmenting and forming sub teams and not caring what the others are working on since it won't affect you.
Remember, it's more important to build the right thing than it is to build lots of stuff.
It's better to have the daily stand-up, interrupt your productivity a little bit and discover what you're working on shouldn't be worked on at all, than it is to work for days on something only to have to throw it out and start all over again because you didn't know that something changed.
Far too many organizations focus too much on individual productivity and far too little on delivering things that are actually valuable to their customers.
That's not to say individuals shouldn't be productive, just that writing code all the time doesn't necessarily mean you will be successful as a business.
If the start time is a problem, bring it up at your retrospective and see how the rest of the team feels about it.
That would certainly be something to bring up with your team if you do regular retrospectives.
The purpose of standing is to keep the meeting short and focused. Can you think of alternative ways that your team can ensure that the meeting is short and focused that doesn't require standing? If so, suggest them (or see what your team members suggest) and try them out!
I think you are missing the point that I'm making which is quite simple. Requiring people to stand up is a discriminatory practice and that puts companies at significant legal risk.
Recommendation? We sit and the meetings are short or long or don't happen at all on an as needed basis.
Don't force your cure on those of us who do not have your ill.
As I mentioned in another comment, they likely forgot the purpose of the daily stand-up, which is to have everyone be on the same page everyday. If they're doing that without a daily stand-up, then fine, but it's usually quite difficult to do in teams larger than 2-3 people, which may explain why they lost the value when they stopped doing it.
It's not hard to do the daily stand-up and there can be many ways to make it more of a team building experience. I use Improv with the teams I work with (see: http://ow.ly/dOmJJ)
You see these a lot in cargo-cult style adoptions. They understand that they need to do these practices, but they don't understand why. The end result is that they try to pervert them to serve their own purposes (e.g. daily stand-up as a status meeting for managers) and lose the real value. Then they complain that "Agile doesn't work here".