Re: Agile Project Management
On 2/12/2012 3:55 PM, Lew wrote:
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.
Maybe technical leadership ~= shared framework??
In practice it works out all right that one team chooses PHP and another
JSF,
Single signon and session sharing becomes a problem.
or as in my experience, one programmer C and another Fortran.
Increases skill sets necessary for maintenance.
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.
If they pick Oracle and operations know DB2 and not Oracle, then
that will not work.
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.
I disagree on that.
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.
Speaking English is sufficient to understand what the other
part is saying.
But making a big IT project succeed require a lot more than that.
Arne