Support etc

Out of the retrospective last week, we decided to have a go at rationalising the way we manage various types of support, maintenance and project work.

Here is a summary...

Support, Maintenance and Project workflow (v1.0)

Two tracking systems

Part of the confusion we have is that (like many companies we've worked in) there are two systems we use for tracking work:

1. The corporate trouble ticketing system, used by all
2. Jira, used by development teams only

What we're trying to do is to use each for its strengths (ubiquity vs. dev features).

Production Defects

These get logged largely by email at the moment, but we're gradually getting folk to submit them via the (new) corporate trouble ticketing system.

Either way, we now make sure they're logged in the ticketing system so that SLAs etc can be tracked and we can do analysis every month on the type of issues we're getting.

Then someone in our team gets an email, they take a quick look and figure out whether it's urgent or not.

If it's urgent, we throw it into Jira and walk over to a developer and let them know it's urgent.

If it's not urgent, it gets forwarded to me for discussion at the next prioritisation meeting - and does get put into Jira until it's been discussed there.   This is my way of making sure that the meetings are productive.   Otherwise we tend to get into those meetings ill-prepared and no-one takes responsibility for the understanding the relative merit behind the thing.

Maintenance Requests

Other requests come in from various people in the business, generally via email.

For now, I'm not seeing a huge benefit in tracking these in the corporate system, so we'll carry on with email until it becomes a problem.

The person who receives the email has two choices - forward to me or represent the item at the next meeting themselves.

Either way, one of us needs to make sure we understand the business driver behind the request.   As I mentioned in the first couple of weeks' posts, it's important to me that we prioritise our work based on a real understanding of relative benefit.

If something is taking up 10mins a day for 100 people, it's more important than something that is really annoying for one person.

This way, when we have our prioritisation meeting we come prepared to discuss the relative merits of each new item before we make decisions about what to add to the queue.

Project Work

As we gather information about the requirements for our project, we begin to identify discreet features that can be worked on, tested and packaged for deployment.

We don't wait for all analysis to be complete before doing this.   At the moment, we have listed only around 50% of the project features and we've started work on those before finalising the rest of the list.

The tricky part here is that some of these are actually lower priority (perhaps) than maintenance requests or production defects.

To make sure a conscious decision is made regarding relative priority, we're planning to throw these into the prioritisation meeting.   I would stress that this is not happening yet.  For now, this happens on an ad-hoc basis (by me) as we break down the work.