Re: agile/xp question (formal analysis)
From: Ron Jeffries (ronjeffries_at_acm.org)
Date: 11/29/04
- Previous message: Laurent Bossavit: "Re: Thought Before Action."
- In reply to: AndyW: "Re: agile/xp question (formal analysis)"
- Next in thread: Ilja Preuß: "Re: agile/xp question (formal analysis)"
- Reply: Ilja Preuß: "Re: agile/xp question (formal analysis)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Sun, 28 Nov 2004 19:17:24 -0500
On Mon, 29 Nov 2004 10:58:19 +1200, AndyW <foo_@bar_no_email.com>
wrote:
>On Sun, 28 Nov 2004 04:59:21 -0500, Ronald E Jeffries
><ronjeffries@acm.org> wrote:
>>
>>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.
It's the word "required" that I'll be taking issue with or exploring.
My thinking is much along the lines of Laurent's post just above.
>
>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).
I would definitely agree that /if/ we did it that way, we would surely
have spiked any possibility of being agile.
What seems equally true to me is that we might have taken a handful of
people, looked at an existing flight booking system, talked with, as
Laurent suggests, people from one airline, and begun to produce a
system.
I'd wager that I could have a small scale booking system running with
a half-dozen people before the recruiting for the 70 people listed so
far could be accomplished. (But you wouldn't bet against me, I'll also
wager. Instead, your concern will be that the small scale system
couldn't "scale up".
>
>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.
Yes. Again, if we choose to do these things, then we'll have spiked
our feet to the floor as regards agility. And I know that people
believe these things are necessary. Maybe they are, but I don't see
it.
>
> <more hiring snipped>
>
>All this stuff needs to happen on a large project (this is based on
>WSSDM but you can substitute any project level methodology here).
I get that it does happen. What's not clear to me is that it really
needs to happen, at least as early as we think. (It's not clear to me
that it /doesn't/ need to happen either, mind you. If one day the
project really will need hundreds of people, I surely don't know how
to manage them in a room.
But if someone had a bunch of money to waste, I could imagine trying
what has been called a "Conquer and Divide" approach, where a small
team builds a small system, works intimately with "Customers" to
figure out what the system's shape has to be, and then begins to
divide into different teams based on natural cleavage points in the
system.
Would this work? I don't know. I wouldn't want to be responsible for
it, but then I don't like the kinds of things that "have to", or at
least /do/ happen on large projects. So the project wouldn't want me,
and I wouldn't want it. That's cool.
But I don't see that these things are logically necessary. I see that
they are things that have sometimes worked, and that people believe
them to be necessary. They are /a/ way to do it, but I don't see why
they are /the only/ way.
>
>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.
Yes, I see that. Many of the practices of Agile/XP are valuable
anywhere. The structure you've described, as I understand it, has to
do with coordinating the activities of many smaller groups, in a sort
of hierarchical structure, so that everything comes together. At the
small group level, much of the process could include Agile/XP
activities to good effect and no harm. (Those activities would be
required to be supplemented with reporting of various kinds to aid in
the coordination, of course.)
>
>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).
I understand the distinction you're drawing. Again, I agree that you
are describing a valid way of doing these large projects, but it's not
clear to me that it is the only way or even the best way -- though
surely it's the best way we know so far.
>
>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).
At this level I'd be wanting to tighten the loop between BA and
developers, and to avoid as many fixes as possible through means such
as concrete acceptance tests and the like. I would suppose that some
of the problems would be difficult, and that other techniques would be
useful as well. I'm sure that no one likes the need for a fix phase. I
suspect that many people see it almost as a necessary evil, and I
suspect that there are still ways to reduce that evil. Some of those
ways might come from the Agile thought process, perhaps.
>
>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.
Yes. Here I'd not use individual developers but teams, and I'd want
not to break th ings between feature, middleware, and server, but
instead to go end to end through all of those in one featue team. As
you point out there is inevitable waiting when we build the teams with
feature, middleware, and server split apart.
>
>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.
What are they doing the other three days?
>
>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.
I believe I understand the description, and appreciate some of the
inevitable scale issues. Obviously this thing wouldn't run on a single
PC in someone's basement.
And yet, I wonder how far one could go in understanding the
architecture and building the UI and so on by starting with a small
team building the system in the presence of "Customers" (BA's, real
users, etc) in an XP style.
It's easy to speculate about the things that "would" go wrong. I
expect that most of the arguments will be about scaling up. Those
arguments are interesting, and persuasive, but not entirely persuasive
to me.
It also starts me wondering about an airline booking system that works
like Kazaa, or Napster, or SETI@home. Small software, small systems,
fully distributed, hmm ...
Thanks and regards,
-- Ron Jeffries www.XProgramming.com I'm giving the best advice I have. You get to decide if it's true for you.
- Previous message: Laurent Bossavit: "Re: Thought Before Action."
- In reply to: AndyW: "Re: agile/xp question (formal analysis)"
- Next in thread: Ilja Preuß: "Re: agile/xp question (formal analysis)"
- Reply: Ilja Preuß: "Re: agile/xp question (formal analysis)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
