In my latest incarnation as a programmer, I often come across the term Agile Developer or even the even more sinister, “are you an agile developer?” which often evokes images of someone on an obstacle course, weaving his/her way through.  Being very unlike this image in my mind,

This movement of “Agile Developers” which has been born in the last few years, has come about as a result of the Project Management Fraternity, rather than the Development fraternity.  To make the point, refer to the “Manifesto for Agile Development”.

In the manifesto, there is no mention of project management, no mention of timelines.  It is instead a set of principles, which each developer should adopt, with the aim of producing better software and better software products.

In the last few years, working closely with teams who were so called “agile”, I had an opportunity to carry out an interesting experiment.  in the first team, Team A, a team of business people were tasked with creating a detailed requirements specification as would be done in any self respecting “Waterfall” shop. We then moved into an architecture phase, where we built a complete system architecture and then initiated the development process using an Agile methodology.

In the second team, Team B, we took a much leaner approach, we had a high level view of the requirement, with the critical business rules and the development started in earnest using an Agile Methodology.

Both teams had the luxury of intimate business involvement throughout the development process.  Both teams deviated significantly from the original. Requirement with Team B evolving both the specification and architecture as the project proceeded.

Team A had to go through a process where any architectural change underwent had to go through a formal process with an architect, while business changes were handled as part of the Agile process.

Team B had a lot more freedom and architectural changes were made as required or business as requirements demanded it.

Logic and the industry would suggest that the team who would make the greatest headway would be Team B, with its ability to adapt, change and evolve as the requirements evolved, and that they would by far outperform
Team A.

Team A was able to deliver the system, on time under budget and produced a system that met the business requirements.  The technical debt and any architectural or design compromises were documented and disclosed.

Team B was less successful, and the architecture is less robust, compromises or decisions that were taken were often not documented as they were seen to be “part of the implementation” rather than a change/compromise of the architecture.  The team missed a number of deadlines and a significant amount of development time was spent refactoring the system to meet the evolving business requirements.

Both projects had a similar complexity profile.  Team B had an advantage in that they had developers who were both  familiar with the domain and had had previous domain experience supported by a business with extensive domain knowledge.

Team A on the other hand had a business with extensive domain knowledge but none of the developers mployed were familiar with the domain.