A Study On Agile Software Development Business Essay

Published Date: 23 Mar 2015

Agile software development is a group of methodologies whose basis is iterative development. The requirements and solutions in this develop through collaboration between self-organizing cross-functional teams. Agile methods usually endorse a well-organized project management process that promotes many inspection and adaptation. It endorses a leadership philosophy that encourages teamwork, self-organization and accountability, a set of engineering best practices intended to allow for rapid delivery of high-quality software, and a business approach that aligns development with customer needs and company goals. Agile methods promote an iterative mechanism for producing software. They further enhance the iterative nature of the software lifecycle by tightening design-code-test loop to at least once a day (if not much more frequently) as opposed to once per iteration. The theoretical foundations of this framework are found in modern approaches to operations management and analysis, such as lean manufacturing, soft systems methodology, speech act theory (network of conversations approach), and Six Sigma.

Agile Vs Waterfall

Waterfall Model: The Adoption of waterfall has helped to drive down the failure rate of software development projects, but even with rigorous project management and processes, a full 70 percent of software projects using this methodology fail to meet their objectives. To put this in perspective, waterfall software projects have less than half the success rate (66 percent) of going over Niagara Falls in a barrel.

Figure: The waterfall process for software development

Agile approach differs from Waterfall in more than one ways, however the major point of difference is that in the waterfall process there are several checks carried out in phases and the team is expected to deliver a particular part in each phase, however in agile the team is expected to carry out their project in iterations instead of phases. At the end of each iteration, the deliverable expected is a working code that can be continuously improved in order to cope up with the ever changing needs of the demanding client. However, in case of Waterfall, it is assumed that all the needs and requirements of the client are known precisely right at the beginning of the project. Alibi the software development industry is such that , it is often very difficult to understand the exact requirements of the customer at the beginning of the project. This is the major shortcoming of waterfall, where the development team is seldom able to meet the expectations of the customer. Agile methodologies embrace iterations. Small teams work together with stakeholders to define quick prototypes, proof of concepts, or other visual means to describe the problem to be solved. The team defines the requirements for the iteration, develops the code, and defines and runs integrated test scripts, and the users verify the results. Verification occurs much earlier in the development process than it would with waterfall, allowing stakeholders to fine-tune requirements while they're still relatively easy to change.

1. XP

Extreme programming mainly focuses on the development; it does not lay too much emphasis on the management perspective of the software projects. The main purpose with which XP was designed was that all organizations could adopt it for free in its entirety or partly.

XP development

The XP project begins with the initial planning stage. This is followed by a huge number of iterations, and the product continuously improves with each iteration, the conclusion of each of these iterations is marked by the customer's acceptance. Finally, when the user is satisfied with the software and all its features meet the customers' expectations, then the iterations are stopped and the team delivers the final software to the customer. Users write "user stories" to describe the need the software should fulfil. User stories help the team to estimate the time and resources necessary to build the release and to define user acceptance tests. A user or a representative is part of the XP team, so he or she can add detail to requirements as the software is being built. This allows requirements to evolve as both users and developers define what the product will look like. To develop the plan for release, the project team fragments the entire project into many iterations. The plan clearly explains each iteration and the tasks to be carried out in that particular iteration. After each iteration, the users conduct tests to check their acceptance by matching the results of the iteration with the user stories. In case, the users find any bugs, then the task is cut out for the team to remove those bugs in the next iteration.

Iterative user acceptance testing, in theory, can result in release of the software. If users decide that enough user stories have been delivered, the team can choose to terminate the project before all of the originally planned user stories have been implemented.

Figure 5 shows a simplified version of XP.

XP rules and concepts

The most important concepts are given below:

· Integrate often: Development teams must integrate changes into the development baseline at least once a day. This concept is also called continuous integration.

· Project velocity: Velocity is a measure of how much work is getting done on the project. This important metric drives release planning and schedule updates.

· Pair programming: All code for a production release is created by two people working together at a single computer. XP proposes that two coders working together will satisfy user stories at the same rate as two coders working alone, but with much higher quality.

· User story: A user story describes problems to be solved by the system being built. These stories must be written by the user and should be about three sentences long. User stories do not describe a solution, use technical language, or contain traditional requirements-speak, such as "shall" statements. Instead, a sample user story might go like this: Search for customers. The user tells the application to search for customers. The application asks the user to specify which customers. After the user specifies the search criteria, the application returns a list of customers meeting those criteria.

Because user stories are short and somewhat vague, XP will only work if the customer representative is on hand to review and approve user story implementations. This is one of the main objections to the XP methodology, but also one of its greatest strengths.

Scrum

In rugby, 'scrum' (related to "scrimmage") is the term for a huddled mass of players engaged with each other to get a job done. In software development, the job is to put out a release. In software development, scrum emerged out of rapid prototyping community, due to the need of a methodology for prototypes that would be supportive in an environment where the initial requirements are not complete and precise at the start, and also keeps changing continuously during the development phase. Scrum differs from XP because it not only includes the development process but also lais emphasis on the managerial aspects.

Scrum management

In the middle phase of each Scrum project, there is always a lot of piled-up work. This backlog gets accrued mainly during the planning phase of the release and the scope of release is mainly defined by this. After the team completes the project scope and high-level designs, it divides the development process into a series of short iterations called sprints. Each sprint aims to implement a fixed number of backlog items. Before each sprint, the team members identify the backlog items for the sprint. At the end of a sprint, the team reviews the sprint to articulate lessons learned and check progress. During a sprint, the team has a daily meeting called a scrum. Each team member describes the work to be done that day, progress from the day before, and any blocks that must be cleared. To keep the meetings short, the scrum is supposed to be conducted with everyone in the same room-standing up for the whole meeting.

When enough of the backlog has been implemented so that the end users believe the release is worth putting into production, management closes development. The team then performs integration testing, training, and documentation as necessary for product release.

Scrum development

The Scrum development process concentrates on managing sprints. Before each sprint begins, the team plans the sprint, identifying the backlog items and assigning teams to these items. Teams develop, wrap, review, and adjust each of the backlog items. During development, the team determines the changes necessary to implement a backlog item. The team then writes the code, tests it, and documents the changes. During wrap, the team creates the executable necessary to demonstrate the changes. In review, the team demonstrates the new features, adds new backlog items, and assesses risk. Finally, the team consolidates data from the review to update the changes as necessary.

Following each sprint, the entire team-including management, users, and other interested parties-demonstrates progress from the sprint and reviews the backlog progress. The team then reviews the remaining backlog and adds, removes, or reprioritizes items as necessary to account for new information and understanding gathered during the sprint.

Figure 6: The Scrum process

Scrum concepts

Here are a few of the most important concepts:

· Burndown chart: This chart, updated every day, shows the work remaining within the sprint. The burndown chart serves the dual purpose of tracking the progress in sprint and also helps decide on when the items need to be postponed from the current sprint to the concurrent sprint.

· Product backlog: It provides a comprehensive list of all the requirements, including the bugs to be removed, the enhancement requests made by the user, usability suggestions, and overall performance improvement which does not form a part of the current product release.

· Scrum Master: He is responsible for the management of the entire project. A person can also be certified by attaining training from an existing Scrum Master.

· Sprint backlog: It gives a list of all the backlog items assigned to a sprint, but not yet completed. Commonly, any item which appears on the sprint backlog is cleared off within two days. This acts as a performance meter for the team, and gives an indication about the amount of effort that needs to be put-in in order to complete the sprint.

AGILE SOFTWARE DEVELOPMENT IN INDIA:

Agile software development is a fast growing technique which is being adopted by many companies in India. Microsoft, Google and Yahoo! were among the early practitioners of agile methodologies, however, now agile technologies are being adopted by big, non-software corporations like British Telecom and Ericsson, who have been enterprise IT customers, says Anurag Shrivastava, MD, Xebia India. There has been an exponential growth since 2004. Presently, many of the biggest names in software have initiated projects that use agile software while others are using agile in some way or the other in their projects. It has become easier for the smaller sized companies to adapt to agile while the bigger ones are slowly getting to it. The highest number of companies practicing agile are located in the silicon valley of India i.e. Bangalore . However, eventhough the number of companies with understanding of agile is more in Bangalore, the other metros and bigger cities too are catching up. E.g The companies in Mumbai, Delhi, Pune, Hyderabad etc.

Adoption of agile software has become rampant in various companies having presence in product and service categories. Time to reach the market and efficiency enhancement are the key factors that are driving the rate of adoption. In short, there is internal motivation. In case of services, the key factors driving adoption rates are peer pressure and competitive advantage which basically means there is external motivation .

Agile methodologies (Extreme Programming, SCRUM) have started getting wider acceptance in the software industry and in many cases, customers insist on going the Agile way for various reasons.

In the traditional software development process, customers get the view of the software at a pretty late stage and it might no longer fit their real and changing needs. Agile promotes a more collaborative model for software development with significant and frequent interactions between the customers, developers, and stakeholders.

In the SDLC waterfall model, requirement gathering and analysis is the first stage, and then the product is developed. It hardly leaves a scope for requirement changes in the later stages. Agile welcomes requirement changes even at the later stages in the development cycle.

Many times, customer has a vision about the software but does not know the end points. In Agile, he could get involved in the development process at regular intervals and go on refining the vision even through few changes in the requirement. In few domains where business scenarios are changing fast, Agile could be a better and faster way to come out with quick software to fulfil immediate requirements.

This view point can be also be observed from the talk of Ramana Rao, VP of Engineering Q3 Technologies where he shared his opinion on Scrum and Agile development methods used by Indian software companies. "I think Scrum and Agile development methods have started making their mark in India. As a matter of fact, many companies have started moving away from the traditional Waterfall model. The change is imminent as customers start getting unequivocal in their demand of "quickly watch things working". Companies will be successful as long as they are able to manage shorter learning curves, impose strict quality guidelines within constantly dwindling development iteration's and at the same time reduce rework."

Recently there have been a lot of talks concerning the integration of offshore programming and agile software development in order to mitigate the disadvantages associated with offshore programming. "offshoring" of software development option has attracted attention due to some relative and perceived benefits of cost effectiveness, timely services, and rapid access to various technical capabilities for increased productivity. Agile programming methodologies such as Extreme Programming (XP), Scrum, DSDM, Test Driven development (TDD) are ideally suited for offshore development. Well-planned milestones, frequent iterations and close involvement of the client in the development process ensure that the software development team is always on track. Any deviations from the expected track are corrected early in the development cycle.

India being one of the preferred countries for offshoring, agile software development has become even more relevant to the software companies here. This is also shown in the recent report by Forrester which says "IT organizations must optimize their processes to better support the business, reduce costs, improve quality, and improve time-to-market. Many have turned to offshore outsourcing or Agile application development processes to help address these challenges - but not both. Indeed, given Agile methodologies' intense developer/customer interaction and light documentation requirements, the two approaches seem diametrically opposed. However, companies that master the complexity of merging the two types of approaches can further reduce costs and also improve their ability to communicate with remote development resources, a challenge for all companies doing offshore outsourcing. The result? Companies doing offshore work can better meet their customers' needs, and Agile development teams can cut costs."

For the purpose of integration and sharing of the information among the companies that are planning to use Agile software development and those that have already implemented the technique, Agile Software Community of India (ASCI) was formed. ASCI, today is a registered society founded by a group of agile enthusiasts and practitioners from companies that practice Agile methodologies. ASCI was basically initiated as a forum for software professionals from various organisations to meet and share various experiences regarding software techniques and methodologies. The key focus in case of ASCI is Agile methodology and related light weight methodologies. ASCI is considered as an institution that facilitates and supports light weight methodologies' innovation for software development. ASCI has collaborated with various universities and schools to increase awareness related to agile software within the academic sphere. So far ASCI has been successful in organising various workshops and corporate conferences on agile software in various parts of India. The basic aim of these workshops is to increase awareness of Agile in India.

The various companies which work in the field of Agile Software Development and have been an active part of ASCI are

ThoughtWorks Subex Systems Curam Software BNP Paribas India Solutions

JKT IRIS Spectra Force TataConsultancy Services

Global Logic Novell Cordys Saviance Technologies

Conchango Virtusa CDC Software

Pragati Software Pvt. Limited

First ECG Tieto Enator

Infotech Global

Brainwave

Xebia R Systems

Agile at Tech Mahindra Ltd.

Tech Mahindra Ltd. (TechM) formerly known as Mahindra British Telecom (MBT) is an Information Technology service provider company headquartered in Pune, India. It is a joint venture between Mahindra & Mahindra Limited (M&M) and British Telecommunications plc (BT). It is the 5th largest software exporter in India (Nasscom, 2009) and 1st largest Telecom Software Provider in India (Voice & Data, 2009).

British Telecom: The Client

British Telecom is also one of the key clients of Tech Mahindra. The company was successfully delivering large and complex solutions in a dynamic time frame, but failing to deliver the results in an acceptable timeframe. Reinforcement of the current technology (BT used waterfall practices to serve its clients) was not the solution as some of the problems faced by the company stemmed from the waterfall lifecycle.

To overcome the current bottlenecks and problems in the current systems, the company needed iterative and incremental (evolutionary) approach to software development. They needed self organizing teams with only that level of governance and control that could propel them to deliver cost effective and time bound solutions to changing needs of the client. Agile development offered these and hence British Telecom decided to "go" Agile and develop and deploy the system with its Indian JV partner Tech Mahindra.

Development stage

Tech Mahindra primarily employed its resources to develop Agile software owing to increasing client demand for implementation.

Training

For implementing Agile, training sessions were conducted for at two stages. The first was training the Managers who would become Project leads for developing the Agile solution in the future. The second was training the software developers. Contrary to the common perception that training in Agile requires extensive training, the Company conducted 3 day training sessions for developers and 3 + 2 day training sessions for managers. The extra two days of training was focused inspiring waterfall managers to become Agile managers.

Developing Agile system

Agile systems performed in a highly collaborative manner by self-organizing teams. To reap the maximum benefits of the system in the shortest span of time and in the most effective and efficient manner, Tech Mahindra decided to implement it through matrix structure.

Daily meetings: Daily meetings were conducted to have a feedback on last day's goal and new goals/deliverables were set for the following day.

Weekly deadlines: The code prepared by the developers was tested with the client on a weekly basis and hence improvements were made at a week's interval.

Pilot Phase: The projects were divided and worked upon in stages. Each of these stages at Tech Mahindra had a Pilot Phase. This essentially meant that a no frill model was first tested with customer and then if qualified by the client frills were added later.

Stress on documentation: With an aim to standardize the entire process, an increasing effort was made to document the entire process - at every stage and at integration level.

Implications

Financial costs and benefits

The highest cost involved in the project was the cost of implementation. This cost was borne by the client, British Telecom. Since training involved 3 (or 3+2) days of training the training costs were pretty low. When looked at these costs with a longer time frame, it was discovered that implementing Agile ended up as being a cheaper option as cycle time reduced drastically.

Resistance of the managers

It is often quoted by many that Agile does not require extensive training and development, that it does not require expertise of the highest order to deliver quick responses to changing client specification. All it requires is a change in mind set. While the conditions stated formerly are still easier to satisfy, changing mind set is the biggest hurdle. Tech Mahindra faced the same hurdle in the form of resistance from senior level and project managers to adopt the new ways. It took some time for the company to overcome the initial inertia. But this did not result in any severe consequence like refusal to comply with the change or increased employee turnover.

Improved response rate

Agile software development overcomes the limitation of waterfall model regarding its inflexibility in breaking a project into separate stages. With Agile in place, Tech Mahindra could make short term commitments, each one changing as the requirements of the project changed. Apart from giving the client enough scope to understand end the program in stages, it offered Tech Mahindra a buffer that if it misunderstood the requirements of the client then it could make progressive changes at small intervals (say a week) instead of discovering at roll out day that the solution developed doesn't solve clients' problem.

Effect of the Matrix

Matrix management is a technique of managing an organization (or a part of an organization) through a series of dual-reporting relationships instead of a more traditional linear management structure. As indicated by the matrix, many employees at Tech Mahindra had to report to at least two managers. This created conflicts of interests at some places while caused internal friction on some instances. But these limitations were small compared to the gains achieved by the company through quick and structured percolation of the learning.

Benefits

The following are the benefits of implementing agile development systems in an organization:

1. Revenue- Since in agile development, little time is spent on planning, and the implementation is iterative, it ensures some early inflow of revenue, which can be used as operating capital for further activities.

2. First mover's advantage- It has a Shortened development cycle-time of 75%. By implementing this process firms ensure an early entry into the markets, which would inturn help them take the first movers advantage. The incremental delivery system helps the cause of an early delivery.

3. Quality- When compared to the traditional form of working where the testing of the product is done only at the end of the cycle, this process has the advantage of inspection at regular intervals and at the end of various phases. This ensures a zero-defect outflow to the next process, which not only ensures a higher quality but also helps reduce additional costs and time which would be incurred had the defect not been identified at the early stages.

4. Visibility- In the traditional process, most of the communication was done in the written form, but in agile development the stakeholders have regular meetings in order to discuss key issues and also to update each other on their day to day operations and progress. This visibility ensures that the expectations from the project and the responsibilities of the project members are clear.

5. Risk Management- Apart from the benefit of visibility, the principle of personal meetings also reduces the risk involved in the project. Through these meetings the key issues can be identified and dealt with at the earliest with the cooperation of the necessary stakeholders (all of whom would be present in the meetings). So this ensures that the right corrective actions can be taken while there's still time to make a difference.

6. Flexibility- In traditional development projects, a detailed plan is made before the start of any project and the role of each stakeholder is defined therein. But then because of the manager think (where he declines to go back on his plan) it is very difficult to change the plan in case of any glitches. However, this concern is properly addressed with the help of agile development, where change is accepted, in fact it is expected. Here the timescale is fixed and requirements emerge and evolve as the product is developed. The major requirement for this is coordination between the group members, understanding one's responsibility, ability to accept mistakes and be ready to make remedies to the same.

7. Cost Control- The timescale is fixed in this approach and so is the cost. The project has a fixed budget, so therefore only the scope of the product and its features are variable and not the cost.

8. Customer Satisfaction- Customer satisfaction is achieved by rapid delivery of goods. The key factor to customer satisfaction is to provide customized products and services to him. The process provides this flexibility and hence enables individual customization with the changing needs of the customer. This enables the business to form a long term relationship with the customer.

9. Promised Product Delivered- In agile development, a lot of emphasis is laid on delivering the right product to the customer. The product/service emerges and evolves through the course of the project, and hence provides a built-in mechanism which ensures that the delivered product is as per customer expectations.

10. Motivated employees- In agile development, small teams are formed for the implementation of projects. These groups meet regularly to discuss the developments in the project. This active involvement, cooperation and collaboration provides an opportunity for each member to voice his concern and give his opinions on important issues. This makes the whole experience very rewarding and helps in creating a very congenial environment to work, where all the employees are motivated to perform better and face the challenges.

The diagram below displays the differences between agile and traditional development methods. By delivering working, tested, deployable software on an incremental basis, agile development deliversincreased value, visibility, and adaptability muchearlier in the lifecycle, significantly reducing project risk.

Source: www.versionone.com/Agile101

Problems:

The problems of agile software are as follows:

Ø Active user involvement and close relationship are needed in the entire duration of the development period. This phenomena is very efficient and makes sure that the right product is offered. It is one of the foremost tenets of agile software development that ensures good management of all expectations. However these tenets require the user to devote large amounts of time and expect him to commit himself fully during the entire course of the project.

Ø During the course of software development , various requirements emerge. This creates the essence of agile which symbolizes flexibility. Flexibility basically means ability to alter the course of action whenever required and to make sure that the right outcome e is delivered. There are two disadvantages to this concept. One of them is possibility for scope creep, which can increase the risks of projects. The other disadvantage is there is less reliability at the beginning and during the course of the project regarding what product it would deliver. This in fact can make things much more difficult to understand the problem of the project and negotiate for projects where in the motive is to have a constant price. Without complete knowledge of what is needed and discipline of timescale, it can become disadvantageous.

Ø Testing is combined well throughout the course of the development. This is essential to ensure the effectiveness and quality without requiring to resort to a long and a tedious test phase at the completion of every project. However, it does not suggest that testing instruments are not required during the project. These testers are costly and they increase the overall resource cost. This however has no effect on curtailing various risks. Research has proven that many projects have actually failed. The various costs involved in a lengthy test phase can lead to high costs when a project runs over the time.

Ø Agile software development is very time consuming and demanding for software developers. They are required to finish to achieve 100% efficiency in every feature within each iteration, and the plethora of iterations can be stressing. Therefore it is extremely important to select the right team and provide a back up team as well.

Ø Agile software provides limited support in the following cases:

o Limited support for distributed development environment

o Limited support for subcontracting

o Limited support for building reusable artifacts

o Limited support for developing large complex software

Ø In case of some software deliverables, especially the large ones, it is difficult to assess the effort required at the beginning of the software development life cycle.

Ø There is lack of emphasis on necessary designing and documentation.

Ø The project can easily get taken off track if the customer representative is not clear what final outcome that they want.

Ø Only senior programmers are capable of taking the kind of decisions required during the development process. Hence it has no place for newbie programmers, unless combined with experienced resources.

Costs:

Costs in relevance to agile software development can be classified as:

a) Costs of change

b) Costs of learning (Experience costs)

1) Cost of change

a) Traditional cost of change curve:

Cost of change is an important aspect of lifecycle testing.The diagram below shows the relative cost of a changed requirement. It can be seen for the diagram that fixing error cost has an exponential growth in the later detection stage in the development lifecycle. This is so because the components in a serial process cumulatively build on one another.

For example, if a requirement error is committed and is detected during the requirement phase, it would not cost much to fix. This is because one can merely alter the part of the model. Typically in American context, the change is in the order of 1 dollar. If requirement error is not found until the design stage, it becomes extremely costly to rectify it. That is because one then has to change the analysis as well as to alter the parts of the design that were formed taking into consideration the faulty analysis. In this case the cost of changing would be ten times more i.e 10 dollars. If the problem is further not found till the programming stage ,one will have to update everything including design and its analysis and discard the previous code. In this case, the error could cost ten times more i.e 100 dollars. Furthermore, if one detects the requirement error during the stage where traditionally testing is done , the error can cost 1000 dollars. Here in this case, one has to change the entire documentation and discard majority of the code. Lastly, if the requirement error is not found until the production stage arrives, the repair cost would be of the magnitude of 10000 dollars.

Traditional cost of change curve.

b) Cost of change curve:

The diagram below shows a curve representing cost of change with reference to agile software development. The curve shows a slight rise as time goes by and does not flatten. There are several reasons for this:

* Tendency to travel heavier over time. The base of the business and test code show growth as time passes thereby increasing the probability that any change that takes place would influence more things later.

* Inflexibility of non code artifacts. The code base and non code base will expand over the period. Various things like manuals related to operations and user references as well as systems related documents would have to be altered and updated. Resorting to a novel approach of Agile Modeling Driven Development (AMDD) will ensure reduction in expenses but however will not lead to full elimination.

* Extra costs due to deployment issues. When releasing software becomes costly, it becomes a much more economical alternative to sell CD instead of releasing software. This increases the cost of change because one starts following moe expensive procedures.

* Environment and lack of agility. Many a times software development personnel have to work in environments which are not agile. They are therefore forced to make use of procedures that increase the overall costs. These techniques result in creating a feedback loop which hamper the scope of change.

A realistic cost of change curve

2) Cost of learning

The learning costs in case of agile software development too follows the same trend as the normal cost of learning. The main reasons for the downward slope of the cost of learning curve are as follows:

1) Labour efficiency

2) Better use of equipment

3) Standardization, specialization, and methods improvements

4) Technology-Driven Learning

Note: The above diagram is for representation purpose.

The above diagrams show that the cost per unit on using agile software would reduce as the production output due to agile software increases.