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.

Intruders

Last week I noticed that a couple of new items had appeared on the board without any prioritisation.

I'm caught in two minds: having people put things on the board gives responsibility back to the team and makes work more fulfilling, but it goes against the philosophy of focussing on the "next most valuable thing".

photo by David Sebben :: Flickr (nebbes6)

For now I've gone the control-freak route and removed the new items from the board (after chatting with the team).

Putting something on the board is effectively making a decision to work on x over y.

Until I've figured out a better way, this is going to stay scrum-like; a meeting (regular or ad-hoc, I don't mind) where a business call is made on what goes into the queue on the board.

I'd like to get to a point where we don't do these meetings to a drumbeat (like weekly, like they are supposed to be now) - but revert to something more in keeping with the Kanban "refinery" approach.

I might put some thought into that next week.

First Release

I'm used to scrum, so it's been a bit weird not working to weekly cycles for development.

Having said that, it's taken out some overheads.

This week it became pretty obvious that we should do a release:

A pile of stuff to release now.

There's a whole pile of stuff - and the more we leave it, the greater work will be required to get through acceptance testing.

So we decided to do a release and pulled those cards through acceptance testing.

None of the release work has changed (not sure if we're doing it right, mind you!).

We still needed to book in the production sys admins, we still wrote a test plan, we still did some manual testing and so on.

I'm still very much impressed with the Kanban approach.   We still use many of the scrum and XP philosophies, but working in a Kanban framework seems to take away some overheads and replace them (ironically) with the "individuals and interactions over process and tools" thing from the manifesto.

It's been interesting to look at the board as we do this though - you'll notice that the left side of the board got pretty vacant back there at the beginning while we all focussed on getting set up for acceptance testing.  

I'm not sure if that's the way it's supposed to be - but by the time we'd finished acceptance testing, the developers were beavering away on new stuff and by the time we were done, it looked "healthier" than I'd seen to date - new stuff coming through as we launched into production...

After the release

I expect that the more regular flow is also down to the decision to break the bigger project work into constituent parts (a few posts ago).

I'd be really interested to hear from other people who are going through a Kanban testing journey, so we can learn from others!

WIP Limits v2

Now that we've ditched the distinction between project and maintenance work, we've been forced to tackle the WIP limit again.

Up until now we'd set a WIP limit on the project work, but not on maintenance.

Now that the work is broken into smaller chunks, it's actually become easier to set a single limit based on uniform speed.

Finally, limits!

Rather than try to figure out what the limit should be, I've just slapped on a limit that reflects the volume we've been handling up until now.

Based on what I'd read in "Kanban and Scrum - making the most of both", I'm expecting the limit to change as we gain more experience - so I didn't want to spend a huge amount of time now.

Ditching "Project"

Brazil has suggested that tracking "project" and "maintenance" might not be as useful as I had thought :)

Ditching the Project vs. Maintenance distinction on our board.

The circle went something like:

1. Big projects are different from maintenance, different speed
2. Big projects will be tracked as one item to reduce noise on the board
3. We'll break up the detail in Jira as subtasks
4. Problem is, developers need to look in two places instead of one (Jira, board)
5. Everything we're working on should be the same level of detail
6. Everything should be on the board
7. We can ditch the swim lanes and convert Jira subtasks to normal ones

So over the past couple of days we've converted subtasks into distinct Jira items and added them to the board.

This has already had a positive impact - as we've begun to put the additional tasks on the board, it's started to fill out the apparent gap that we had between "Queue" and "Dev-WIP".

Hopefully this will become easier to manage now.

I'm also suspecting it will become easier to set WIP limits now, we'll see...