How do the front end engineering teams work?

At Vodafone, I am regularly asked about how the front teams work — both in terms of their workflow but also how we ensure quality in our code. It’s a tough question — one I respond to with varying answers each time.

First and foremost, there is no right or wrong answer to this question. We try and ask everyone to offer their best guidance and knowledge to ensure the way we work is both effective and efficient. Each developer is tasked with ownership and responsibility for what they write, it’s key to creating a culture of autonomy, mastery, and purpose.

But what does this really mean? To start, let’s look at how we’ve set up our teams.

Who are our teams?

We’ve set up each team to be made up of solely front-end engineers. Each team is a maximum of 6 engineers — alongside a tester, scrum master and a product owner.

But why 6? 🤔 It took some trial and error to get there, but 6 seemingly is the magic number to ensure decent collaboration between team members and ensure we do not create too much complexity. Simply put, more than 6 meant team members were continually stepping on each other’s toes and encountering tedious merge conflicts. (Scrum Guide also gives a nice write up on optimum team sizes).

Each team’s goal is simple, they look after a product vertical — for example, Sim Only 📵, or Handset 📱. It’s important for each of our teams to have a clear focus and clarity — having a single product to manage ensures this. They can then independently manage their own backlog, roadmap, and features — with less friction and impact on who owns what.

We currently have 8 front end teams, all with elaborately stupid names (i.e. Kraken) — However, one big issue became apparent as part of this ❓ How do we ensure team alignment?

The shared component library

This is where our shared library came in. A privately shared repo (for now) that teams can use between projects. It provides front-end developers and UX designers with a reference of UI components and utility styles available to all our web channels. It also provides developers with instructions on how to use the library and a set of API client services to simplify API integration. (This is a big subject — we will have a wider post on this coming soon 😃).

Many companies have created libraries such as this, Material being a very high profile one, alongside many others. But our aim was to create our own, something we have curated, tested and developed ourselves — something that as a team we can be proud of and one day, hopefully, distribute for others to use.

The goals of this library are —

• Reduce the overall cost of ownership 💰 (initial and maintenance) across the channels.
• Improve UX consistency 💻 between journeys and across channels.
• Reduce time to market ⏲ for new/modified journeys in any web channel.

What’s good about it? ✅

Atomic Design — Brad Frost (http://atomicdesign.bradfrost.com/chapter-2/)

Overall the shared library has enabled us to build applications faster, with greater consistency in the presentation layer and with a higher focus on quality. It makes the creation of new web apps that much simpler — giving our entire team a suite of pre-styled React components (categorised by Atomic Design principles, i.e. atoms, molecules, organisms, and templates).

So what’re the drawbacks? ❌

Working in this way is not without issues, we’ve had to put together extensive groupings of developers that are the essential ‘guardians’ for changes within the repo. These individuals ensure stories are well written, the changes required are well documented and that any PR meets extensive acceptance criteria.

Using this gating has caused some bottlenecks, meaning certain individuals within the team are required extensively for releases, PRs and builds — this is something we need to work on.

How do we ensure quality?

Testing is a key part of the software development lifecycle. Within Vodafone it is one of our key deliveries to increase our testing coverage.

We need to be able to measure whether something is good or bad. In the majority of cases, this is done through adherence to standards and best practice set out on our wiki. We then share a series of metrics and KPIs — such as code coverage of >90%.

We are currently using Jest/Enzyme for React unit testing — Unit testing is important because it is one the earliest testing efforts performed on the code and the earlier the defects are detected, the easier they are to fix. Alongside this we are also creating our own end-to-end testing framework — we will share more about this in the future.

We output all these results in SonarQube so everyone in our wider digital estate can see exactly how we are performing at a code level — how many bugs, what our coverage is — it’s key to ensure ownership of our builds, deploys and releases.

Should we change?

This is a question we keep asking ourselves… change for change sake is not something we want to do, but there are always ways to improve.

We have considered the following —

• Feature teams — teams made up of cross-functional resource that can own end-to-end journeys
• Creating bespoke product tier libraries — such as a core shop library for example
• Could larger or smaller teams work?

Thanks for taking the time to read this, we’d be interested in seeing how other development teams are structured, so let us know in the comments 💬