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.

Agile Processes in outsourced projects

In outsourcing environments, Agile processes need to be modified to a great extent to suit highly decentralized nature of such projects. The major challenges seen in such projects are the disconnect between the locations of the customer and the development teams. Also, it is seen that there is a obvious difference between the managements of the client and the customer as both of them are different entities. Agile practices are modified in such situations by providing for certain specific teams both at the client and outsourcing ends whose main job is to communicate between both organizations. The client team in this case is responsible for overseeing the outsourced work at regular intervals besides communication. At the outsourcing end, the developer team responsible for communication is tasked with ensuring the definition of correct and specific goals to the development teams. Also, a specific documentation format needs to be developed to better translation of user requirements to developer specs. ⁵

Strengths of More classical Approaches in Software Development

More classical approaches as mentioned above are beneficial in specific situations. ⁶

Waterfall Model

For example, a waterfall model is better in case of more classical projects where all the requirements are made clear beforehand. The whole development process in this case is highly documented and planned with little or no need for modifications. In such a project, the developers have assumed to have worked on such projects before and have a clear idea of what the development process should be consisted of.

Spiral Model

The spiral model is beneficial in cases where there needs to be various stages in the project, still predefined, and there needs to be a delivery at pre specified stages in the project as per pre defined guidelines. This allows for a better structure for software delivery in specific cases. At each spiral stage, the user or customer is taken into account to get his feedback on the features developed during that stage.

Iterative Models

Certain iterative processes are used by development teams to arrive to a final shape of a software when the customer is not sure of the requirements of the software. In this case, the software developers take an incremental approach wherein at each stage, some specific needs of the customer are met and delivered and the customer asked for further requirements as needed.

Top Down or Bottom up Models

These kinds of models value the concepts of modularity and integration for development. In a top down model, the basic skeleton containing modules is developed first and subsequent detailed modules developed after that. The case is different in bottom up approach where the individual modules are developed first and then integrated to get final system.

Rapid Prototyping

Rapid prototyping uses the iterative approach wherein with high level understanding of the users requirements, a basic prototype is created, which is then refined with each subsequent phase to impart more and more functionality as per fined grained requirements of the user.

As its evident, the Agile method can be tweaked in various ways to achieve the functionality of each of above development models if needed.