Category: Management

The Importance of your Local Development Community

~ Adam ~ 1 Comment

I recently saw a post on LinkedIn, I’m fairly sure it was an advert for in house training but the message rang true. One manager turned to the other and said “If we train our developers they’ll get better and leave!” To which the other manager replied “But worse, if we don’t then they might stay!”

One of the most common reasons I hear from departing team members is boredom, that they want to go somewhere else and learn new things, use new technologies, and learn from other people. I myself have preached to friends on many an occasion that you learn more in your first few months at a new job than all the time afterwards combined.

You want the most eager, hungry, and interested developers on your team. You want to be able to retain them by introducing them to new ideas. It’s also your responsibility to keep your long serving members of staff from stagmenting and falling into a development rut.

The answer is often closer than you may think!

Local groups of developers are not hard to come by. I’m based in Leeds and to my knowledge we have Agile Yorkshire, Leeds Sharp, Leeds Code Dojo, and Leeds DevOps. Groups of people who meet regularly to discuss ideas, listen to speakers who bring new and exciting topics to the table. By visiting these groups I’ve been introduced to AngularJS, Microsoft Cognative Services, F#, .NET Core, and many many more…

By encouraging your developers to attend these events you motivate them to go out and find new ideas and technologies. Far better for them to have a night out, come back full of new knowledge than decide they’re fed up of using the same technologies over and over.

So how can you encourage participation in these events? Why not arrange to go as a group? Encourage someone to speak and bring the team along to support them. Plan a team night meal afterwards or ask someone to bring ideas back to your own internal training. Who knows, you may even bump into your next hire while you’re there!

Monitoring Support Ticket Age

~ Adam ~ Leave a comment

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…

Creating a Valuable Signoff Process

~ Adam ~ Leave a comment

We all have them, a series of tests which need to be run before a build is considered good enough to be released to a customer. You may have different scripts for different stages of release (Alpha/UAT/Live), you may have different processes depending on the severity of any bugs found. Whatever your process I’m sure we can all agree that your signoff process is one of the most important pieces of your development puzzle and one of the most vital to get right in order to avoid issues further down the line.

But what makes a signoff process good? These are the things I believe a good signoff process needs to achieve:

  • Detect all unknown bugs in all critical features
  • Quick and easy to complete

Clearly these are at odds, if you want to find every bug then you’ll need to invest significant time! Let’s look at why each of these are so important before we try to find a solution.

The first one is fairly obvious, the most critical parts of your system are the ones which will generate the most urgent Support Tickets. In order to minimise those stressful late nights we need to validate that those areas of the system are as robust as possible.

But why the speed? Why not simply run through every test and permutation before each release (assuming you don’t mind driving your QA team mad)? In this world of Agile Development and quick turnarounds it’s becoming more important than ever to test and release quickly. After all, I mentioned in my previous post about Sprint Planning I suggested that you should aim to both develop and test your new features in each Sprint. In order to maximise your development potential you need to make your signoff process as efficient as possible.

So how do we do this? The key is to target your testing effectively. You need to work with your Product Owner to identify the Critical Functionality which must not fail, these form the basis of your signoff scripts. Other areas of the system can be tested on a rotational basis or when changes are made.

This prioritisation of the most critical functionality guarantees that the vital happy paths are always tested. This leaves more time for the QA team to expand their efforts into other areas while the developers are coding new features. By targeting your signoff scripts you can guarantee a high quality build without the lengthy delays which come from a bloated signoff process.

Measuring Sprint Velocity is Useless Unless You Ship!

~ Adam ~ Leave a comment

I’ve recently been reading The Goal by Eli Goldratt, in it Alex Rogo (the Plant Manager) boasts to an old teacher of his that the new robots they’ve installed have greatly increased their efficiency. The Yodaesque Jonah then promptly proves his data worthless and sets Alex on the path to enlightenment.

What struck me however was how clearly this mirrors the software industry. The Goal has been the go-to book for managers for years but only with the relatively recent release of books like The Phoenix Projext have the applications to software industries been recognised.

It’s a well established idea to model a software development team like a factory. Time and money goes in, features and fixes come out. In the story Alex was delighted that his robots had given him an increased efficiency for making a particular part of the process, it was only when Jonah pointed out that the robots did not result in any increase in sales that he saw the problem in his logic.

So, let’s imagine that our software business is Alex’s factory. We’ve brought in a robot to do the work of the Development Team and Sprint Velocity has gone up from 100 Story Points to 300. As the Development Manager you get to pat yourself on the back, celebrate your success, and go home at the end of the day.

But what happens to your release at the end of your Sprint? Is your product stacked up on your factory floor awaiting the next machine (perhaps your deployment or infrastructure team)? Or have you sold it and added value to your business?

This may seem like false measurement, your numbers are telling you that you’re delivering but the reality is very different. The truth however is even worse, unshipped features are the software equivalent of Work in Progress, they’re the half finished products sat on your factory floor taking up time and space. Until your business can deliver them they’ll continue to come back and haunt you, injecting unplanned work into your Sprints and sucking time out of your Development Team.

So, If your Sprint Velocity measurements only take into account the work pushed through your Development Team then you’re not measuring the value you’re adding to the business, you’re making the same mistake as Rogo and only considering one part of the system. You may be getting great results, but are you helping achieve the goal!?

Setting SMART Goals for your Team

~ Adam ~ Leave a comment

Annual reviews are often one of those things we do as a box ticking excercise. It’s dull, time consuming and there are often more interesting geeky projects you’d rather be working on.

Words like SMART buzz around our brains for a few weeks and then are promptly forgotten (much like the goals) until the same time the following year when each goal is ticket off as “Done” or “No Longer Relevant”.

Surely there’s a better way?

Let’s look at what SMART stands for…

  • Specific
  • Measurable
  • Attainable
  • Relevant
  • Time Constrained

Your business may have different words but the jist is the same.

I want you to think about these words differently. Instead of writing goals for someone to achieve I want to think about User Stories. It’s reasonable to demand that any PO writing new features for the backlog should create them so they are Specific, have good Acceptance Criteria, be feasible to implement, be a valuable addition to the software, and should fit into a single Sprint.

In other words SMART is just another way of setting detailed and unambiguous instructions!

So now we know that SMART is simply a way of writing clearly let’s look at what goals you should set.

What do you expect your Team Member to be doing for the upcoming year?

This may sound like an obvious question but in my opinion annual goals shouldn’t all be about Continuous Personal Development or an arbitrary “I’d like to lean that” because these are the first things which will be abandoned when you have a tough day. Instead look at what your department goals are and propagate these through to your team.

If you have a major release coming up then set that as one of the goals. If you need to analyse system performance or memory usage then write it down. What you will find is instead of irrelevant targets which will be abandoned in favour of more pressing work your team will suddenly become accountable for getting the releases out to customers. Not only that, but they will see that their day to day tasks are being used to measure performance instead of the “Nice to Haves” which were abandoned as soon as the year hit a rough patch.

You will quickly find that most developers will much rather have a goal of “Create Offline Sync Mechanism as specified in Feature 123 before the end of January” than something vague like “Improve the Support mechanism”. For one thing there’s a lost less ambiguity as to whether it’s actually been achieved! Remember, less ambiguity means fewer awkward conversations when you come to assess goals, that has to be a good thing!

In conclusion, setting clear (or SMART) goals for your team which actually reflect the work they’re going to be doing day to day is a great way of getting investment in your department’s objectives and helping making those annual review forms much more relevant. Learning goals are good, but they shouldn’t be the core of a Team Member’s assessment.

DDDNorth 2016

~ Adam ~ 3 Comments

I was very excited when I saw the announcement of DDDNorth earlier this year. I’ve attended the conference several times before and to see it was once again in Leeds really gave me no excuse not to attend!

Despite having a rather late night the previous evening I was one of the first there, in fact I think I accidentally tailgated a speaker inside and sat quietly in the corner until the masses arrived.

For those of you who don’t know the DDD events are free, one day conferences focused at .NET developers. They’re held around the country and have a very high standard of speakers. DDDNorth is our annual event and usually circulates between the Universities of Leeds, Sunderland and Bradford.

The first session I attended was “Machine Learning for Muggles” by Martin Kearn and it was one of the best geeky talks I have ever attended.

Martin demonstrated how to use the Azure Machine Learning API to upload your own data for analysis. He then took a photo of the audience and used facial recognition and text analysis to ask questions like “show me the happiest person”. Before today I’d always assumed machine learning was only for the likes of Google, before the first coffee break I was already wondering whether I could use the APIs in our own products.

The second session I attended was “10 More Things You Need to do to Succeed as a Tech Lead” by Joel Hammond-Turner. I’d attended one of his talks before (entitled 10 Things You Need to do to Succeed as a Tech Lead) and with my recent change in role I felt it was a wise choice session.

I was right. Joel gave us a good list. It contained tips on requirements, instrumentation, and team training. I was particularly impressed by his thoughts on managing and measuring technical debt!

The last session of the morning was “You read The Phoenix Project and you loved it! Now What?” by Matteo Emili. Having recently bought and demolished TPP while on holiday this was the session I was perhaps most excited about. Matteo argued for pragmatism, he told us that in order to sell process changes the value must be determined. He quoted the common phrase “you can’t manage what you can’t measure” and discussed in depth how you should use the Build-Measure-Learn. There were even a few tips and ticks towards the end to help us get our automation deployments going!

It was lunchtime, which meant sandwiches and GROC talks (I have always been curious to know what that stands for).

I arrived in time to see a few interesting mini-talks. The first was on using the C# interactive window in Visual Studio, the second was around ARM templates for Azure, and the final one was entitled “What’s the Point of Microsoft?” and was a tongue in cheek presentation about how the big tech players compete in today’s software and hardware world.

I’d love to continue, I’d love to tell you about the Microsoft BOT API talks I had lined up for the afternoon. Alas it was not to be, it was around this time that the office called to tell me that several hundred members were having issues with their accounts. No rest for the wicked!

I’d like to take the time to thank the DDDNorth team for putting together yet another fantastic event. The speakers this year were superb and if I get the chance I fully intend to catch the sessions I missed elsewhere in the country at a later date. See you next year!