Scrum - Part I: Daily stand-ups

I'd like to open these series of posts and the blog by sharing my thoughts around Agile, and specifically, Scrum.

Over the past 7-odd years, I've been through a number of workshops in all roles imaginable: Product Owner, ScrumMaster, individual contributor, and manager - sometimes representing a schizophrenic amalgamation of all four in a single session.
My main issue with each and every one of those sessions was that said coaches always presented a set menu: i.e. you shall have to do steps A, B, C, D up to Z, and success will ensue.
Now, each of the individual steps made a lot of sense, but life tends to present a never-ending series of trade-offs: i.e. you can do step A, but then you need to be wary of specific conditions where it might not work great, and this is exactly what I felt was the gap.

As software developers, we are expected to wield a large set of tools, and then apply a specific tool here, and another tool there - this is what we are being paid for. If a software engineer went to a talk on Monday and learned what a State design pattern is, and then started using it from Tuesday onwards on every "if" statement, he/she won't be providing a whole lot of value (this, in fact, precisely what happened to an ex-colleague of mine).
To take an even closer parallel, an experienced project manager would apply a different set of tactics depending on what project is being managed.
Why not do the same for running teams and sprint iterations?

So, what I'll attempt to do is dissect a few Scrum practices and look at what situations they worked well for my teams, and which they did not.

Let's start with the holy of the holy: daily stand-ups. I'm sure that most Agile adepts will be shaking their head with indignity: surely daily stand-ups are a must for each Scrum team.
Well, I've been a ScrumMaster for a group of 12 engineers with varying expertise levels: the team owned a set of modules (rather than projects), and they worked on different tasks. If we take the classic guideline of no more than fifteen minutes per stand-up, we end up with 75 seconds per person. 
I'd challenge anyone (even a great speaker) to condense an unfamiliar subject, progress, plan and showstoppers included, into 75 seconds. The team consisted of great guys, but even their best admirer would not call each and everyone one a brilliant speaker. Hence, these stand-ups devolved into either interrupting the chattier folk, or 1-to-1 conversations between the two guys who did share a project, while many people were trying to stare up a hole in the ceiling, get rid of their slot and move on with their lives.

Now, I'm sure that if this were a team of 4 people of the same expertise level, working on the same project, then it would have worked out great. The problem happens to be that it wasn't.

Of course, the solution suggested itself: re-define the notion of team, and have only stand-ups between the people who are collaborating daily. Considering that in this case, this would have been not more than 2-3 people at once, we devolved to the "speak to each other" practice.

One can raise a valid risk of going the silo-ed way, and ending up with people becoming unaware of what is going on around them. So far, the solution we gravitated to was having a weekly sit-down (time-boxed, half an hour long) involving the entire team. 
Would I recommend this for everyone? Of course not. 
Did it work? In my opinion, yes, for these specific teams. At least, the team members in both cases were greatly in favour of moving away from the all-inclusive stand-up.

With all of that, here's my set of pros and cons for the daily stand-up.

Pros: Works well for project teams, especially efficient when engineers have similar expertise. 

Cons: Not suitable for large module teams, especially if they work on disparate areas. Becomes a burden on teams larger than 6.