Month: December 2016

What I Read in 2016

~ Adam ~ 1 Comment

This post is shamelessly inspired by John Sonmez’s blog post Books I Read, seriously 72!? I need to get an audible account! Here’s my list:

IT Related

Always space for some geeky books on my shelf!

The Phoenix Project

img_0319

This is possibly the most important book IT managers can have on their bookshelf at the moment. The Phoenix Project illustrates how systems thinking can be applied to IT and shows you how futile software development is without it. If you’re going to read one book in 2017 make it this one!

The Goal

220px-the-goal-bookcover

An oldie but a goodie, I did a book review on The Goal recently and I have to say. Once you’ve read The Phoenix Project if you want to go a little deeper then this book is absolutly essential!

Rolling Rocks Downhill

img_3736-1

This is a book I’ve quoted from several times before, Clarke came to speak to us at Agile Yorkshire and I made a point of picking up his book. What I love about this book is how Agile ideas are developed as solutions for problems the team is having, rather using methodologies and presenting them as solutions to your problems.

5 Disfunctions of a Team

dysfunctions

This one was recommended to me via a colleague, it’s a great quick read and essential reading for anyone works in a team (therefore pretty much anyone). I’ll do a review of it sometime soon, recommended reading!

 

Personal

Although my wife doesn’t believe it I do occasionally read books which are not work related!

The Mermaid Singing

516xlezdovl-_sx330_bo1204203200_

My wife reads dozens of books where people are brutally murdered and has always encouraged me to do the same. While we were on holiday she talked me into reading a the first of Val McDermid’s Tony Hill series and I have to admit I loved it. I’m reading The Wire in the Blood already!

Divergent, Insurgent, and Allegiant

divergent-series

I actually really enjoyed these, I’ve seen the Shailene Woodley films on the shelf at the supermarket and have held off on buying them until I’d read the series. I’d expected another Hunger Games or Twilight Saga and while I wasn’t too wrong I loved the idea of the factions system. A good read, loved the twists and thought the big series twist was inspired.

 

8 books, nowhere near John’s 72 but still a good list. What have you read this year? Anything to add to my list for 2017?

 

The Goal Book Review

~ Adam ~ 8 Comments

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!

When and Where to Automate Testing

~ Adam ~ Leave a comment

A year ago I undertook an interesting piece of R&D to write Selenium tests for our main UI. I watched the pluralsight course, learned the difference between WebDriver and the IDE, and started building my Page Object Model. My simple test took the best part of three weeks to build and executed in around half the time a decent QA would take if you gave them a double shot of espresso.

I patted myself on the back, demonstrated the work to our Product Owner, and then advised that we should shelve the work because I wasn’t confident to hand over the mind boggling complexities of waits, framesets, and inherited view models into general practice.

Over time I lost confidence in the project. If it had taken me days to generate even the simplest of tests how would a junior developer fair when asked to automate complex financial scenarios. Quietly I put the idea to the back of my mind and concentrated on other more pressing matters.

That was until last week. We’ve been doing some work on our BACS integration and as part of the regression test I’d enlisted the help of one of our QAs to mock each response code and import it into the system. The process was tedious, repetitive, and I hated myself when I had to tell him he’d missed a vital check off each scenario.

As I was speaking to him cogs in my head began to turn. I’d gone off the idea of large scale test automation because of the complexity of our UI but the BACS processing system doesn’t have a UI. I could knock something together in a couple of hours which would create customers, mock BACS files, and schedule our JobServer. Even more powerful, if I used a technology like SpecFlow our QA could write the tests he wanted, I could automate them, and we’d be able to iterate over every scenario within a couple of minutes. Even more exciting was the idea we could send the feature files off to our Product Owner and banking partner and ask them to verify the behaviour was correct.

Later that week, after we’d proven our project to be a success and found a handful of low priority bugs to be corrected I started to wonder why this automation project had delivered such value where the previous UI automation had failed. I decided this was because:

  • The BACS process was an automated mechanism already so the test automation steps were simpler
  • The UI had been designed for human use, it wasn’t a chore to run through but it was complex for Selenium to navigate the controls
  • Mocking and importing BACS files was repetitive, slow, and tedious

The project turned out to be a huge success, we’re already planning on how we can expand the solution to cover other payment integrations such as SEPA.

The next time you’re considering whether or not you should automate an area of testing consider the nature of the tests. Do they use complex UIs? Do you have to repeat very similar tests over and over again? Do they currently take up a large portion of your testing cycles?

Try to automate the hidden process which run over and over and you wished you could test every time if you had the time!

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…