Agile Development

I recently attended a Society for Technical Communications meeting where Kathryn Poe and Matt Stringfellow spoke about Agile Development. Kathryn and her Matt did a great job explaining how Agile development can impact those of us a the end of the waterfall, this is what I took away from their informational speech: 

Agile Development allows us writers, and software documentation specialists to have roleswithin product development- especially in the realm of software development, rather than below or after development roles. 

Documenting, writing Q.A. and developing basic marketing slicks or website text after a product is completed puts us in a bind. We are the last straw to getting a product to market, and as such in this role we are under the waterfall of the product deadline. If the development team falls short of meeting a deadline, whose time are they eating up? Most likely the person who’s job is put into the perspective of “just checking a checkbox”, or whose job is last on the to-do-list. The product documentation ends up being done in 2 weeks, for a product that took 2 years to develop- not cool!

I learned from a recent DFW-STC meeting, that Agile development allows the writers, documentation specialists, Q,A. people, and marketers alike to over come the waterfall effect that always seems to happen in a development schedule. 

The key, it seems to overcoming such an obstacle, is to document, while the product is being developed, by breaking up the development cycle into chunks. By developing one feature at a time until it is finished (feature has been bug tested, wired up with the GUI, documented, Q.A.’d - finished) you can come out from under the development schedule and join it. Developing in this manner is supposed to help keep the team afloat as well, by encouraging the meeting of shorter more concise deadlines, as opposed to only thinking about the end- that huge looming deadline 2 years in the future, (or however long) that the entire product is supposed to be configured. 

This type of development it seems, also causes less re-working, and re-configuring of features, because once a feature is finished it takes a lot more work to re-open it, and start over. It is much more work, and it makes a feature that was only supposed to get 2 weeks of development time, eat up 4. 

All in all, I think Agile is a pretty good option, if you have a development team large enough to work on one feature at a time, and still meet the end product deadline. I’m not sure what happens when you work in a very small development environment.

If you are interested in learning more about Agile Development please check out Agile Alliance the Agile Community Website or the book The Art of Agile Development.