The Server-Side Pad

by Fabien Tiburce, Best practices and personal experiences with enterprise software

Agile Yes, But Not Without Documentation!

with 4 comments

Agile software development is a methodology that relies on small iterations and frequent releases, teamwork and collaboration.  Agile development embraces change as the rule not the exception. It is generally nimble and adaptive.  Agile typically favours face to face communication to documentation.  Agile measures success according to working software (hence the importance of rapid prototyping), not abstract (from a software end-product standpoint) project milestones.

By putting the emphasis on the end-product, on collaboration and by embracing change, the agile methodology is perhaps the best software development methodology available today (for most projects).   We use some form of agile development and project management on virtually all projects.  One size does not fit all however.  I  sure hope the avionics of the plane I am flying on were not developed by a team who believes that paper specifications and formal documentation were unnecessary project overheads.  Yet most projects, even the largest and most complex (perhaps better served by the waterfall method), benefit from adopting some agile principles.

My biggest concern with strict agile is the insistence on human interactions over documentation, as if one was a substitute for the other.  Take requirements analysis for example (a topic recently covered in a LinkedIn Q&A).  Gathering requirements is an iterative process, a series of passes. After each pass (a discussion, interview or meeting with stakeholders), requirements must be documented and compiled.  Provisional conclusions and principles are drawn. At the next meeting, it is important to review and vet the requirements, assumptions and principles as understood and documented.  This will typically elicit further qualifications and uncover other requirements and assumptions. The process requires multiple iterations, each advancing the requirements-gathering further towards finalization. The process goes on until all parties believe they have exhausted all qualifications and that the requirements, as documented, fully encapsulate the business, functional and technical needs of the particular feature or component being discussed.   This does not mean the specifications are ever “final” or set in stone (one of the biggest arguments against the waterfall method.   “finalizing” requirements assumes changes are the exception not the rule).   It does however support the idea that documentation is an extension of the collaborative thought-process not a substitute for it.   I believe without this important qualifier, the agile methodology cannot scale to large and complex projects where dependencies, complexities (business rules and complex processes) and risks abound.  

In conclusion, I believe the agile methodology to be sound and effective, cost and otherwise.  But documentation does not undermine the methodology, it makes it better.

Advertisements

Written by Compliantia

February 24, 2009 at 3:59 pm

4 Responses

Subscribe to comments with RSS.

  1. First comment- I think your points are VERY valid in the climate of most people starting agile in a new organization and in today’s climate of agile terminology flinging and over-hype.

    Second comment- I don’t think that the original manifesto signers felt that conversation is a substitute for documentation. (Actually, I know this having talked to or read material by more than several of them.) What you are saying was exactly their point. The manifesto clearly states that documentation is valued, but conversation is valued more. (Hence your important qualifier is already built in, people just overlook it!) What they were really trying to combat was the old-school philosophy of writing a set of requirements, believing it was done and pitching it. This lack of review and collaborative thought always led to a breakdown and finger pointing somewhere later in the process.

    So… almost totally agree. Good post. Just didn’t want the assumption out there that the core movement believes in the substitution point.

    Kevin E. Schlabach

    February 25, 2009 at 4:49 pm

  2. […] III: Be agile.   Don’t fight change, embrace it.  Focus on the user experience.  Try rapid prototyping and commit to frequent releases.  Be nimble, be agile. […]

  3. […] your target.  Software engineers are worth every penny you pay them.  Expensive?  Just adopt an agile methodology and ensure most of your dollars are going towards the end product not superfluous […]

  4. I’m all about requirements engineering and sound system documentation, UML, etc. The question is, how much analysis can be done upfront, means before starting implementation. Iterative requirements engineering without starting implementation will never capture all requirements. It’s just too theoretical for people. Business people need to see.

    So I think analysis and design documentation should be part of the tasks in a sprint or even mentioned in a product backlog. Standards of the content and form need to be defined as it fits a project/company.

    Christian

    April 21, 2009 at 9:34 am


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: