Re: Agile Project Management
Arne Vajh=F8j wrote:
Lew wrote:
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 pi=
eces.
I can think of examples from my own experience where a software
development team of maybe a dozen or fifteen folks (developers, tea=
m
lead, technical architect, PM, QA/QC types etc) fell into the follo=
wing
slots:
1. as the only software development team in a small (<30 people) pr=
oduct
company;
2. as one of several similar sized teams in a ~100 person IT shop i=
n a
small/mid-sized (several thousand people) services organization. Ea=
ch
team working independently on their own IT projects;
3. As the only team working on a specific product in a large (10,00=
0+
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 *proje=
ct*
you sure would want clean interfaces. Myself I don't think that ado=
pting
agile is either going to help you or hinder you in achieving that g=
ood
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 larg=
e
organization to function effectively.
Maybe technical leadership ~= shared framework??
In practice it works out all right that one team chooses PHP and anothe=
r
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 o=
f
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 sin=
gle
unit? That is a proven antipattern. You have to break that large a grou=
p
into manageable sizes, and those smaller groups must have autonomy.
I disagree on that.
However, not to the /reductio ad absurdum/ point you mention. Analogous=
ly,
you and I have autonomy in our posts to this newsgroup, yet we work wit=
hin
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.
Again, there's a difference between autonomy and isolation. Within the
overarching framework, each team must be autonomous with respect to its
own responsibilities. You seem to interpret "autonomy" as "no one
communicates with each other". That's not what it means. What it does
mean is, "Each group makes its own decisions within its sphere of
responsibility."
Your counter-examples do not negate autonomy, they negate isolation.
--
Lew