CSC/ECE 517 Fall 2010/ch6 6d ub

Limitations of Agile vs. other software-development methods

Agile software development is a group of software development methodologies based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams.¹

Developing a fairly large or a small software project involves some planning. Though there are proponents of the sit on the computer, code and be done with it approach, it hardly works for projects as their complexity, both in terms of deliverable and resources increases. There are numerous ways in which a software project is planned and executed. From the more classic and orthodox models like the waterfall model to the newer XP philosophies such as Agile and Scrum, these methodologies are different ways of achieving the same goal, each with its pros and cons.

Agile is an iterative method of software development wherein the software development is done in terms of multiple stages which may/may not build upon each other. At the outset of the project, the various user requirements are gathered and split up into various such relevant stages which are completed one after the other a reviews done. Due to its iterative nature, agile allows for dynamic project scope and development with a high degree of user interaction. In comparison to more orthodox and classical methodologies, Agile can be looked upon as a combination of spiral module with a waterfall module which is executed in each spiral of software development.

As mentioned in the description of this wiki, the paper by Hoda et al 'Agility in Context' ², though Agile looks as a excellent method to carry forward and execute various real world software development problems, there are many limitations and modification that are needed to its methodology for use in real world scenarios in many cases.

Agile and its strengths

Agile due to its iterative nature is based on a system where each iteration takes into account some of the user requirements and code is developed based on those requirements. Based on user feedback, any changes if necessary are made to the code in subsequent iterations. This makes Agile projects highly adaptive to change in specifications as compared to more classical models.³K. Beck. Extreme Programming Explained: Embrace Change. Addison-Wesley, 2000. Agile also is very customer centric, where client feedback at the end of each stage is essential in work on next iteration. Also, a high degree of involvement from the customers is needed to create specifications that can be rightly mapped to the priorities and split up into iterations at each stage of the agile project. Agile is also a proponent of highly integrated and synched teams. This is due to the highly dynamic and iterative methodologies used in Agile. It is these strengths which are a limiting factor in many of the projects which do not implement on one of the above features by the book, and hence need software development to be carried out by some modified Agile methodologies which take features from some classical development models.

Unorthodox Agile Models

Customer 'Proxy' or 'Story Owner'

Agile requires a high degree of customer interaction both in getting specifications and also for validating development in an iteration. However, it is seen that in many cases, the customer expects software projects to deliver like more conventional projects wherein a high requirement overview is provided and the development team is expected to complete the project and give it in one go to the customer. This is not at all beneficial in Agile development methodologies where a more detailed specifications description is needed from the customer and also a feedback needed in every iteration. Where a customer is very not forthcoming, a customer 'Proxy' is made from within the development team who is responsible for being a liaison with the customer to get a more established way of communication. Also certain 'Story Owners' are designated for each iteration of the project. These members of the team who are 'Story Owners' who were responsible for the requirements gathering and feedback of a specific iteration by acting as a limited time liaison between customer and the development team. Such a story owner was responsible for a story in only a specific iteration or stage of the project. Agile Undercover: When Customers Don’t Collaborate⁴

Offering Iterations or Buffering in Fixed Bid Contracts

It is seen that the classic customer just gives a fixed bid contract with specifications and expects the development team to deliver a product within a quoted fixed time. A Agile development team in this case can make use of iterations to have a more balanced and co-ordinated development of project instead of having a solitary fixed deadline by allowing the customer to buy fixed iterations of a given project and continue with further iterations if they are happy. Also, some teams will provide a buffering period over estimated completion time to provide for Agile process iterations while negotiating such a contract.

Staggering iterations in case of Design/Architecture intensive projects

In case of projects which are design/architecture intensive, it has been seen that staggering iterations is better in case of team which do design viz a viz development. This is because there exists a pipeline structure in the project which actually makes one team a customer of the other, and a simple Agile methodology of requirements gathering and verification on each iteration follows for each of the individual teams.

Documentation intensive Agile projects

In some cases, it was seen that documentation was necessary as a part of requirements of the project, or in the case where it was necessary to have a single repository of terms familiar to the customer and their mapping to the terms essential to the developers. (Data Dictionary). this involves an undercover agile approach where the output in form of documentation is done in the classic waterfall way, while the development is still Agile. This however, needs careful mapping of the documentation goals to the Agile goals.