Essay: Disadvantages and Limitations of Agile Development Processes

Abstract
In many organisations, Software developers and mainly project managers are scratching their head in confusion to grade the validity of agile processes to their very own development environment.
This assignment shall identify the limitations which may applicable to multiple versions of agile processes concerning the different type of projects for which an implementation or application maybe problematic. (Dan Turk, 2007)
Introduction
As technology advances, a lot more businesses are looking to get the upper hand in terms of competitiveness via efficient and time accurate application t of a Internet-based services. This causes developers to be under tremendous high pressure and anxiety to produce either new or enhanced implementation swiftly and quickly. (Dan Turk, 2007)
The main purpose for the development of Agile Software Development was to primarily address the difficulties faced to develope software ‘Internet Time’. Basically Agile Development processes approaches help to utilize technical and even managerial processes which constantly adjust and adapt to the following, (Dan Turk, 2007)
‘ Changes which were learned from mistake and positive lessons while during development
‘ Changes in the software requirements
‘ Changes in the development environments
Agile Development processes are actually meant to assist quick and early production of a working code. This is usually ascertained by restructuring the development processes into iterations. During this period the iteration focuses mainly delivering working codes which is off important value to the customer and project. (Dan Turk, 2007)
However Agile Software Development critics point out that concentrating too much on coding could lead to loss of history information due to the lack on emphasis on proper documentation and models to support software creation system and evolution of large complex system. (Dan Turk, 2007)
This paper shall now proceed to present what is perceived at limitation of Agile Development Processes.
Limitation of Agile Development Processes
Limited Support for distributed development environments
In development environments where the team members are not located at one location but are found in different parts of the world might have trouble adjusting to the face to face communication which is an requirement advocated by Agile development.
One alternative to such scenario is making use of face-to-face communication technology like video conferencing. However this is not really a perfect alternative due to the fact that these technology are often expensive and not really reliable. (Dan Turk, 2007)
Face-to-Face communication is just as important in a distributed environment as it is in a non-distributed environment. However its occurrence is lesser and one has to plan early to make sure that all the necessary participants are able to participate. (Dan Turk, 2007)
Face to face communication can be used during meetings where developers are geographically dispersed provided the developers are aware of each other progress and could discuss plans to further develop the project. (Dan Turk, 2007)
In such meetings, documentation and not code should become the main way of communicating. Proper documenting the necessary requirements and designs which are maintained and produce on time are very important and necessary to make sure that all the team members adhere to the same end goal of the product. However one should be careful not to misinterpret this as a requirement to model all the aspects of the software. Software and documentation should only be made if they have important value to the stakeholders or the project itself. (Dan Turk, 2007)
Limited Support for subcontracting
When an organization subcontracts out the task of software development to its subcontractors, it is often based on the scenario of the subcontractor being informed of what is required of him. The tasks which are to be subcontracted have to be well detailed and define due to the subcontractors need to bid for it. (Dan Turk, 2007)
During the period of bidding , a subcontractor would develop a plan which is inclusive of a process , with milestone and deliverable with sufficient details to estimate the necessary costs. Normally these process is iterative and a incremental approach. However in Agile Development process a subcontractor may have to take the risk and try to be predictive of the process by trying to specify the number of iterations and the deliverable required to finish the project. (Dan Turk, 2007)
It is actually feasible for a contract to be drafted in a way which allows subcontractor a certain flexibility in how could deliver the product the necessary price and time limitations. This would certainly be a good idea or approach if the subcontractor is known to have a good track record and is trusted by the contracting company to be able to produce a product according to their criteria.
Basically a contract which should be able to support the subcontractor environment in an agile development should consist of the following, (Dan Turk, 2007)
Fixed Part
This part defines,
‘ The necessary limitations and frameworks on how the subcontractor will intend to implement changes in to the product related to time and cost based criteria
‘ activities like quality assurance which must be carried out by the subcontractor
‘ requirements which are considered to be fixed together with deliverables that must be delivered
Variable Part
This part would define the necessary requirements and deliverables that could vary within the scope or limitations in the Fixed Part. This part would also be able to adapt along with the constraints which are found in the Fixed Part. During the singning of the contract, it is necessary that a description of the important deliverables and important requirements are included. (Dan Turk, 2007)
Limited Support for building reusable artefacts
Basically Extreme Programming which is a process of agile development often concentrates on implanting software products which are aimed to handle a specific issue. When developing during ‘Internet Time’ usually involved developing a general solution even though it might be clear that this could produce benefits in the long run. (Dan Turk, 2007)
It is best that in such environments projects which are affected by the development of reusable artefacts should be handled with generalised solutions. This specific segregation of product-specific development vs. Artefact development is an important feature of a framework known as ‘the experience factory'(Dan Turk, 2007)
It is a requirement of a reusable artefact applicability that emphasis on processed used should be concentrate on quality control. This is due to the fact that the impact of a poor quality is as huge as the number of application that actually reuse the artefact.
While it is possible for agile development to be applied to the development of reusable artefacts , it is actually clear now on how Agile processes could be compatibly adapt.(Dan Turk, 2007)
Limited Support for development involving large teams
Basically Agile Development Processes supports ‘management ‘in-the-small’ processes in which the control, coordination and communication mechanism are used in a small to medium sized teams. With a large team, the number of communications lines that needs to be maintained or supervised can reduce the efficiency of practices like face-to-face communications. Basically larger teams actually require fever agile approaches to handle issues relating to ‘management-in-the-large’. In fact traditional engineering practices which pays more emphasis to documentations, change control and architecture-centric development are more suited to ‘management-in-the-large’ rather than agile approaches. However this does not eliminate the possibility of agile processes being applicable in a larger team environments, it would just be less used than in small teams. (Dan Turk, 2007)
Limited support for developing safety-critical software
A software in which failure would end up in direct harm to human or have heavy effect on economical damage is known as a Safety-critical software.
The mechanism dealing with quality control which is provided by agile processes (pair-programming and reviews which are informal) have yet to be proven to be sufficient to users that the end product is actually safe. In addition there is a huge concern if that these methods alone are sufficient. (Dan Turk, 2007)
Rigorous test coverage, formal specification and various other formal evaluation and analysis technique found in software engineering approach actually provide efficient but more expensive mechanism to handle the development of a safety-critical software. In fact some agile processes could prove to be an advantage and useful to the development of such software. (Dan Turk, 2007) .
They are as follows,
‘ test-first approach which requires one to actually define the unit tests before coding
‘ An early production of a working code which is supported by the increasing and iterative processes structure of agile processes which assists exploratory development of a critical software when the requirements are not actually well-defined.
‘ Pair-programming can actually be an productive action to formal reviews
Based on the above points, it can be said that both agile and formal evelopment can work together or be combined as and when deemed necessary. In order to keep critical pieces of software which could boost confidence and quality , formal techniques should and can be used in an agile way. (Dan Turk, 2007)
Commitment
Productive user involvement together with close teamwork are essentially a must throughout the whole development cycle. In fact these are very interactive, produce good rewards and even ensure submission of the right product. The very fundamental principle in agile processes are the very factor that ensure expectations are adhered to. Since the very basic definition of failure is not to meet expectations, it is a very critical success factor for any project. Unfortunately these principles are very costly and tend to put a huge amount of pressure on the user representative’s time and indefinitely require a large amount of dedication and lots of commitment as long as the project is not completed. (Waters, 2007)
Frequent Delivery of Product
Occasional submission of the product and the constant need to validate every single feature before moving on to the next actually makes the User Acceptance testing very vigorous and time consuming. The users need to be on constant standby for fast and efficient testing of the features as they are presented all through the duration of the project. Although this helps to ensure quality product is delivered, it proves to be too much of a time consuming method. (Waters, 2007)
Immediate Feedback Resulting to Scope Creep
With instant feedback capabilities that comes while using agile approaches, the potential of scope creeps come in. End users who actually see that their requirements are easily met will only see the result and not the effort put into meeting those expectation and will ask for additional features. In a scenario of project managers and developers not being able to manage the end user expectations, the end users would just keep flooding the entire agile team with additional work. This could amount to a lot of pressure and could reduce the efficiency of the developers. (Barett, 2012)
Limited Support for developing large, complex software
Assuming that code refactoring actually negates the importance to design to be prepared for a change would not necessary sustained for bigger complicated systems. Usually in software like this most of the time there are critical architectural aspects which may prove to be hard to change amend to the important role they actually have in core services provided by the system.
In scenarios like this, amount of money used to change these aspects could prove to be very expensive and therefore it would actually pay of to make effort to predict changes early. The thought of relying hugely on code refactoring could be a big problem for such system (Dan Turk, 2007)
Conclusion
It may appear that there are many software development project which succeeded using agile approach. However most of these stories so far are anecdotal. In general certain some angle of software development could benefit from agile development while others could use less of it. From this very thinking , software development processes which are practical can actually be categorised based on the dependence on their level of agility.
In other words agile processes in not a one shot fit all kind of process. It a process with is more suitable to a small team with no physical geographical distant (teammates are all nearby and not in various countries etc). With agile development constantly putting pressure on team mates due to constant demands from clients, it is very essential that a program manager is able to handle the client.
Overall agile process is a method that could use further development and be tweaked closer to perfection.