Welcoming Change Whilst in the Realm of Agile Software Development

Summary show

Agile Software Development

One of the most difficult principles of Agile Software Development to actually implement is the principle of welcoming change. Two of the statements of values in the Agile manifesto are:

Customer collaboration over contract negotiation
Responding to change over following a plan

These statements lead to the idea that Agile Software Development welcomes changes from customers and other stakeholders in the project. The Software Development team aims to gather feedback by developing frequent releases through developing the software in a series of iterations. A customer changing their minds concerning the requirements of a project isn’t viewed as a problem, which can be in sharp contrast to how many methodologies approach the topic of requirements changing. This incorporation of feedback and customer involvement is an important contribution to the success of Agile methodologies as it leads to the development of software that customers really want. Following this principle is no easy task because applying this principle needs to start at the beginning of a project. Guides to implementing Agile Software Development frequently mention the role of the executive sponsor and other business-oriented roles within a company that needs to buy-in and support an initiative to introduce Agile Software Development. But in a Software Development company that develops bespoke software directly for customers, the business people in the company need to understand and stick to the principles of Agile Software Development likewise.

There may be support for Agile Software Development in a project of all members. Still, the general perception amongst the business people is that it is one area that developers do and does not directly concern them. As much of the material available on Agile Software Development does specifically concern Software Development teams, that is quite an understandable assumption to make. In a company developing bespoke software, the client needs to be made aware of the nature of an Agile Software Development project. A contract needs to be negotiated that is compatible with the chosen methodology. And it’s the business people associated with a project that usually holds the responsibility of setting the customer’s expectations for a project and negotiating the contract.

Customers not really acquainted with Software Development expect that when negotiating a new project with a Software Development company, the process is quite like purchasing almost every other goods and service. The client explains what they need, they agree a price together with a delivery date, and the customer then waits for it to be achieved. The Software Development company will not want to challenge these expectations for fear of making a customer uncomfortable and potentially losing their business. This often leads to a binding agreement that mirrors these expectations. The customer 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.

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

These changes are unlikely to be very welcome to the Software Development company at this point. In practice, these requests for changes result in friction between the customer and the Software Development company, possibly bringing about arguments between the company and the customer. The company will believe that these requirements weren’t specified originally when the contract was signed and demand additional cash to implement these changes. If the customer agrees, a new contract will need to be negotiated. On the other hand, the company may agree to do these changes for free given that the customer is without a doubt quite upset that the software does not do what the customer wants. These changes are often handled for free; the company gets closer to generating a loss on the project. In both of these scenarios, the project is sure to be late.

If the development team itself is trying to be Agile and is developing the project in iterations, the case is often improved through getting feedback from the customer earlier on in the project. But if the contract remains to be the same, these changes will still be unwelcome to the business people associated with the project. They will be seen as an extra expense, and the developers will be instructed to extend the time for making these changes until a new or revised contract can be negotiated. Once the business people perceive that changes will be happening between iterations and that this needs addressing, they should recognize that a new approach will probably be required to make new contracts with customers. An effective option that they might choose is to try to break down the ‘development of the project into separate, ready planned phases and then make this the substance of the contract. This approach doesn’t challenge the customer’s expectations of being certain of a project’s outcome, so it appears like a safe option. At the start of a project, a customer is frequently quite positive that they know what they aspire to. In practice, actually seeing and using the software might most likely make the customer consider the project in a whole lot more depth than they had previously.

This phased approach to making contracts will not solve the issue of welcoming changes and introduces new problems. When the first phase of the project completes, the customer gets to use the software for the first time and makes requests for changes. As a consequence, the next phase will have to be planned again. If the original phases were estimated, then the next phase will require a new estimation from the development team. And the business people will have to create a new contract for the next phase. Normally, this approach will demand a large administrative overhead for relatively small amounts of work. The customer can also be likely to get impatient over the length of time it takes to get some more work done. More steps need to be taken to develop within an iterative fashion effectively.

In an ideal scenario, the people setting the customer’s expectations for the project would have bought into the concept of Agile Software Development and grasp the principles involved. They would also be responsible for convincing the customer of these benefits and negotiating a contract that works well with their chosen methodology. Three typical customer expectations shall be challenged during this process:

that they already know exactly what they want
that they can be certain of what to expect at the end of the project
that the Software Development company is exclusively responsible for the success of the project

To convince the customer that developing the project the Agile way is a good idea; the benefits need to be emphasized:

That they can change their minds if they want when they want
Their changes will be incorporated into their application quickly with minimal administrative overhead
They will not have to wait long to see their changes in the software
The application developed will be what they want it to be, not now but what they want on the release date
They will have an important role in guiding the development of the project throughout its development

There are, of course, trade-offs for these benefits:

The customer can’t be certain what they are certain to get at the end of the project when signing the contract
The criteria for the success of the project will change with time and will not be stated explicitly in the contract as a detailed specification
The customer must take an enthusiastic role in participating in the project. The project’s success all hangs on the effectiveness of the collaboration between the customer and the Software Development team.
The customer will have to prioritize their changes, choosing which ones are developed first and which have to be dropped when necessary.

A compatible contract will likely not state a detailed project plan and plan a binding agreement for the Software Development company. General, advanced-level requirements will be used as the success criteria for the project.

In return, the contract will enable the customer to request changes to the project when the customer wants to. A formal definition of how changes are handled will be included in the contract. This definition will match the methodology used by the Software Development team. With most Agile methodologies, this will mean that the development team will incorporate these changes in the next iteration following the change request from the customer. The contract will also not contain specific time estimations for high-level requirements. It will instead contain an iteration schedule. A contract that welcomes change is a contract that does not have to be changed.

While the process described is known as change, this term doesn’t accurately describe all that occurs. A changing business environment can motivate changes in requirements but what is happening most often is creating new ideas for the software from both the customers and the development team. It is part of the creative process that makes the software, and it is definitely something that ought to be welcomed.