At some point you just say, "let's discuss this after the Scrum". Usually when people get off track, it's because they need to talk to someone specifically instead of the group. We don't usually have a problem with this, but we don't mind if a Scrum goes half an hour or so once or twice a week. Sometimes we just decide to break out and brainstorm and let others go about their day. You've got to deal with it on a case-by-case basis.

Fair enough. At least I didn't use the term "literally" to mean "figuratively". :s/It's ironic/Strangely enough/

Please tell me this is an exaggeration. Show me a single developer who hasn't caused an issue of some sorts, in production, and I'll show you a developer that hasn't fully matured yet.

What ends up happening in that case is that a bug is found in the "original" (or any subset thereof) code and it's fixed. 11 copies with the bug, authored by three other developers, remain.

It's ironic, I was literally just reading that blog post.

I've worked in both environments. Where I currently work we have a daily Scrum (in name only) and we only cover three questions:

• What did you work on yesterday?
• What do you plan on working on today?
• Is there anything blocking you yesterday or today?

It's a liberating thing. I can literally call someone else out for blocking me, or they can call me out for blocking them. Our manager can say, "I understand you were working on X, Y, or Z yesterday, but Alice, Bob or Carl needs you to work on this today so they can get their stuff done." It's simple, it's effective and it makes the team more coherent and cohesive with nothing more than a 15 minute "stand-up" (we all work remotely on any given day and we do the Scrum via Google Hangouts) at 10 AM. It sets the tone for the day. And it only costs our attention for 15 minutes and willingness to be reasonable with other professionals on our team.

We don't have:

• Organizational Fear: You can dial up anyone or schedule a meeting to resolve a problem. If you break the build and no one says anything about it... they can either tell you about it the next daily Scrum, or it isn't a problem for them. Simple as that. You need to talk to someone? Schedule a meeting with them and anyone else that needs to be involved. If you can't make that happen, bring it up at the next daily Scrum.
• Losing Your Job Fear: We're all paid professionals and are experienced and knowledgeable in our field. Keeping us afraid would only be enough to keep us working, but not enough to keep us innovating and a leader in our field. For more on this, read further.
• Fear Of Changing Code: Once again, if you have an issue with code, bring it up with the original author of the code or someone familiar with the code base. They won't take it personal (see previous point). If you're afraid of breaking the build, dial up someone and do some pair programming. At worst, you'll check in something that doesn't pass unit tests (or lacking those, code that will not pass code review before it's deployed). You'll feel stupid for at most a full day and you'll survive.

To be honest, FDD seems like a culture problem more than anything else. You're a professional. Act like it and expect those around, and above, you to act like it. If your culture is so messed up that you suffer from these problems, it's most likely just the tip of the iceberg of the organizational challenges that your company faces.

"Of course, that's just my opinion; I could be wrong" -- Dennis Miller

So... you just DDOSed your friends. You sure you're not a sysadmin yourself?