My company does outsourcing, mostly with startups. We use scrum (the management framework) and lots of extreme programming (technical practices), all of which fall under the broader "agile" (abstract concepts). We do these on every one of our projects...from 2 person iPhone apps to year long, multi-team projects.
For any group of people that's going to work together and produce, the ideas in scrum and agile are super important. Apply them how you like, using whatever names you like, but understand them and be aware of which ones you're doing
To me, scrum is barely a process, and it won't solve any of a group's problems...but if it's applied at all it will make those problems really obvious, at which point it's up to people to fix them.
I set the policy early on in my company (we follow very complete Agile and XP) for all engineering related meetings: immediately after lunch or not at all. Standups, Iteration planning and review, Manager 1-on-1s, you name it.
Lunch interrupts everyone and people are rarely doing their most incisive thinking while food digests...if we're going to be unproductive anyway, might as well have a meeting.
I put in this policy for the same reasons PG talks about, and feel like it pretty completely handles the problem. Do people agree or disagree? Is there any reason I shouldn't be treating 1-2:30 as talking time, and the rest as coding time?
For any group of people that's going to work together and produce, the ideas in scrum and agile are super important. Apply them how you like, using whatever names you like, but understand them and be aware of which ones you're doing
To me, scrum is barely a process, and it won't solve any of a group's problems...but if it's applied at all it will make those problems really obvious, at which point it's up to people to fix them.