Symptom:
The Development team is continually missing milestones for new product releases. Sales is complaining that the new version they need is unavailable and eroding customer confidence.
Diagnosis:
One way I can spot this instantly is to look at time sheets or JIRA tickets, to see what fraction of Dev’s time is being spent on “Sustaining Development” (bug fixes or non-feature updates).
A healthy number is 10-20%.
More than half is a real problem unless it’s temporary.
I once had a client whose devs had 110-120% allocated to Sustaining Development, meaning they were working overtime to stay above water. 0% allocated for new development. It’s important to remember that Developers gain much of their pride from developing new capabilities. This environment was absolutely toxic, and as one might imagine, talent began quitting (accelerating the problem for those who stayed).
Cause:
Executives are pressuring Dev that each incremental feature addition is an “emergency for a critical customer, and therefore must be added to the current release immediately”.
There are two related aspects to this problem:
- Hacking new capabilities into last year’s offering is accumulating Technical Debt. An occasional kludge can be okay, but improvising too many features without rethinking the structure will eventually make a brittle application. Think of a house with too many additions; at some point the underlying structure must be re-evaluated or shored up.
- Once a system becomes fragile in this way, the burden of “keeping it alive” increases substantially. All modern software is dependent upon many systems (often dozens). Each new release of iOS, Android, or Windows is a fresh opportunity for bugs to appear. Each ad-hoc feature that’s “hacked into place” creates an exponential increase in the chance of a faulty interaction between them. A steady flow of bugs will be discovered by customers or triggered by vendor updates, until a solid round of revision is completed.
Solution:
- Executives absolutely must authorize a fraction of the Dev energy for working on fresh architecture, the new version, the new product. Managerially, it’s easiest if there can be a division of labor by people (you three work on bug fixes, and the other four are on the new release). But sometimes talent cannot be divided in this way (e.g. “we need our star database engineer on both new and old”). In those cases, consider a time-share. Make it a very firm rule. Not a policy of “please work 40% on new, but I’m still going to call everything an emergency and pressure you day and night”. A better policy would be “Thursdays and Fridays I promise you’re not expected to touch any Sustaining Development”. Or “every day before lunch is New Release work”. It must be sacrosanct.
- Someone needs to reset the expectations of the Sales team. Stop promising things that are undeliverable. Have a major meeting between Sales and Dev, after the above policy has been implemented. Explain “we’re in a hole, and the only way out is for Dev to have a legit portion of its time dedicated to making a clean new version of our product. We’re going to reset the Company’s roadmap to be calibrated for this. We need to review all promises made to key customers about adding ad-hoc capabilities added to our old version, and we may need to tell some that they will simply have to wait for the new version.”
Every CEO wishes they could allocate a larger team, or even temporary talent, to the CTO for alleviating this mess. In reality, there’s rarely capital for it. Policy changes will be needed, and sometimes they’re painful. But the sooner they start, the sooner the company will be in a better place.
