Agile Development

This will be the first post of many touching on Agile Development.  As such, it will be more of a general introduction to the environment I have been exposed to and a launching point for later posts.  This is my first time working in an Agile Development environment and I have now been embedded for three months at a client that underwent a transformation to Agile Development (from Waterfall) over the course of the last year.

They went all-out with their transformation and:

• replaced all cubicles with team islands created from tables that are bolted together
• populated the room with a plethora of white boards for use in spontaneous discussions
• discarded the generation and use of documentation (from high-level documentation to commenting in code)
• adopted pair-programming
• adopted the practice of embedding the business analysts with the developers at the team islands
• adopted test-driven development
• adopted "clean code" practices
• adopted the use of card walls for feature and defect tracking
• adopted the use of weekly iterations (commitments, demos, and retrospectives) and monthly deployments to the production servers
• ensured high levels of accessibility to the product owners (members of the other departments for which the products were being written)
• adopted the use of daily stand-up meetings attended by the team and the product owners
• adopted the practice of having value stories from the product owners approved by a steering committee prior to work commencing on those projects/sub-projects
• adopted the practice of allowing the product owners to prioritize story cards (individual features or pieces of features) to be worked at the start of each iteration
• adopted the practice of encouraging the team to continuously question whether every feature/meeting/etc. is truly providing a value to the business that is greater than the amount that would be spent on development

So far, I have a very positive opinion of Agile Development (I think it is doing a lot of things "right" and there are many aspects of it that I think are excellent improvements over traditional Waterfall), but I have seen several weaknesses so far:

• Because the majority of the design is done by the pair working the story card, it seems to require that the team be composed of mostly senior-level developers and for weaker developers always be paired with stronger developers.
• If any team members are unwilling to embrace an Agile environment, the success of the team will be crippled.
• The lack of documentation and comments will likely cause maintenance headaches down the road (2+ years out).