I have read a couple of books and several articles about the agile development approach. What was funny to me is that there was a necessity for entire books on this topic; as I understand it, this boils down into some simple concepts, and these are the ones which I can apply in my shop:
- Produce a quality product
- Focus on the work that provides immediate and tangible benefits to business partner
- Streamline project lifecycle
- Structure a project team consisting of project manager, designers, software engineers, quality assurance and business partner.
- Break the project down into small, independent functional components.
- Create tools for testing these components in isolation (prototype).
- Categorize project components into independently installable phases.
- Schedule regular brief status meetings with the development and testing team to review bugs, identify obstacles, and establish action items to be addressed before the next meeting.
So why the proliferation of literature? Why the rhetoric, the nomenclature, the rules, the standards?
Each project needs to be analyzed to determine how best it can be implemented. The methods above are general; the specifics may include partnering developers, ice cream breaks, group offices, isolated cubicles, a combination of formal design followed by a prototype, a daily meeting, brainstorming meetings at Starbucks. In other words, there is no single formula to follow. Some of the terminology still sounds nuts to me – a scrum, for example, sounds vaguely pornographic (maybe that’s because there is a full moon tonight?) – and when dropt in conversation rather screams an elitist attitude lacking in substance. However, I can respect the variety of Lean Software Development, eXtreme Programming, Test Driven Development and other specific agile approaches as potential methods to gain the road when it winds so precariously before me.