My theory is this: the more people you have working on a project, the less meetings you should have. If you have 1-10 people, you could all sit in one room together, having a never ending meeting. This is the One Big Room people like me dream about because I had such a fun working in one at the startups I used to work at itwhen all those people in the room were friends.
It was fun being in that room, and I looked forward it to every day. Which explains why I like The One Big Room Theory so much. The ultimate question of shipping product split 50/50 in each of the startups I was in: one company "shipped" (it was hosted) product and still exists, while the other didn't and no longer exists.
In most Agile-think, a prime idea is that you meet face-to-face as much as possible, ideally, putting everyone in One Big Room. This gives you rapid feedback in the "purest" form possible. In Scrum, and other implementations, you meet daily at the stand-up meeting and exchange statuses. The goal here it to keep everyone in the loop, giving people an over-all context of the project and a chance to start engaging with team members.
Just Showing Up
As the scale of companies I coded at grew, meetings became more numerous and, frankly, tedious. There's a certain point, to be a cynical coder, where people just show up at meetings for face-time: to show that their involved. I'm not saying that these people don't have valuable work that could be done. Instead, their perceptions is that showing up at a meeting is the prime channel to prove that they're doing that valuable work and to do that work.
In America, and I suspect most Western societies, we learn from a young age that simply showing up is half the battle. That rule is beaten into us starting in school where too many tardies (showing up late to class) can effect your grade. Think of of how silly, and un-Agile-think that is: you could be a straight-A student, but if you got to class late 10 times, you'd get a B for the class.
After 12+ years of that mentality, it's little wonder that white-collar workers pack meetings. They don't want to risk getting a B, even if the meeting(s) in question have no effect on shipping the product.
Bad Writers
There are many cynical paths we could go down at this point, primarily among them that all these people aren't really needed to accomplish the goal of shipping the product. I've spent many hours down those cynical paths, and they get frustrating and, worse, boring after awhile; indeed, they're one of the smaller, but compelling, reasons I'm here at RedMonk instead of coding at a large company.
But, let me talk of more constructive things, back to the topic of meetings. If one of our predicates is that people need a way to expose that they're doing work and, thus, show up to meetings, the next theory for why we have so many meetings despite them seeming unproductive that I'd float is that most people don't know how to effectively communicate in other mediums. For example, in writing.
That is, people are very good at communicating face-to-face, but less so with the written word. I feel extremely comfortable typing instead of talking, but I'm not sure if previous generations, or even my peers, feel the same way. To be frank, perhaps all these people who like meetings can't communicate effectively in written mediums.
Thus, suggesting that they just use threaded email and discusions or, better, a blog, makes them panic. It's at this point that Cockburn's theory on One Big Room comes in: One Big Room (and more face-to-face time) isn't a way to optimize a group, it's a way to fix a broken group. What this means is that a group doesn't need to be in One Big Room to be good, rather, if a group is crappy, One Big Room is one tool you use to make them better.
Taking it to an extreme, if you have a "team" of product managers, managers, developers, technical writers, and QA that isn't communicating with each other fast enough to ship the code, throwing them all into one room and locking the door is a compelling quick fix.
Time-shifted Collaboration
That enticing scenario aside -- and though it's painful to type it because it seems so obvious -- chances are you don't need to have a meeting. An email thread, a blog post with comments, or even just a 1:1 meeting in IM will probably do.
This seems counter-intutive because, in the past, there weren't that many tools to facilitate time-shifted collaboration: email was about all there was. But, once you add in such collaboration tools, like archived email, blogs, and wikis, the need for everyone to collaborate at the same time is lessoned. Once again, consumer technology is leading the example for the workplace. On the public Internet, meetings aren't possible, and yet people use these time-shifted collaboration tools every day to get projects done.
My suggestion, then, is to look at meetings as supplemental, out of the ordinary things. If an email, IRC, or IM conversation can't resolve the issue, then call a meeting. But, assuming that you need a meeting -- esp. one every day just to report status that could otherwise be posted to a blog -- seems like too much of a time-suck, almost at every size of your team.
Disclaimer
Of course, as mentioned above, if your people can't communicate in a written medium, this may not work out too well. It's easy to be flip and say "well, you've got bigger problems" (man, oh man, how I hate that response), but the reality is that there's not a very good understanding or practice of "Agile Firing" beyond containment and ignoring.
For as transparent and feedback rich as most Agile implementations are, the team can rarely vote someone off the island. That'd be putting way too much control in the teams hands for most companies and organizations. For some reason, meritocracy is for open source development, not commercial development ;>
Previous Topic
