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!

Driving Technical Change Book Review

Driving Technical Change is a great little book who wants to understand how to influence different people in a technology organisation.

If you’re expecting a book on mind control then you’ll be disappointed. If you’re looking for a book which will explain why people react in particular ways to new ideas and technologies then that’s exactly what you’ll get.

Terrence Ryan discusses a series of personality caricatures. These are a little extreme, but you’ll be amazed at how closely they match up with people you know!

Then, the book discusses why these people may resist change or disagree with your proposals and how you can help to win them around.

For example, one of the characters in the book is “The Overworked”, this guy has far too much to do and never enough time. They can’t spare the time to pick up your idea, so how do you convince them? Show them how your project or proposal will save their time and help them complete their neverending pile of work.

I don’t want to plagiarise Terrence work, I’d much rather you picked up a copy and let him explain them first hand.

Would I recommend this book to someone working in a development team? Absolutely! Not just to help them drive powerful ideas forward, but also to help them appreciate other points of view – understand why The Boss, The Overworked, and The Burned may not necessarily agree with every suggestion.

Scrum Is Not Enough!

Let me start by saying I’m a big advocate of scrum (despite some of my posts in which I challenge it over and over again). Having said that it has it’s weaknesses (like any process), one I’m going to highlight in this post is the insular nature of some scrum teams.

The best way to explain this is to describe my own experience. When I started in the Scrum Master role I was very keen on continuous delivery and wanted the development team to produce a build every two weeks which could be supplied to the business to decide whether to deploy it or not.

We had a lot of projects on at the time and we were working very hard to meet the commitments my predecessor had signed us up to and get features out the door on time.

This went on for a month or two, we hit every deadline in the calendar and provided the builds to the deployment teams on the dates we’d agreed. So what happened? Nothing…

What I’d failed to realise was that despite our hard work over the last few months we’d failed to release a single new feature to a customer. The deployment teams had struggled to install our software into UAT and without any contingency (except when it was carefully planned for) we had no capacity to assist them or pick up any issues – until the next planning session of course (where usually the next feature was the most urgent due to “customer commitments”).

Development kept on working, features continued to be produced and deadlines were hit. But the customers were sat waiting, UATs couldn’t be completed (or in some cases even installed), and the business because frustrated with us because we weren’t available to help them get the product out the door.

So what went wrong?

This is where you may have to forgive my sleight of hand in the title. I don’t believe the problem was with the scrum methodology as such, merely the most common implementations of it. The first oversight was the handover, the second was the goals of the team. Let me explain…

Firstly the handover, the issue wasn’t that it was sloppy or that it we didn’t have consistent priorities across the business (although that certainly didn’t help). The issue was that we had one… A scrum team should contain all the skills and knowledge required to get a feature from concept to customer. Rather than handing builds over to the business to deploy we should have had someone from the deployment team working in the scrum team who would actually do the implementation. The team itself would then support the new feature through it’s UAT phases and out into the customer’s live environment.

The second failing I mentioned was the team goals. I have already alluded to this but the goal of the team was to “write this feature” whereas it should have been “deliver this feature to the customer”. Only once that goal has been met should they move onto the next one.

This continuity and accountability is a very powerful thing. Projects fail when departments don’t communicate with each other or their priorities are not aligned. Systems slow when there’s too much Work in Process (for example incomplete UATs) clogging up the pipeline and generating unplanned work. If you want to break out of this cycle you need to stop thinking about departments and handovers. Stop thinking of scrum teams as groups of developers delivering feature after feature and start thinking of projects being created and delivered by teams of people from all the disciplines you need.

If you can do that, then you can make your scrum team work for the business and not only for it’s own productivity.

The Goal Book Review

I recently finished reading The Goal by Eliyahu M. Goldratt. This is the book which is referenced in The Phoenix Project and Rolling Rocks Downhill so I was determined to get my hands on a copy and read it!

Alex Rogo is a Plant Manager, work isn’t doing so well… in fact he’s been given an ultimatum and is about to get shut down. In order to save his job he enlists the help of an old teacher who persuades him to question the standard measures and processes he’s been using his whole career.

What follows is a very interesting and in depth look at the Theory of Constraints (although I don’t actually believe the term is used in the book) as the team try to identify the bottlenecks in their plant and work on ways to exploit them.

Like the best books Eli doesn’t try to throw too many concepts at you, his message is clear – find the bottleneck and organise work around it. There are some great analogies (such as Herpie leading his fellow boy scouts through the woods) and you genuinely feel like you’re working these problems out alongside Rogo.

The last few chapters felt a little disorganised to me but they they carried an important message – build up the process of how to examine your system, don’t just rely on a defined step by step guide. Continuously review, understand, and adapt.

Would I recommend The Goal to other IT Managers? Absolutely! You’ll gain a great understanding of how to observe and measure your team’s throughput.However, I’d say it’s absolutely essential for anyone in software development to read The Phoenix Project first so you understand why we’re looking at manufacturing plants to help us run IT departments!

Monitoring Support Ticket Age

There are various ways you can monitor how effective your support process is. You can record the number of tickets opened and closed, you can keep track of queue counts, or you can ask your customers!

When I develop a KPI I want a simple numerical value, something I can examine, track, and use to decide whether we are improving or struggling.

One of my favorite statistics to measure is the average age of tickets in the queue. The benefits of this are:

  • You can calculate it at any time and don’t need to measure tickets added and closed for a prolonged period of time.
  • You can get a feel for how long tickets are sat waiting for a resolution.

In other words it gives a rough value of how long a customer can expect to wait before you respond to them.

However, as with all measurements the act of measuring it can change the result. In our world this can have a very direct effect, if you only focus on how old tickets are you encourage a First-In-First-Out approach (as Developers and Support Analysts fight over the oldest tickets in an effort to bring down the average). This can undermine your attempts at ticket triage and prioritising.

This is a known risk when working out KPIs for your team. KPIs are often easy to manipulate (in our example a developer choosing to pick up an old P4 ticket over a new P1). It’s a risk yes, and any skilled problem solver will quickly work out how to game this measurement if they need to. However, I would hope you have enough confidence in your team to feel confident they will not to ignore urgent tickets for the sake of an arbitrary numerical goal.

What’s important is identifying the behaviours you want to encourage in your team. One of my first priorities in any role is to give customers a good level of service (and make sure they aren’t kept waiting too long for answers and support). If I want to achieve that I need a value which helps me record it, until I find a better one ticket age is my KPI of preference.
What KPIs do you use? Make your suggestions in the comments below…