The Foxsoft Maintenance Process
Our maintenance process is how we keep your application healthy and up-to-date. Tasks are added to your Maintenance Backlog as they’re discovered, and we use agreed maintenance time to work through those items.
Our principles
The following principles are central to how we deliver maintenance effectively:
Maintained backlog
A maintained backlog gives us the information we need to deliver effective maintenance; an unmaintained backlog prevents us from making the right decisions.
Completing what's started
Incomplete tasks are all cost and no value. Bias towards completing what’s started.
Prioritising risk
The highest-risk items are the most valuable to the project. Prioritise according to the risk.
Prioritising end of life
Plan with End of Life (EoL) dates in mind. A task which is high risk but an EoL date 12 months away can be deferred (within reason).
Keeping you in the loop
To ensure that you’re informed every step of the way, we’ll let you know in advance when your maintenance is scheduled and arrange a kick-off call to discuss our goals. We’ll also keep you updated on our progress and any issues that we encounter. After the maintenance is completed, we’ll provide you with a summary of the work that was done and any recommendations for future maintenance or upgrades.
The maintenance backlog
It’s important for you to know how maintenance time is being spent, which is why you have direct access to the maintenance backlog. The backlog itself contains tasks for any of the following types of issues:
- Maintenance, ie updates and checks.
- Technical debt, ie areas of recommended improvement.
- Documentation, ie filling in blanks in project and product knowledge base.
- Bugs, ie issues with existing features where the application does not behave as intended.
- Change requests, ie small changes initiated by the client which may be accommodated within the retainer.
Feature development using maintenance time
Although we make some allowance for feature requests as ‘change requests’, it’s important to understand that maintenance is discrete and separate to feature development. Maintenance time is usually limited and our primary focus is mitigating known or potential risks. Feature development typically takes a lot of resources and distracts from the important maintenance work and is therefore better managed through separate development sprints.
Task lifecycle
The lifecycle of a maintenance task takes it through the following important steps. There are some other steps in the process which aren’t explained here, but these are the key ones you need to know about.
- Not Ready: An issue has been raised or identified, but we don’t yet know how it should be handled. These tasks will be defined, evaluated, and estimated so that we know where they fit in the maintenance pipeline and how much work is likely needed to address the issue
- Ready: These tasks are ready to work on, but have not yet been started. When we have capacity for maintenance work we pick the next most important item from the list and work on it until it’s done. The key measures we use for choosing a task are:
- End of Life: Tasks with an EoL date need to be completed and delivered before that date or else your application is at risk
- Risk: High risk items should always be dealt with before low risk items
- Approximate Size: If we can deliver three smaller high risk items in the time it would take to deliver a larger item with comparative risk then we should do so.
- In Review: Once an item is complete it may need to be reviewed by you in order to confirm it meets your requirements. If you’re happy with it you’ll accept it and it will get released to production, if you’re not then we’ll agree some changes before it’s released. Note that not all tasks will need your review since the majority of maintenance tasks are technical items which don’t directly affect the end user