Welcome to the next part in the series on the evolution of Engineering at Rentalcars.com (aka BookingGo these days) over the last few years. The next few blogs are focused on Delivery, Ways of Working and our Product Evolution.

Delivery and ways of working

The ambition in 2015 was for BookingGo to become a business that has truly adopted Agile ways of working. A company in which we organise ourselves using a product-based, not project-based, culture. For a business that is going through hyper growth, has legacy technology and delivers a huge amount of incremental product changes weekly, this isn’t a small feat. In BookingGo we call this “Changing wheels on a moving car”.

At the time, technology was split into two parts: Front End (FE) and Internal System Engineering (ISE). ISE at the time consisted of Software Engineering and Technical Engineering (Infrastructure, Service, IT Services) and mainly focused on services and the platform. We also had plenty of challenges with competing priorities due to dependencies and no clear single version of the truth of work needed to do.

Our initial focus for the first 12 or so months was on ISE and tackled this in a multi-faceted way:

  1. At the time, we had a Project Management Office and we worked with the PMO team collating all work and changes, whether explicitly requested or not, so we had one view of the work to do.
  2. We regrouped ISE into three groups aligned to key parts of the business and assigned business owners. This was our first iteration towards the Product groups we see today (two years later) and each of the groups had a domain of responsibility.
  3. Work was then allocated to each domain (i.e. by group) and our Engineering Managers would meet every two weeks with Business Owners to prioritise the work.
  4. Engineering Managers and the PMO would issue status reports every couple of weeks to surface progress.

This took a while to bed in, but really started the groundwork for shifting to Domain based Product teams because both the team and the business saw the benefit of having work prioritised within a team. We also started to form a hypothesis that a platform (backend ISE) team was dated and instead should be a number of Domain based Product teams.

Plus, we recognised that the team needed help with Delivery and Engineering practices. Even though we weren’t a fully adopted product-based organisation at the time, we knew that an Agile team needed three key hats (roles) to be a success:

  • Engineering leadership
  • Focus on delivery
  • Ownership of defining the requirements

Engineering leadership

As per the previous blogs, we tackled this area by introducing the Engineering Managers and Engineering Lead roles. We continue to iterate and evolve these roles as our organisation grows.

Delivery & requirements definition

We had P in place and were mindful to not confuse the organisation or ways of working. Initially, we tried using some of the Project Managers as Agile Project Managers. However, this didn’t really help us reap the rewards we wanted – for a number of reasons:

  • Agile and projects collide
  • The business still hadn’t transitioned to Product teams
  • We had an FE and ISE organisation
  • A lot of dependencies, which meant that work was being forced into programmes of work

With that in mind, we adapted the Project Management Office to operate like a Programme Management Office from a project-based approach where so that they would manage programmes of work across multiple delivery teams.

We then introduced two new roles into the business: Delivery Lead and Business Analyst.

  • Delivery Lead
    These roles were a combination of Scrum Master, Project Manager and Agile Coaches, but had a strong Agile background rather than a project or programme mindset. We started off with three Delivery Leads: one per group.

  • Business Analyst
    These roles were focused on shaping the requirements and starting the concept of backlogs.

These roles were partners to the Business Owners and Engineering Leadership.
In addition to the new roles, we started to introduce some basic Agile concepts into the business:

  • Backlogs on JIRA
  • Stand-ups
  • Retros
  • Two-week sprints

Whilst all of these seem very simple, running effective stand-ups, retros and sprints is no easy feat, because it requires a cultural and mindset change, along with the tools, technology and business to support the evolution.

Rentalcars Agile Delivery

With the growing need for us to ingrain Agile ways of working more into our business, we developed a tailored Agile framework for the business, which we labelled Rentalcars Agile Delivery (RAD). It provided some solid foundations for teams, organisation design and ways of working.

We built the framework in collaboration with Software Engineering, Delivery Leads and the PMO. Out of this was born our Agile Delivery function: we joined the PMO and Delivery Leads to create an Agile Delivery function, and we rebranded our Delivery Leads as Agile Leads.

Whilst today we wouldn’t phrase our Agile ways of working in BookingGo as RAD, this framework provided a lot of foundations for our ways of working and culture today.