Re: agile/xp question (formal analysis)

From: AndyW (foo__at_bar_no_email.com)
Date: 11/28/04 

Date: Mon, 29 Nov 2004 10:58:19 +1200

On Sun, 28 Nov 2004 04:59:21 -0500, Ronald E Jeffries
<ronjeffries@acm.org> wrote:

>
>OK, after lying awake most of the night, I have a question for you and
>Daniel -- and anyone else who can chip in. I'm not entirely convinced
>by the overhead / infrastructure issue, for reasons that I'll maybe
>come back to here, or separately. But for now let me get to my
>question.
>
>Imagine a project. I'll put some numbers to it, come back with your
>own if it works better for you.
>
>Imagine a ten-person project, planned to take six months. It's
>supposed to produce 60 features.
>
>OK, ten people, six months, call that 1200 person days. 60 features
>means that the analysis, design, code, test, and fix for the average
>feature will be 20 person days. Two team weeks.
>
>So, modulo maybe a little time starting up, what is it that stops our
>team from shipping one feature, analyzed, designed, coded, tested and
>made to work, approximately every two weeks?
>
>Now remember, there are projects that do just that. C3 was 14
>developers, not 20, and it delivered a fully integrated and tested
>system every three weeks, adding about 10 or so new features every
>cycle, for four years, at approximately a constant pace of features /
>unit time. I've coached projects all over that do this.
>
>Yet ... folks here, like you, Andy and Daniel and others, seem not to
>just be saying that it scales up more slowly, so that a larger project
>could only ship a feature every four weeks or something. You seem to
>be saying that a larger project reaches some point where it can't ship
>incrementally at all, and can instead only ship large batches of
>features, once, or a few times, over the course of the project. Unless
>I'm not understanding your points, of course.
>
>So ... what am I missing? Thanks!

i'd call that a small project to be honest and what you have described
while being valid is probably the output of just one feature core
team. Add another five or six of those teams to the project then
imagine the infrastructure that would be required to go with it.

As an example, (i'll make up an imaginary project - based on one that
I was on, using a formal method), but lets assume we are developing a
flight booking system for maybe a dozen major airlines around the
world

The first thing that will probably happen is that the management team
will have to bring together a sales engagement team - probably with
people in several different countries.

Next will be the senior architecture team, probably about 6 people and
will include the top PM and probably any others as well (some projects
may have half a dozen project managers on board).

At this stage a BA team will be formed from industry experts - these
people along with the architecture team will be customer facing - or
if no customers exist (as is often the case) will represent the
customer along with the slaes team.

So now you have probably about 30 or so core people involved in
creating the very high level problem statement, use case model,
non-funcional requirements and system architecture for the airline
industry.

Management tasks would be the Business Case and Acceptance Plan for
the project. The former is to draw funding and the latter is to have
signoff for each of the customers and all of the bits and pieces of
the project (all the stages and features etc).

As that starts to develop you'll want to start getting a UI team into
action, these guys have to do a lot of conceptual modelling, probably
create a prototype and proof of concept as well as during production
create the UI for each of the feature teams.

The UI team will also probably be your floor walkers along with the
architects - basically solving developers and management issues,
teaching, bug fixing, evangilizing the vision, etc.

BAs will start coming on board and you'll want to start splitting them
into sub-teams as each of the feature sets start being defined. Each
Team of BAs will produce the requirements for that feature set. They
will be doing most of the analysis and part of the design (to the
system model).

By now you may have about 60 or 70 people on your project and probably
some idea of what an airline booking system does (you've probably also
nicked a copy of your competitors product at the local trade shows).

Management overhead at this stage will include fleshing out the whole
dev process for each of the feature teams, a resource plan, high level
shcedule, release plan, QA Plan, Risk Plan, Reuse plan, Test Plans
Metrics, Issues and Dependancies.

These will be at the senior PM level and there will probably be a
manager or person responsible for tracking each one of these. At the
more detailed level the PMs on each of the feature teams will also be
doing that work, and input will come from developers (developer
overhead).

Now the feature teams will start ramping up and taking developers on
board. These guys will be working with the BAs and performing some
level of design (as dictated by the architecture team) and all the
tasks that were listed in the 10 man example (you could be using
agile/xp at this level).

So things that will be floating around will be for analysis - AOMs
(analysis object models), scenarios, OIDs, State Models, Class
descriptions, screen flows, layouts, architecture diagrams, NFP
documents, APIs, target environment platforms, and for design - all
the design stuff for the above.

You will also have a middleware team, several server side teams (if
multi-platform) and a database team and a test team and most likey a
build team as well.

You'll probably be creating implementation teams, as well as bringing
people in from whatever countries you are deploying your product to
for training and planning sessions.

By now you should be up to a hundred or so people depending on how
many feature and back end teams you are running.

All this stuff needs to happen on a large project (this is based on
WSSDM but you can substitute any project level methodology here).

The Agile/XP process itself can be used on the project, but at a much
more granular level. Usually its the method that the feature and back
end teams use - and it wont be a direct implementation - it will be
highly modified at the best of times.

Its important (at least for me) to understand that when an Agile
person is talking about release schedules and feature sets and all
that - they are doing so from the perspective of a member of a feature
team, rather than the perspective of the entire project. At the
project level it is more like mini-waterfall (although you will find
the buzzwords to be taken from the feature teams).

So you'll have multiple BA teams performing analysis/high level design
- as they finish each phases tasks, they will probably start on a fix
phase (ver x.1) for a while to pick up issues found by the devs and
customers (this is the mini-waterfall overlap) , before going on to a
missing feature phase (x.2) for stuff that was delayed, and then the
next phase (y.0).

As each work product this produced by those teams it will probably
then get assigned to the appropriate feature teams and probably by
them to an individual developer who will follow it thru to completion.
Its likely that they will have counterparts on other teams (if the
produc requires middleware, server stuff etc). so there will be delays
while people wait for things to happen or do other stuff such as
planning and the like.

In general you'd find that a developer will be coding for probably 2
days out of 5, days at best (if you look at the average metric)
although sometimes they may get a burst and perhaps do a whole weeks
worth.

You'd probably be looking at about a year or so to come up with a
working system that could be demo'd to the sponsers and customers
(although you would have kept the UI folks doing whizzy things with
prototypes), and maybe 2 years to go gold with a version 1, then
probably anotther 2 years to capture your target market share and
mature the feature set with reall stuff.

Probably at the ver 1, the team size would shrink or grow depending if
you are spinning off maintenance to the individual countries or having
a core dev team with feature implementation teams out on location.

Relevant Pages

  • Re: agile/xp question (formal analysis)
    ... >still separate Analysis from Design and so on. ... development of a feature. ... your project plan. ... Thats what all methods achieve, nothing to do with the method itself, ...
    (comp.object)
  • Productivity: Quantity or Quality?
    ... produce software quantity or software quality? ... which "goal" should developers be aiming for? ... some "feature" may be taking its time for the programmer to produce, ... "science" (left hemisphere thinkers) people will find it simpler than "art" ...
    (alt.lang.asm)
  • Re: Alternatives to MS project
    ... It's also the reason I do not plan on using the ... document attachment feature but rather just use links, ... > was developed by expert developers who had no understanding of ... They hired scheduling experts to advise them but, ...
    (microsoft.public.project)
  • Re: FC4 or FC5
    ... cost it is equivalent in Windows. ... you may have paid more for support of RHEL than XP. ... those who whine about this or that missing feature are losers. ... You seem to forget that not all users are developers. ...
    (Fedora)
  • Re: Some thoughts on VB9
    ... A Document Outline for code that displays #regions as well as groups members ... feature but that's pretty much the extent of refactoring in VB2005. ... is for good reason that VB developers have a bad rep.... ... VB developers who are serious about the language wrong. ...
    (microsoft.public.dotnet.languages.vb)