RE: Agile working with offsite teams

["Leonard C. Porrello" <Leonard -dot- Porrello -at- SoleraTec -dot- com>]

As I understand it, Agile is to software development what poetry is to
literature. It is very difficult to do well, very easy to do poorly, and
most people don't understand why a good poem is good and a bad poem
isn't. When you give college freshmen the option of either turning in an
expository essay or writing a poem, the worst "writers" invariably
choose to write a "poem" (and the results are predictable).

Granted the distributed nature of your team, I can't imagine how your
team will use Agile. Perhaps they intend to adopt only some Agile
principles.

Why do I say this? Check out "Principles behind the Agile Manifesto"
(http://xprogramming.com/xpmag/jatAgileIsIsNotMayBe.htm). It includes
the following principles:

"Business people and developers must work together daily throughout the
project."

"The most efficient and effective method of conveying information to and
within a development team is face-to-face conversation."

Even if the development team manages to pull off daily teleconferences
between developers and customers, fact-to-face conversation isn't going
to happen. What they plan to do instead? How will what they do get
communicated to you and QA?

The problem with a piecemeal approach, picking and choosing what Agile
principles you'll use and which you'll discard, is that you aren't
really doing Agile. You are in uncharted waters. And that might be fine
for mature, disciplined, and well integrated development teams.

You might also want to check out "Perils and Pitfalls of Agile Adoption"
(http://www.informit.com/articles/article.aspx?p=441115). Among other
things, the author states the following:

"It's really easy to throw out the big, thick methodology binder and the
heavyweight requirements documents, but Agile development expects that
something will replace them. Many organizations move to iterative
development without automated testing-with the result that the testing
burden grows exponentially-or move to iterative development but keep the
hard deadlines and the expectation of full delivery on a ship date. Pair
programming without communication and feedback is just someone breathing
over your shoulder. Without testing skills, a developer won't be able to
do automated testing; worse, he won't even realize this as he wastes
hours writing so-called 'tests.'

"In other words, Agile techniques require depth: the ability to know the
right techniques for the current project and the ability to choose
between them. Without direction, a team told to throw away its waterfall
method will simply devolve into "code and fix.

"That isn't Agile: it's chaos."

Leonard



-----Original Message-----
From: techwr-l-bounces+leonard -dot- porrello=soleratec -dot- com -at- lists -dot- techwr-l -dot- com
[mailto:techwr-l-bounces+leonard -dot- porrello=soleratec -dot- com -at- lists -dot- techwr-l -dot- c
om] On Behalf Of Julie Stickler
Sent: Thursday, September 04, 2008 1:42 PM
To: techwr-l -at- lists -dot- techwr-l -dot- com
Subject: Re: Agile working with offsite teams

I'm also quite interested in this thread, as I've just discovered that
while I was off documenting product A (built by off-shore, contract
developers in India) our company's development team for product B has
suddenly decided to adopt Agile development.  I'm in MA and they're in
New Zealand (on two coasts) and the QA for that team in also in India.
 I just found this out before I left for vacation last week, so I
haven't even had time to go back through the archives to look for
posts about Agile.  And I'm a lone writer, so there's just me working
on both Product A and B.

Personally, from what little I remember, I'm not sure that our company
is disciplined enough for Agile.  We essentially don't have any
develoment processes in place right now (they don't even really write
specs), and it sounds like Agile is not on the "beginner" end of the
development process scale.

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

ComponentOne Doc-To-Help gives you everything you need to author and 
publish quality Help, Web, and print content. Perfect for technical 
authors, developers, and policy writers. Download a FREE trial.
http://www.componentone.com/DocToHelp/

True single source, conditional content, PDF export, modular help.
Help & Manual is the most powerful authoring tool for technical
documentation. Boost your productivity! http://www.helpandmanual.com

---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot- 

To unsubscribe send a blank email to 
techwr-l-unsubscribe -at- lists -dot- techwr-l -dot- com
or visit http://lists.techwr-l.com/mailman/options/techwr-l/archive%40web.techwr-l.com


To subscribe, send a blank email to techwr-l-join -at- lists -dot- techwr-l -dot- com

Send administrative questions to admin -at- techwr-l -dot- com -dot-  Visit
http://www.techwr-l.com/ for more resources and info.