> From: Russell Gold [mailto:[EMAIL PROTECTED]
> Sent: 25 October 2004 14:53
> Subject: [XP] Persuading the technical team...
>
> I am in an interesting situation. Our development organization is
> split across four geographic locations across North America, most of
> the branch groups having been aquired. My local team (the most recent
> aquisition) has been using TDD and some other aspects of XP for some
> time and have been very effective with it. The other teams are much
> more used to BDUF approaches and are not as successful.
>
> We managed to put together a technical leadership team (officially an
> "architecture team") and are now trying to address a number of
> problems in the code and process. Naturally, I am pushing for an agile
> approach, and had assumed that the others were amenable to it, but
> simply uncertain how to go about it. I was mistaken. A recent comment
> from one of the more vocal members:
>
> > I don't think you get the performance/modularity/decrease
> in config that we
> > need by incrementally changing something. Refactoring
> without a clear
> > architectural goal is just polishing a turd.
>
> > Remember, GIGO - polished, naturally.
>
> > You seem to be saying that as we incrementally refactor,
> the architecture
> > will appear from the process. I don't believe this is the
> case (never
> > witnessed such an event, nor heard of one).
>
> Any thoughts on how I go about making the case here? Or am I simply
> wrong in assuming that we can refactor to a good architecture without
> extensive documentation and review?
>
>
If as you say, your team has been very effective with agile processes,
and the other teams have not been as effective then you should be able
to present some business based statistics to help back up your point.
Especially for the third comment, providing some hard evidence that
previously your team has employed agile processes, and that you team has
since employing agile processes had a higher customer satisfaction,
faster delivery to customer and less customer issues than previous
projects then the process should speak for itself.
If there is one or two vocal members who are particularly resistant to
the idea of using Agile processes, then possibly inviting them to come
and visit your workplace, to see the process in action and see how it
works may help.
Of course, if as a recent acquisition you have no say in these meetings,
then you may have to choose your battles carefully, and possibly allow
the BDUF people to go ahead with their plans, instead waiting for more
apt circumstances to make your point.
Good luck with it anyway.
Mib
Software Engineer
To Post a message, send it to: [EMAIL PROTECTED]
To Unsubscribe, send a blank message to: [EMAIL PROTECTED]
ad-free courtesy of objectmentor.com
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
