Agile software development, the principles. Principle 2: Welcome changing requirements, even late in development.

This is the second of 12 posts about the principles of agile software development. Purpose is to go back to the start of the agile manifesto (http://agilemanifesto.org/principles.html) and discuss the implementation of the 12 principles in real life software engineering. Goals of agility are to go deliver software of higher quality, faster, with a higher acceptance to end-users and able to follow the changing business requirements to strive for competitive advantage.

The question is: is this going to work in practice or is this only based on a nice marketing and sales story.

Principle 2: Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

This is one of the marketing / sales pitfalls of agile software development. What sales executive like to tell the customer is “Our agile process is designed in such a manner that we can incorporate changes during the whole development phase, even in the end”. This is nice customer expectation management (understatement). What the customer understands form this promise is that this project is able to incorporate all changes in requirements even up to a few day’s (or even hours) before going life.

What is often not mentioned is that welcome change works both ways. Both the development team as the customer / user team have to be able to welcome changes during the project.  Our common goal is to deliver valuable software to support the customer’s competitive advantage.  This competitive advantage is often linked on time to market.  So we (customer and developers) could agree upon changes in requirements that enable the team to deliver more valuable software faster. This can surely add to the customer’s competitive advantage.

Why should we welcome change? Is it just better to fix requirements at the start of the project so everyone knows what to do and the customer is certain what to expect at the end of the project.  This believed to be true some 20 years ago. Nowadays there are several reasons to welcome change during the execution of the project:

• Business is changing. Business changes do not hold during the execution of the project. To keep an competitive advantage it is hardly possible to allow no changes during projects with medium to long time span. New markets are explored; customers demand changing service and competitors deliver new products/services.
• Understanding of the requirements or problems can change during the execution of the project. New insights into the requirements/ problems can change solution of this. In most (some) cases these new insights can change the implementation of the solution in a positive way. In those cases it is not wise to hold-on to an fixed solution form several weeks (or months) ago.
• Keep an opening for implementing new technological developments during the execution of the project. Some of these developments make the implementation of the solution easier or make it possible to implement more requirements with the same resources.

The basic architecture of the software has to be able to support these changing requirements. The architecture has to be both robust and flexible to stay stable during development and support of the implementation of these changes. As we are more and more creating software in an object oriented world this is becoming less a problem.

So to keep the end result aligned with the customers needs and enable maximum competitive advantage for the customer, changes must be seen as a possibility and not as another way to delay and overcomplicate the project.

You have to rely on your own project management skills to handle the consequences of these changes (in budget, planning or functionality) in a proper manner. Discuss the possibilities and consequences of the changes with your customer and incorporate the end-result of this discussion in your project.

Other posts about the AGILE Principles (soon to come):

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity–the art of maximizing the amount of work not done–is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Google