Re: Agile Project Management
Arne Vajh=F8j wrote:
Arne Vajh=F8j 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 piec=
es.
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 followi=
ng
slots:
1. as the only software development team in a small (<30 people) prod=
uct
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, ~20=
00,
~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 adopt=
ing
agile is either going to help you or hinder you in achieving that goo=
d
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 w=
hat
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.
--
Lew