William "Chops" Westfield wrote:
>> There is no such thing as perfect communication.
>
> I think the problem with many development methodologies is that they
> fail to scale well.  I've had some of my most productive moments
> sharing a bull-pen like room with 1 to 6 other engineers, but I can't
> imagine enjoying sharing an "open space" with 20-odd people, and I
> sure don't see how to scale "good communications" to projects
> involving more than 100 people.
>
> (At one time we had a policy of seating SW engineers in cubes next to
> HW engineeers, and that accomplished some good things when most HW
> efforts involved one or two HW engineers and most SW efforts involved
> one SW engineer.  But it pretty much died when the projects got big
> enough to involve more than 3 of each...  Sigh.)

I agree there needs to be a balance. For example, McConnell recommends using 
pair programming only for the difficult parts of the code, and discourages 
its use for routine programming.

However, the agile concept of small teams can definitely be scaled (it's 
been done in the real world). I already explained it in the "agile" thread, 
but the way it works is, a small "top-level" team is formed, consisting of 
delegates (product owners), one from each lower-level team. If more people 
are involved, the process is repeated.

This is similar to traditional environments where you have a manager (or a 
team lead), the difference being that within each agile team, communication 
barriers are reduced.

Vitaliy 

-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist