Friday, November 16, 2012

Criticism's of Agile Development by Dennis et al

In their book "Systems Analysis and Design with UML" 4th Edition, Dennis et al discuss Agile Development, and mention the following criticisms:
  1. Today's business environment, where much of the actual information systems development is offshored, outsourced, and/or subcontracted does not fit well with agile development methodologies requiring co-location of the development team
  2. If agile development is not carefully managed, and by definition it is not, the development process can devolve into a prototyping approach that essentially becomes a “programmers gone wild” environment where programmers attempt to hack together solutions
  3. A lack of actual documentation created during the development of the software, raises issues regarding the auditability of the systems being created. Without sufficient documentation, neither the system nor the systems-development process can be assured.
  4. It is unclear whether agile approaches can deliver large mission-critical systems
My immediate reaction to point 1 is "Google Hangouts", "Skype Screenshare" etc.  It seems to me that one can work almost side by side with other people around the world now.  Regarding point 2, I think this is a danger for all software projects.  I don't know that I agree that agile methods are not carefully managed.  It would seem to me that careful management is an orthogonal issue to agile development.  You can have a large waterfall development process that is not carefully managed, and ends up generating reams of useless documentation, and you can have a carefully managed agile project that keeps the developers talking to the customers, and any documentation generated carefully in step with needs and software alike.  

Regarding point 3 agile methodologies emphasize working software over documentation, but that doesn't mean there should be no documentation.  Dennis et al appear to be arguing that some critical mass of documentation is required in order to perform an audit, and assure the system and systems-development process. I don't see why this should be the case.  Surely an audit can be performed on a working system as well as on documentation.  Futhermore, isn't the bigger danger that one has lots of documentation that is unrelated the actual system or indeed the actual needs of the users.  In this case what does the documentation help us assure in terms of the system or systems development process.

Regarding point 4 this seems like a open question.  One might well argue that large payroll systems, or systems like the mars rover must be developed much more carefully than a social media app for a mobile device, but in all cases if the resulting system fails to meet user needs then there are no winners. Personally. I am skeptical that the big design up front waterfall model necessarily produces good results on large mission-critical systems.

To be fair, Dennis et al go on to say:
Even with these criticisms, given the potential for agile approaches to address the application backlog and to provide timely solutions to many business problems, agile approaches should be considered in some circumstances.
So all credit to them for including the agile ideas in their systems analysis textbook.

No comments: