O R G A N I S A T I O N S
A N D
I’m a big fan of the findings from the DORA DevOps Survey, which identifies lead time, mean time to recovery (MTTR), deployment frequency, and deployment failure rate as indicators of high-performing teams – measuring all of these ‘equally’ ensures positive behaviour
WHAT PERSONALITY TRAITS DO YOU LOOK FOR IN IDEAL CANDIDATES?
HOW DO YOU MEASURE SUCCESS AND OVER WHAT TIME FRAME? HOW ARE THESE METRICS DETERMINED?
There’s not really a standard set of traits – it’s down to how each candidate comes across. Tenacity is important, and a willingness to be flexible: Developing and deploying software in a large financial institution has its own challenges, and requires a level of rigour and patience – in essence, it’s a lot harder than simply working on a project at home! Personally, I think it’s important to question and challenge the status quo: The way things have been done, traditionally, often need to change. This needs to be done with integrity – helping the organisation to evolve, rather than trying to ‘go around the side’. Also, it’s not really a personality trait, but we need engineers who possess skills at the intersection of infrastructure and software development: We have infrastructure engineers, and we have software developers – those who are strong in both areas are increasingly valuable. HOW ARE EMPLOYEES RECOGNISED FOR THEIR EFFORTS? Within our wider team, we make sure we highlight and celebrate successes, and noteworthy efforts from both teams and individuals. Within the wider GTIS, we also have a mechanism (known as ‘Thank-You Tuesday’), allowing everyone to highlight and recognise when colleagues have gone over and above their role to help others. Having said that, it’s important that we don’t celebrate ‘heroics’ too much. Sometimes it’s necessary, of course, but our work should flow in a sustainable fashion, and we don’t want people working crazy hours simply to keep the lights on. Barclays also has a number of internal awards and recognition mechanisms both for technical excellence, and our ‘Better Products, Faster’ awards, which are for teams finding better (and more agile) ways of working within Barclays.
T E S T M a g a z i n e | N o v e m b e r 2 01 7
S T A N D A R D S
This is critical, in my opinion. I talk a lot about ‘eliminating gut feel’, and being able to show in concrete terms when things are improving (or not!). We use tools like JIRA and Agile Central to track work, and we can pull out metrics like lead-time and cycle time from this. I’m a big fan of the findings from the DORA DevOps Survey, which identifies lead time, mean time to recovery (MTTR), deployment frequency, and deployment failure rate as indicators of highperforming teams – measuring all of these ‘equally’ ensures positive behaviour (e.g. simply measuring deployment frequency might result in frequent but low-quality releases – measuring deployment failure rate as well corrects this). We try to track the team and product level (never at the individual level), and I’m very conscious that measuring the wrong things can drive the wrong behaviours, so it’s an art. WHAT CONTINUING LEARNING OPPORTUNITIES ARE AVAILABLE FOR BARCLAYS EMPLOYEES? We had a lot of internal training available, and various mechanisms (classroom, online, etc.). We also encourage all our team members to spend some time educating themselves – a lot of the things we’re doing have come out of ‘side projects’, and things people have been looking at in their spare time. So we’re keen on self-learning, and experimenting, although we’re also clear on when an ‘experiment’ needs to be productionised, and more rigour applied.
Assisting the most adequate tests possible, software testing tools help to defeat repetitive, vulnerable operations – replacing the human el...