Measuring your Support Queue

Last week I wrote about how we use a dedicated “SWAT Team” to handle the inevitable unplanned work which threatens to creep in and disrupt our sprints. This week I want to talk about how we measure our SWAT Team, what KPIs we use and how we know whether we are doing a good job.

There are hundreds of posts out there which discuss the merits of KPIs for developers and how the wrong ones encourage behaviour such as cherry picking or incorrect prioritisation. I agree with them entirely, that’s why it’s important that the measurements you do take should reflect the customer experience, rather than the team’s performance.

For example, counting the number of tickets solved would be a poor metric because only quick wins would be looked at. Equally timing how long was spent on each ticket would also encourage people to rush in order to get better stats. However, recording how long a customer waited (from raising a ticket to resolution) measures the customer experience – which is, after all what we should be more concerned about!

In my team we use two main statistics to measure how well we’re performing. The first is one I’ve mentioned before. Average Support Ticket Age is crucial for us because it places a numeric value on how long customers are currently waiting for our help.

The second metric we use is Cycle Time, this is the time between a Ticket being passed to the team and it being resolved. In other words, how long is it taking to solve tickets passed to us This is taken as an average of tickets closed over the last six weeks.

The reason we like these two values is not only that they give a customer’s perspective on our work, but because they balance each other nicely. If we measured Cycle Time alone then we’d get fantastic results by simply solving tickets as they come in but longer running and challenging tickets would be left behind. Equally by focusing only on the older tickets it’s likely we’re missing urgent tickets and quick wins which could be resolved quickly. It’s only by continuously improving both values do we provide a good service.

You’ll notice that we don’t worry too much about the volumes of tickets. I find this doesn’t actually matter, the number of tickets being raised varies from month to month, from customer to customer, and will change as customers leave and (much more ideally) join us. If the team is becoming overloaded with tickets then this will be highlighted in the metrics we already have (as we won’t solve the tickets as quickly). A measure of tasks in the queue is less import than whether the team is keeping up with the required workload.

A final point to make us where we start and finish timing. If you’ve ever read The Goal you’ll know that one of Eli Goldratt’s key points is whether you are measuring the right thing (he points out that efficiency increases do not necessarily produce an increase in profit). The decision you have to make with your KPIs (particularly when a ticket was opened) is whether to start your timer when the customer raises the ticket, or when it’s passed to your team. There is no perfect answer here, if you want to understand the entire customer journey then you need to look at Customer to Customer timings, however – if your team only plays a small part in that journey (as in our development team’s case as we have several support teams before us in the process) then your metrics will be less valuable if they include areas outside your control. Consider what you’re measuring, but never forget that you may only play a small part of the customer’s overall journey.

Hopefully I’ve given you a few ideas? Do you agree with my views? How do you measure the performance of your support teams?

Why Branching still has a Place in the Agile World

I’m sure every developer out there would love to have a single code base with builds which are automatically tested and pushed out to customers. However, let’s assume for a moment that you’ve not got a full CI system with triggered builds, automated testing, and thousands of automated deployments a day.

For the sake argument let’s say you’ve got some of these pieces in place. Perhaps you have nightly builds? Maybe even some unit tests! But if you’re like most of the companies I’ve worked with you still run manual signoff scripts and have a couple of guys who do the deployments, know every config setting by heart and can get your application to run in all kinds of new and innovative ways.

Despite what The Phoenix Project tells us deployments to customers are still a big deal and version management (finding a way to release bug fixes but not new features) is a fact of life.

If your customers are anything like mine they’ll be incredibly nervous about taking new features. They want lengthy UAT phases and opportunities to train their staff on new functionality. This may seem like Waterfall to us, but remember many of our clients have stakeholders in some very big business. In my industry (Health and Leisure) for example we have code freezes over the January period while New Years Resolutioners and marketing campaigns are at their peak. Very few businesses would open themselves up to the risk of IT failures during these critical times.

And yet support contracts and maintenance doesn’t stop. The busy times are when the software is really put to the test and we must be able to respond to any issue which may arise.

This is why we use maintenance branches.

Our job as developers and IT professionals is to deliver a good service to our customers. We need tools and processes to do this. Agile and Continuous Integration are two of those tools but if they don’t help us meet business needs then we should seek others which do.

My customers tell me that they want to be able to take patches quickly if required. That they want to be able to access fixes without the need to test and learn new functionality.

Techniques such as feature toggles help but in my view the only way to truly meet this need is to cut a release branch after each feature (or for convenience block of features) is completed. We usually use a minor version to represent this. Using this model we can support customers without surprising them with new functionality and continue to develop knowing that we can put out maintenance releases of older version at any time.

Controversial? Perhaps, practically over purity… I hope so. What are your views or release branches and support customers with on premise installations?

April Agile Yorkshire

I managed to get a seat at Agile Yorkshire this month, I’ve missed a few of these recently partly due to other commitments but also the sheer popularity of these events.

Royd (from NewRedo) organises and coordinates these evenings, this week he’d arranged for Chris Cheadle and Sean Craig from NHS Digital and John Le Drew who runs The Agile Path to speak to us.

Chris and Sean went first, they spoke to us about an event they’d run a little before Christmas. They’d called it Firebreak, during a two week period almost the entire organisation downed tools and worked on “whatever they wanted”.

They’d started with almost a kickstarter approach, people posted ideas on postit notes and their colleagues pledged their time – once a project was fully resourced it was banked and it would go ahead.

I love the idea of this sort of thing, really opening the doors to let teams work on what they want – what they feel wild make a difference. Anything from process improvement to a proof of concept or a piece of server maintenance. It certainly seemed to be a positive experience for the NHS team, some of the projects saved thousands of pounds on licence fees!

The second talk of the night was about Safety and how important it is to effective teams.  John explained that he considered safety to be “free to make suggestions, give feedback, and make mistakes without fear of punishment or humiliation.”

For me this feeds into the fundamental requirement of trust which Patrick Lenconi described in his book Five Dysfunctions of a Team. He postulated that without trust (or in John’s words safety) teams would not challenge each other and discuss ideas.

John had a few examples of this, my favourite was a role play exercise where three characters were so determined to avoid taking the blame for pressing The Big Red button which would overload the nuclear reactor they refused to cooperate to press the three buttons which would save them. Contrived? Perhaps… but it makes the point that if you are scared to look foolish then you’ll naturally be less confident to make suggestions.

Something which did niggle me was the idea of accountability, as managers we need to hold our directs responsible for their performance but this is challenging without undermining that feeling of security. In Lenconi’s book he encourages the team to hold each other accountable, finding the balance between a blame culture and safe, self motivating team is a difficult balance to find!

I’d certainly recommend listening to John if he’s speaking in your area. At the very least I’d say every manager should hear his views about engagement and workplace stress! I for one will be listening to his podcast.

It was a great night, as I’ve said before I’d always suggest Agile Yorkshire if you’re a Leeds based  geek!

Why Technical Tests are both a Wonderful and Terrible Idea

When hiring for a new developer its extremely common to ask them to demonstrate their technical ability. Often this is a practical test to be done at home and then sent into the hiring manager.

It’s a nice idea, you get to see the candidate’s unhurried work, get a feel for their skills and potentially ask about them in a face to face interview later. It’s far harder for a bad developer to write good code than it is for them to learn a few answers about relational databases or solid principles.

However, I believe this approach is flawed!

To explain why I want to describe the recent experience of a friend of mine, an outstanding developer who recently applied for a development role. The technical test was presented to him and he completed it, he’d had a rather manic week and so determined not to miss his deadline so he worked late I tot he night. He confessed to me later that he probably spent somewhere between ten and twelve hours on that piece of work!

What happened?

The company rejected him with a series of bullet points over design choices without ever giving him the chance to explain why he’d made those decisions.

So let me ask you this, do you think friend is ever going to waste his time with one of their roles in the future? Do you think I, knowing his experience would apply for one of their jobs? What about the rest of our friendship group?

My point is this – any hiring manager will tell you how scarce good development resource is. By demanding eight, ten, maybe even twelve hours of our candidates’ time and then throwing it away, that’s (in my view) arrogance.

What’s more it doesn’t actually tell you very much! Sat at home what’s to stop someone googling the question, posting something on Stack Overflow, or asking a friend to complete the test for them? How do you know that the candidate’s work is their own?

So what do I recommend instead?

I’m hoping to start recruiting over the next week months and I intend to send code review tasks out to my candidates. Why?

  • Asking someone to review your code gives them a chance to suggest improvements and identify where you’ve not used best practices
  • Code reviews ask candidates to explain and articulate their views, something a straightforward programming challenge doesn’t
  • You still get the same feel of a candidate’s focus (do they focus on code clarity, performance or UI aspects?)
  • You are demanding far less of a candidate’s time and therefore aren’t putting off people applying for the role

Will my approach work? I don’t know, we’ll find out! What are your experiences with practical coding challenges? Do they work?

A Different Sort of 1:1

I met up with my line manager the other day, a nice change to our more common video chats. Spare meeting rooms at head office are seen less frequently than unicorns so instead of sitting in the open plan work area he suggested going for a walk.

The idea resonated with me and it’s something I’m determined to try with my team. Here are a few reasons why

  • Meeting rooms are very formal, 1:1s don’t have to be
  • Fresh air and a little light excercise is good for all us office bound geeks
  • Getting away from the office environment can lighten moods and change perspectives

Now, I don’t suggest you try a walking 1:1 on a wet, cold, or otherwise horrible day but the next time the sun is shiny why not take a walk?

Have you tried outdoor 1:1s? What was your experience?

The Cost of Fixing Bugs Late

Have you ever been in a situation where you’ve written a piece of code and it’s almost there but there are a few niggling issues which “can wait for V2?”. Have you ever wished, maybe months later that you’d gone back and resolved them at the time? You’re not alone!

More and more developers and managers are beginning to realise the true cost of fixing bugs late, not only on their sanity but on the company’s time and money.

Let’s say for the sake of argument that you’ve finished a piece of code except for a few edge cases. You’re under a lot of time pressure so you decide it’s of a high enough quality and you push it through to QA. The cost to the business of fixing that issue actually increases dramatically the longer it’s left.

Let’s look at a few scenarios:

You fix the issue immediatly

  • Fix time – 30 minutes

You send to QA and it’s rejected there

  • Fix time – 30 minutes
  • Build time – 2 hours
  • QA deployment time – 1 hour
  • QA signoff testing – 24 hours
  • Fix time – 30 minutes

QA passes as an “edge case” but the customer disagrees

  • Fix time – 30 minutes
  • Build time – 2 hours
  • QA deployment time – 1 hour
  • QA signoff testing – 24 hours
  • Deploy to UAT – 3 hours
  • Customer UAT – 1 week

Missed in UAT but discovered as a significant issue in Live

  • Fix time – 30 minutes
  • Build time – 2 hours
  • QA deployment time – 1 hour
  • QA signoff testing – 24 hours
  • Deploy to UAT – 3 hours
  • Customer UAT – 1 week
  • Customer live deploy – 3 hours

 

As you can see, even with these rough estimates the time it takes to resolve the customer’s issue increases dramatically the longer it’s left. Not only that but the cost of time to the business of paying staff to run extra QA cycles or rounds of UAT spirals out of control. We haven’t even considered the final case where it goes to the bug queue to die and a completely different developer has to learn the feature and resolve the problem.

The graph is actually a very common shape*.

graph-2

I’m a big fan of practicality, no software is going to be perfect and it’s unrealistic to expect that you’re going to find and fix each and every issue before shipping to a customer.

However, hopefully this has made you stop and think and has provided a strong argument for making that extra 30 minutes to resolve the issue before it causes a real headache for the business!

*Thanks to fooplot.com for the graphing software.

Stay Technical

I recently spent a Sunday night in a hotel in Hatfield prior to a customer meeting on the Monday morning. For some unknown reason I felt an urge to learn Python.

Why? I have no idea… I’m a .NET developer, my team are all .NET developers but it seemed ages since I’d picked up a new technology and had a little play… not because I’d needed to for some project but just because it looked cool!

As IT Managers and professionals we got to where we are by working very hard and having a natural curiosity about technology. Our roles may have changed but I believe it’s crucial to keep that inquisitive nature alive – especially if we want to engage with and be relevant in our teams.

Of all the managers I’ve ever worked with the ones I’ve respected the most are the ones who find the time to stay hands on. I always told myself that it was something I’d hold onto through my career.

With so much of my recent time being spent reading about the Theory of Constraints, Agile Principles, and Scrum practices… it was a refreshing change to think about immutable data types and significant white space!

The next time you have a quiet few hours do consider picking up a book or opening up pluralsight. Remind yourself why you chose to be a developer in the first place and maybe even write some code in a new language!