Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
Back during 2009-2010, I finally decided to buy an apartment and call it my own home. I had a few specific requirements of an apartment. The budget was an important factor, others were location. amenities, neighborhood, proximity to schools, and so on. However, my most important factor was that it should not have a balcony if it was a high-rise. So there was some search and I zeroed in on one project that was offering an affordable, community living experience at a good location with no balconies. So I signed up, paid the advance, booked a small box in that project, and the deal was done. Come 2010, the builder sent me a sweet letter congratulating me on getting an upgrade to my apartment – a balcony. Shock! Turns out (or maybe that was my educated guess) the builder was finding it hard to sell apartments without balconies. Prospective buyers would turn and walk away when they learnt there were no balconies whatsoever. So the buyer re-planned, slightly altered the models, and slapped a balcony to the plan. That was a scope change right there, one that messed up my requirements, added costs to my wallet, spoiled the (what I felt was) otherwise pure aesthetics of the project. One stakeholder got to sell more apartments and another one got the wrong end of the stick.
Anyway, the point of this whole story is to say that requirement changes happen. Scope gets added, removed, changed, chopped, diced, and in general modified. That is the reality of product development and managing it is part and parcel of project management. Let us now see how the above principle guides Agility.
Why is it said so?
Competition induces scope change. In a highly competitive environment, competition often causes new requirements to be identified. To see the point let us take the example of the Smartphone business and go back to 2007. That was the time dominated by names like Nokia, Blackberry, Palm, Motorola, SonyEricsson, and a slowly rising Samsung among many others. Seemingly out of nowhere, but there was much speculation already then, Apple released the first iPhone and set in motion a series of disruptive innovations that fundamentally changed the Smartphone business and set standards in user experience that would soon become the new norm. Just to take one example, the multiple finger touch as the primary means of human-device interaction upset the set players. Irreversibly, undeniably (maybe with a lot of cribbing) the existing big names had to account for this changed reality and make plans to develop phones with a dominant finger-touch interface. Of course, I have simplified the story here to say my point. There were several other fundamental changes too apart from just a touch interface. In short, the Smartphone business was re-imagined and re-implemented by new players like Apple and Google. It was incumbent on the existing players to adapt to the changed reality, welcome the changes and stay competitive. After 6 years, we are aware of how the bloody war has played out and laid some hallowed names to rest. In fact, it still remains interesting.
Scope change is directly related to uncertainty. In a highly competitive environment differentiation of one’s product from the competition is critical. But more especially, in a field of software development the differentiation can be equaled by the competition in quick time. Thus the quest for differentiation is almost constant and this uncertainty leads to scope changes. In fact, it would not be wrong to say that scope changes to a project actually signifies the importance and relevance of a project.
Changing requirements signify value uncovered to the customer. Same as the above argument, the customer/client seeks a change in scope when a new value is seen in the new scope that was not uncovered earlier. An example is this story about the first iPhone.
Enabling the flow of value is more important than controlling requirements inflow. Traditionally we have been used to freezing the requirements, then freezing the schedule and budget, and then implementing to the plan. Increasingly, it is seen that freezing the schedule and cost first and then fitting in the best value in terms of requirements is a better approach at least in software development. In other words, ordering the flow of requirements such that the highest priority requirements flow earlier within the set schedule is more important than controlling whether that requirement is needed or not.
How is it put in practice?
Agile approaches split the planning phases over several levels of increasingly detailed planning events.
Scrum has the Sprint planning meetings where detailed task breakdown for the immediate iteration takes place. This is supplemented with other long-range planning meetings like release planning meetings. These meetings accommodate changing requirements with the only condition being that the requirements in the current iteration in progress does not change.
XP similarly splits planning into Release planning and iteration planning.
Again, I will try to put in a separate detailed post on specific practices implementing this principle but the above lists a brief on the practices.
- 1. The Agile manifesto.
- 2. The principles of Agile software development.
- 3. On how the first iPhone got its scratch-proof glass.
- 4. The planning levels in Agile software development.