Arne Vajh?j wrote:
Arne Vajh?j wrote:
Lew wrote:
Arved Sandstrom wrote:
I don't think the OP meant ~800 person *project*.
Once we start getting into these examples I'd like to see a clear
understanding of what numbers are involved in what roles on what pieces.
I can think of examples from my own experience where a software
development team of maybe a dozen or fifteen folks (developers, team
lead, technical architect, PM, QA/QC types etc) fell into the following
slots:
1. as the only software development team in a small (<30 people) product
company;
2. as one of several similar sized teams in a ~100 person IT shop in a
small/mid-sized (several thousand people) services organization. Each
team working independently on their own IT projects;
3. As the only team working on a specific product in a large (10,000+
persons) IT company. Dozens upon dozens of other teams, many larger,
some smaller. But this team is insular and works on one thing.
In these 3 examples mentioning the size of the organization (~25, ~2000,
~25000) is irrelevant.
You're absolutely right, though, Patricia: for an 800-person *project*
you sure would want clean interfaces. Myself I don't think that adopting
agile is either going to help you or hinder you in achieving that good
architecture; either you know what you're doing or you don't.
If you have structured an 800-person project in this sense, not
decomposed
into 5- to 12-person autonomous projects, then either you don't know what
you're doing or you don't.
If would put it the exact opposite if a 800 person project is split
into 80 autonomous projects of 10 persons, then the management it
totally clueless.
Imagine some autonomous web UI projects choosing:
- PHP
- Struts
- JSF
and some autonomous persistence projects choosing:
- Oracle with SP's
- DB2 with Hibernate
Full communication between each member of a team requires geometric
increase in communication bandwidth with team size. Autonomy, within a
shared framework as you aptly point out, is a necessity for such a large
organization to function effectively.
In practice it works out all right that one team chooses PHP and another
JSF, or as in my experience, one programmer C and another Fortran. What's
the harm? Where teams must share a common resource, say that choice
between Oracle and DB2 you describe, one of those small teams could be the
database team. It would then function autonomously to serve the needs of
the other teams, the database team's clients.
Surely you don't profess that 800 people on a team should work as a single
unit? That is a proven antipattern. You have to break that large a group
into manageable sizes, and those smaller groups must have autonomy.
However, not to the /reductio ad absurdum/ point you mention. Analogously,
you and I have autonomy in our posts to this newsgroup, yet we work within
a common framework of the English language. Autonomy is not synonymous
with isolation.