In the Agile world the ideal project cycle churns out iterations until the customer's ROI for the next iteration is lower than the cost. Maintenance and support continue until system EOL. But, too often this is the story:Contract is awarded to you - the new company - to replace ancient system. You are up on new technology and eager to dive in. The project delivers iterations on time with maximum value for 18-24 month. After each iteration you receive positive feedback about technology, business value, usability - every metric the customer cares about. Things are dandy.
But then subtle complaints creep in. The customer starts to ask "Why don't we have feature X? What about <>?" Developers start to say things like, "Well, that issue was fixed in 3.2.6 of the library, but we can't upgrade past 3.0.11 without some major work." Suddenly your app looks several years old and you client isn't nearly as excited about your work. Future epics are planned, but the initial contract runs out.
The client awards a new contract - not to you - to replace the 'ancient' system. And the cycle repeats.
How do we avoid this fate? First, let's think like our client. Project sponsors - almost always non-technical - want to maximize ROI. [Government sponsors talk about wisely using taxpayer funds, but it's the same thing.] They think in terms of system capabilities. Bad sponsors think only in terms of features: "What does the system do today that it didn't do yesterday?" Better sponsors understand things like performance and scalability and will be amenable to initial outlays for infrastructure to support those activities Practically no sponsor will understand the ROI of "refactor Struts 1.x to Struts 2.x" right off the bat. That's where we come in.
I think that, as technologists, we have two responsibilities here: 1) evangelize continual technology investment to our clients, and 2) identify value for any investment we suggest. There's been a lot written about (1) with regards to refactoring. Refactoring, from a business POV, is spending $ to keep the same functionality with an ostensibly 'better' implementation behind the scenes. (Google "justifying refactoring" to get a sense of the problem + solutions.) What I'm talking about is more than just refactoring some code, because in general introducing a new technology will not leave the outward system unchanged. But it's the same idea to me. Some strategies:
- Identify the carrying costs of existing technology. Clients focus on the cost of change and generally don't compare that cost to existing costs. By focusing on how much it costs not to change, project sponsors can begin to make apples to apples comparisons.
- Identify a technologist within your client's organization that can speak your language. This person can work within their organization to help make your case.
- Schedule time with the product owner each iteration to discuss technology-specific backlog items. Make sure these items are actually on the backlog!
- Use the Scrum value of continual improvement and relate it to code.
- Pilot new technologies on admin or lesser-used screens. Fewer users will be affected, and generally admin users are more accepting of growing pains on screens.
- Use EOL or support policies from current dependencies as justification. Bugfixes, including security-related bugfixes, often must be applied in some environments and can be the impetus for upgrades.