SCM Concerns for Agile Development
There are some areas where agile proponents view SCM with suspicion, and consider the activities to be high ceremony and low value. Let us consider several of these of these.
What about the Cost of Deployment/Upgrade?
The flattened cost-of-change curve is all well and good when dominated by the cost of making development changes. But what if it is dominated by the cost of deploying and upgrading a change? Let’s suppose that it’s easy to make the change, but expensive to deploy it to every applicable instance of the software stored on an end-user’s device? This might be the case if:
- There are corresponding hardware changes required with the software change.
- The system is a highly available one and there is an associated system down time where the system cannot be available for all or part of the upgrade.
- The system is deeply tied to and/or used for significant business process workflow or decision-making support, and an upgrade/downtime requires new training to be developed and users to be re-trained.
In each of these cases, there are no easy answers. We can try to apply lean thinking and agile principles to mitigate the risk and rework for such events, but that may be the best we can do.
What About the Cost of Unforeseen Feature/Requirements Interactions?
Working in microscopic increments may be swell! In theory, I can see that the smaller the change/ feature/iteration and the tighter the feedback loop, the smaller the rework associated with any such task/feature/iteration. There is no code that is more adaptable than no code (code that doesn’t exist yet).
Isn’t one of the main purposes of up-front requirements, analysis, and design, though, to be able to anticipate what would otherwise have been unanticipated impacts of certain requirements upon other requirements and also to avoid having to rework the architecture because of such last-minute discoveries? By developing features in business-value order rather than impact/risk-driven order, aren’t you basically rolling the dice that you won’t have to scrap something major and rework it all over from scratch?
In theory, the answer to the above question is yes. In practice, though, it is rare, provided that your team is very disciplined about doing aggressive refactoring and dependency management in even the smallest possible increments of change:
- If refactoring and integration and testing are rigorously and ruthlessly performed at the fine-grained levels of minimal mergeable tasks, and minimal testable modifications, then you should be able to realize the benefits of emergent design.
- If you don’t have enough discipline to do it so thoroughly and frequently, you may need to make a trade-off by doing a little bit more up-front requirements and design (which FDD does, for example).
Merging and Building: Continuous "Push" Integration Versus Discrete "Pull" Assembly
In the agile world, developing a fully executing system is a holistic Gestalt approach in which the whole is greater than the sum of its parts. In the traditional SCM world, many of us have grown accustomed to a more