[matthewmacleod]

I don't think it's an 'either-or' proposal though. You're contrasting 'here's my ideal asynchronous system' with 'horribly long rambling meeting at the worst time.'

Here's my company's typical morning, for example:

- Arrive at the office. Catch up on email, Basecamp, maybe do some code review, that kind of thing. - Have a stand-up meeting that lasts ~ 5 minutes, where developers and product people discuss what they are currently working on, any blockers, things that they anticipate will be needed from others etc. - If there are any issues that require further discussion, agree a time or channel to discuss them.

It's great. Everybody is fully aware of everything that's going on, who's working on what, and any upcoming issues. It takes basically no time and serves as the launch point for the day's work.

I appreciate that it doesn't always work – may be more of an issue for teams that are geographically distributed. But I also absolutely see it working really well in practice, so I'm suspicious of reasons for discarding the idea so easily.

[p4wnc6]

In several jobs all using Agile, with experienced Scrum masters and lots of training, I've never heard of or witnessed a stand-up actually lasting the allotted 5 minutes (they always run way over and never contain info that I actually need to be present to hear about) -- not even when it was a team of just four people. It's simply unrealistically averse to human nature.

[disruptiveagile]

Hmmm, during my last contract my shortest daily stand-up with an oversized team (14) was in fact four minutes: we held it around a restaurant table right before dishes being served :) PS: It took 4 minutes because one of the team members was new - her first day with us ...

[matthewmacleod]

I have very infrequently had a standup run over in ~5 years of daily stand-ups; if it does (rare), it's because we've discovered an issue that's going to stop the team making progress immediately and needs to be dealt with. They almost always contain relevant info from the team I am working closely with.

I have to wonder the environments in which people are working where this is not the case. Is it just that the teams are too large?

[p4wnc6]

I don't doubt your experience. I'm just saying that my experience has been violently the opposite -- for both large and small teams in large and small companies, all of which had done extensive training about Agile and had used Agile for a long time. Also, and this is not an exaggeration, literally every software colleague or contact or friend I know also has had the experience I have had.

We acknowledge there are amazingly rare companies like where you work that don't suffer from this -- but they just seem to be so, so, so extremely rare that they don't really factor into any true understanding of what "Agile" means in practice at the overwhelming majority of companies.

Also, in almost every case our standup meetings went on too long because people talked about irrelevant things, personal anecdotes, weekend plans, etc. Many times they thought what they were saying was relevant, but it wasn't. Scrum leaders were often the ones doing this the most.

Over time it basically fractured the team into two groups:

(1) the "boy scout" group who wanted to appease the Agile process and look like good, obedient workers, and so never minded the irrelevant and time-wasting meetings and acted chipper and happy to engage in all things Agile.

(2) the disillusioned and burned out group, for whom (over time) the irrelevant banter of stand-ups became like having someone grind your eardrums with sandpaper, and led to frustration, lack of energy to participate, and resentment, and a ton of turnover.

I've seen this dynamic develop in a lot of companies too. Sadly, the answer they usually come up with is a sort of Agile eugenics: let the people who get understandably frustrated by Agile leave -- regardless of how much experience in the company they have, how critical they are to their team or product, or how good they are. And then change the hiring process to screen virtually solely for Agile enthusiasm and end up shifting the workforce to a pro-Agile monoculture -- and then, regardless of whether it's objectively true or not, declare victory and talk endlessly about how much more productive you are now that you are uniformly Agile.

[douche]

It doesn't really matter that it takes almost no time - it's that it is an interruption[1]. You're working along on something, getting in the groove, then Outlook dings at you , so you've got to page out the real work that you're doing, recall the silly scrum answers you're supposed to give, get up, walk over, wait for everybody to show up, blather on about things that you don't care about and already know because you've read the digests from source control checkins and ticketing, say your piece, and escape. Half an hour or more is blown away, plus another half hour to get ramped up to where you were before this all started. Oh, and by the way, somebody surprise-scheduled a customer demo or {InsertOtherMeetingWithNoDefinedAgenda} for you in an hour. Might as well just get coffee and browse the internet, and accept that normal working hours are for looking like you are working, so you can actually get something done later when everybody has gone home.

[1] http://heeris.id.au/2013/this-is-why-you-shouldnt-interrupt-...

[matthewmacleod]

I'm not convinced.

Stand-ups are only an interruption if they are poorly scheduled. I accept that sometimes it isn't possible to schedule one, such as when there is a large, geographically-distributed team. However, I have rarely seen them take place outside of the first 30 minutes to one hour of the working day, in cases where teams work on-site. This works really well in my experience, offering a little bit of time to get set-up for the day, a stand-up near the beginning to catch up and exchange status, then an uninterrupted rest-of-the-day.

To be honest, it sounds like in most cases I've heard of that teams are just undisciplined about interrupting developers. I obviously agree that interruptions are bad, but I've had great experiences (like my current team) when the standup serves to consolidate all interruptions – there will be no surprise customer demos, unexpected interrupts or other things of the sort, and part of the 'social contract' of the team is 'we will have this short meeting to keep us all up to date, and in exchange we will prevent developers from being interrupted'.

It works great.