During our evolution to date, we’ve focused a lot on surfacing work and introducing Agile concepts to the team; at the same time, we really needed to start to embed different ways of working with regard to Engineering and quality. At the time testing, Test Driven Development (TDD) and Non-functional Requirements (NFRs) were not really understood.
Nor did we have a set of Engineering standards for building our systems. I am not a huge fan of the word ‘standards’ as it doesn’t provide teams with the flexibility to tackle problems in the way they need to. So, with that in mind, we coined the phrase ‘Engineering Defaults’, which could be overridden if there was a better way of doing it or a different (or new) use case.

NFRs

We introduced NFRs through creating a set of defaults. Our first iterations were:

  • Performance
  • Availability
  • Scalability
  • Security
  • Supportability
    We also came up with a further 50 NFRs to consider: accessibility, usability, etc.

Tech Radar

We introduced a Tech Radar, which had our default technology for both Software and Data. We used the following constructs for our Tech Radar:

Picture1

Themes on our Tech Radar for the Software & Application perspective:

  • Application Development
  • Build Tools
  • Scripting
  • Resilience
  • Messaging and Data Stream Processing
  • Front End / GUIs
  • Service Orchestration / Maintenance
  • Logging
  • Data Exchange
  • Scheduling
  • Testing

Themes from a Data Perspective:

  • Operational Databases
  • Data Warehousing & Business Intelligence
  • Caching / NoSQL Technologies
  • Full Text Search
  • Event Backbone
  • Configuration Stores
  • Object Stores
    Our Tech Radar continues to iterate and evolve today.

Engineering Defaults

We also introduced the concept of a Journey of User Story to live, which effectively gave the team guidance on the Engineering defaults to consider when building a new story or feature into the code.

Picture2

Testing

In addition, we started to build out the test team, with an ambition of having at least one tester per team. There is a lot of debate out in the industry as to whether we need testers in the team as developers should automate everything. My view on this is slightly different. I believe we need testers, but the role of test is evolving – from a situation where testers get some work thrown at them to test, to being much more in the early stages of the Software Development Lifecycle. As our test capability evolves, testers focus on shaping requirements to be testable, and on exploratory testing, test education and risk evaluation. Today, we’ve gone from three testers in our organisation to over 30, with testers at all levels of the career paths.

We also introduced testing tools such as SonarCube, TestRail and BrowserStack to start evolving our test case management, introducing test automation and raising awareness of code quality.

Summary

We made a lot of changes in Engineering with ways of working. Some worked and some didn’t. Some of our key learnings were that culture is key and change takes time to embed through the organisation. We also learnt to reduce our focus so we didn’t do too much at once.
And we made a choice not to use external companies to drive the change because we wanted to build the capability in house, so it had more longevity.
We will share more on our testing strategy, technology defaults and engineer practices in future blogs.