[eitally]

Meetings are one type of forcing function. Anything with concrete, time-bound deliverables is a forcing function, too. In a well-managed organization with trained & competent staff, it should not require meetings to ensure progress.

[SanjayMehta]

Some meetings, especially one on one, can be useful. It's very hard to say no to someone you've met, especially when your only other interaction is over the phone, email or chat.

Recurring meetings, especially at the developer level, are a waste of developer time.

I always found it easier to walk around, get personal updates one on one and integrate the information.

That way I wasted only a few minutes of each developer's time, instead of boring them all for an hour per week.

[inetknght]

> That way I wasted only a few minutes of each developer's time, instead of boring them all for an hour per week.

I've been in companies where a standup with 6 people takes 45 minutes.

The company I'm in finishes standup with 8 people usually within 10 minutes and often enough within just 5 minutes.

The companies have very different approaches to information sharing. The first wants in-depth information and for everyone to have opportunities to speak up to offer help. A true team effort is what they want. The second wants everything to be as brief as possible, so you can get back to doing what you're paid to do.

I saw a lot more "progress" at the second company. I also saw a lot less collaboration and more "oops we need to fix this now" happening too -- even into production.

The first company definitely did things a bit slower. But that slower generally translated to better quality software: software that generally worked correctly on the first try, or problems were at least caught before reaching production. When an issue did arise in production, it could be safely and quickly handled and rarely with downtime, because rolling back was part of the extensive test suite.

Coming to truly understand the differences between approaches has been eye-opening, and has seriously changed my biases about "how" to go about writing software on a day-to-day and week-to-week basis. Collaboration is good, but you have to have buy-in from the developers for it to work well. That was key and it took a lot of convincing each developer of the benefits.