It was at one of my previous jobs, when I had to witness an unpleasant relationship between engineering and business folks. Company’s main product was a network optimization software that would enhance standard internet routing protocols. Team was small and we were pretty much following a traditional development model, where requirements were fully understood and signed off by customers and business analysts before the engineers would start working on the product. In the early life of the product company was targeting the ISP business, however as time went by and product was not selling well, company decided to market the product for enterprise businesses instead. We were in the middle of the major release lasting about six month, when business analyst decided to change the feature set for that release. Everyone in the engineering group was stunned and could not believe that so much time was wasted on unnecessary functionality. What I found more interesting – when I talked to both sides at lunch, each one had its own compelling arguments, and both seemed to be right. Developers blamed the change in requirements on business analyst who they thought failed to produce solid system requirements. Developers however never understood the actual reason behind that decision – the company was running out of money and had no choice but to aggressively change its customer base to survive.
How does agile methodology deals with changing requirements? Agile Manifesto states:
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
Not only Agile methodology expects the requirements to be changeable, it actually requires them to be changeable. The main reason being is that it takes a lot of time and energy to finalize requirements with the customer and product could potentially be never launched. Customers are also not experts in the software development and do not see a problem of changing requirements as a serious one. On the other hand, even if engineers could get a stable set of requirements, they would probably be fooled as well. As Martin Fowlers writes,
In today’s economy the fundamental business forces are changing the value of software features too rapidly. What might be a good set of requirements now, is not a good set in six months time. There are projects that must follow a predictive requirement model, for example a lot of government projects. However, much of the business software do not fit that category thus they have to revert to a new adaptive process, iterative development, that can give them control over an unpredictability.
In todays market developers are being asked to deliver more of a product with less resources. Thus any efficiency that can expedite the development process is being considered. With strict deadlines and limited resources, as is the case in most startups, no one can afford to sit back and wait for a full set of requirements. Becoming agile allows you to get your development organization get started early while your product managers are still developing or finalizing the product feature set.