XP handles ‘Change Requirements’ at ease!
In my previous blog post ‘QA’s Role in XP’, we saw some of the Extreme Programming (XP) Values and Principles. This is a follow up post discussing how XP allows the software development teams to manage ‘Change Requirements’ (CRs) at ease.
First of all let us explore some of the possible causes for change in requirements.
- One of the obvious could be change in business needs. i.e Industries that are fast progressing compete in capturing the customer base at the earliest with their innovations in product solutions. This in turn means every competitor should be aware of what is in the market and where their product relatively stand. As a result the solution which was originally intended might need a change when the business landscape changes.
- Latest tech tools released in market as well as upgradation of existing tools.
- Change in internal stakeholders whose vision of the product is different.
- Feature to Market Priority changes
- External / Third Party system changes
- Miscommunication between the business and the software development team
Let us see how XP enables the software development teams with some key practices to handle all of the above causes.
Continuous Delivery (CD):
Continuous Delivery systems are primarily set up to cater short / frequent release cycles. CD systems briefly performs the following tasks — picks a commit, integrates with the existing code, runs the unit tests, integration tests and other automated tests and finally pushes it to production (or to a QA environment and the QA pushes it to production environment after they are done with their exploratory testing).
Frequent release cycles enables the business to prioritise the features for every release that are most important for their revenues and branding and help quickly reach the customers. We are talking about release cycles as short as every commit to prod or an iteration or chose a minimum viable product (MVP) to go within a few weeks. Also since the product is continuously released incrementally, the chances of vast or major changes in the market is very less which means that if at all we encounter changes to be incorporated it can be seamlessly incorporated.
Feature Toggles:
While talking about frequent releases, one of the puzzles would be that if the developers should hold their commits until the feature is completely done, so that the CD systems can take it to production afterwards. This is a big anti-pattern. Changes can be managed easily only when the commits are all well integrated at any point in time. Feature toggles comes in handy to manage continuous delivery of features that is still in development. A typical use case would be say the team is developing feature A and suddenly another feature B has higher priority to hit the market the team can toggle ‘off’ feature A (which has still reached completion) and start Feature B development and continue CD.
Feature toggles are also useful for A/B testing a particular feature / CR on a customer sector and getting frequent feedbacks.
Automated tests:
XP relies on automated tests heavily. When we say automated tests we are looking at unit tests, integration tests, functional tests, performance tests and all other kinds of tests that can be automated and integrated with Continuous Integration (CI) pipelines. This is to mainly enable Continuous Delivery. Once all the tests passes the build is automatically certified to be production ready. On the other hand, the team gets immense confidence in the product during development as these automated tests acts as ‘safety nets’ to fail safe.
Typically integration with third party systems is also automated as contract tests and when there is a change in the third party systems it is brought to notice when these tests run. Also when the existing dev tools get older and have to either upgraded or replaced with its fancy version, these automated tests are real guardians for the software development teams which otherwise would have to go through multiple manual testing and defect fixing cycles.
Iteration Planning with Business:
Every iteration within a release the team comes together along with the business to understand the current needs of the business specific to that point in time and schedules an iteration plan collaboratively. Like mentioned earlier, this enables changes in priority of features to market to be incorporated in a structured way. Each iteration could be a week or two maximum, which means the business need not wait to bring in CRs for a very long time.
Also the collaboration with the business extends to the level that once the stories are detailed with the acceptance criterias by the Business Analysts (in software development team), it is sent for sign-offs to the Product Owner in the business side so that any miscommunication can be curbed even before the development work begins.
Frequent Feedbacks from the Business:
Once the development work for the iteration is over, there is a showcase to the business. This is a structured forum to receive feedbacks on what has been built so far. As part of the showcase, the dev team runs through the acceptance criterias of each story along with the edge cases. They also discuss about the NFRs. The discussion is kept as transparent as it can be so that when there is a misunderstanding in the implementation by the business or in the way the requirements have been understood there are clear feedbacks to work on before picking any new tasks. These feedbacks are just over the short chunk of work done in that iteration and hence it will be small and easy to handle.
By receiving frequent feedbacks this way, we do not let change requirements grow in magnitude and impact the business as well as end up wasting the dev team’s time by building on top of some irrelevant business flows.
These collaborative meetings with the business and software dev team at regular intervals (usually twice within an iteration, more for the BAs) helps the team understand any change in the business stakeholders and their visions and have meaningful conversations at the earliest.
Thus we can see that XP incorporates structured way of handling change requirements, at ease, for both the development team and the business folks.
