Welcoming Change Whilst in the Realm of Agile Software Development


Posted August 21, 2018 by stevewillson703

Probably the most difficult principles of Agile Software Development to actually apply is the principle of welcoming change. Two of the claims of values in the Agile manifesto are:

 
Probably the most difficult principles of Agile Software Development to actually apply is the principle of welcoming change. Two of the claims of values in the Agile manifesto are:

Customer cooperation over contract negotiation
Responding to change over following a strategy
Both of these statements lead to the idea that Agile Software Development embraces changes from customers and other stakeholders in the project. The program Development team aims to gather feedback by developing regular releases through developing the software in a series of iterations. A client, changing their minds concerning the requirements of a project, isn't considered as a problem, which can be in sharp contrast to how a large amount of methodologies approach the topic of requirements changing. This incorporation regarding feedback and customer involvement is an important contribution to the achievement of Agile methodologies as it leads to the development of software which customers really want. Following this principle is no easy task since the application of this principle needs to start at the very beginning of the project. Guides to implementing Agile Software Development regularly mention the role of the executive sponsor, and other company oriented roles within a company which need to buy-in as well as support an initiative to introduce Agile Software Improvement. But in a Software Development company that develops bespoke application directly for customers, the business people in the company need to comprehend and stick to the principles of Agile Software Development similarly.

There may be support for Agile Software Development in a undertaking of all members but the general perception amongst the business people is it is one area which the developers do, and does not directly issue them. As much of the material available on Agile Software Development really does specifically concern Software Development teams, that is quite an easy to understand assumption to make. In a company developing bespoke software, the customer needs to be made aware of the nature of an Agile Software Growth project, and a contract needs to be negotiated that is compatible with the actual chosen methodology. And it's the business people who are associated with a project that always hold the responsibility of setting the customer's expectations for any project and negotiating the contract.

Customers not really acquainted with Computer software Development expect that when negotiating a new project with a Program Development company that the process is quite like purchasing every other goods and services. The client explains what they need, they agree a cost together with a delivery date, and the customer then holds back for it to be achieved. The Software Development company will not wish to challenge these expectations for the fear of making a customer unpleasant, and potentially losing their business. This often results in a binding agreement that mirrors these expectations. The client continues to expect that the software, by the release date, will be ready and do everything the customer wants, and they only need to wait around.

However it is inevitable that the customer will need to provide suggestions on the software and will be very keen to make some modifications. In the above scenario the client is going to find themselves giving their own feedback at a time towards the release date when they actually reach see the software.

These changes are unlikely to be really welcome to the Software Development company at this point. In practice these demands for changes results in friction between the customer and the Software package Development company, possibly bringing about arguments between the company and also the customer. The company will believe that these requirements wasn't specific originally when the contract was signed and demand extra cash to implement these changes. If the customer confirms, a new contract will need to be negotiated. On the other hand the company might agree to do these changes for free given that the customer is undoubtedly quite upset that the software does not do what the client wants. The more often these changes are handled free of charge; the company gets closer to generating a loss on the assignment. In both of these scenarios, the project is sure to be later.

If the development team itself is trying to be Agile and it is developing the project in iterations, the case is often enhanced through getting feedback from the customer earlier on in the work. But if the contract remains to be the same, these changes will still be unwanted to the business people associated with the project. They will be seen as an extra cost and the developers are going to be instructed to extend the time on creating these changes until a new or revised contract could be negotiated. Once the business people perceive that changes will be occurring between iterations and that this needs addressing, they should recognize that a new approach will probably be required in future for making fresh contracts with customers. An effective option that they might select is to try to break down the 'development' of the project in to separate, ready planned phases and then make this the material of the contract. This approach doesn't challenge the customer's anticipation of being certain of the outcome of a project, and so it appears just like a safe option. At the start of a project, a customer is frequently very positive that they know what they aspire to. In practice, actually viewing and using the software might most likely make the customer consider the challenge in a whole lot more depth than they had previously.

This particular phased approach to making contracts is not going to solve the issue involving welcoming changes and introduces new problems. When the very first phase of the project completes, the customer gets to use the computer software for the first time and starts making requests for changes. On those grounds the next phase will have to be planned again. If the original phases had been time estimated then the next phase will require a new evaluation from the development team. And the business people will have to create a brand-new contract for the next phase. Normally, this approach will demand a large management overhead for relatively small amounts of work. The customer may also be likely to get impatient over the length of time it takes just to get extra work done. More steps need to be taken to effectively develop during an iterative fashion.
-- END ---
Share Facebook Twitter
Print Friendly and PDF DisclaimerReport Abuse
Contact Email [email protected]
Issued By steve
Website Software Development
Business Address London
Country United Kingdom
Categories Business
Tags development , software
Last Updated August 21, 2018