Smart tech for SMARTY: How we built the UK’s first lean mobile network

To deliver in an agile way, the organisation and delivery teams must have high levels of trust. That’s a foundation that flows through all interactions and aspects of the project. When we worked on SMARTY, mutual trust enabled us to reach decisions quicker, have lighter meetings, fewer presentations and less paperwork. Freed from all this, the team could focus on delivering and creating real value.

It was important for us to have lots of autonomy, too. We had enough management buy-in and power within the team to make decisions. We worked as a single delivery team.

The people on that team had the authority to make big decisions with a very short reporting line up to the CEO.

This meant we could discuss and decide in hours, not days, and allowed our feedback loops to be tight. For example, when deciding between email services to use, we put the different options on the table, made the criteria for assessment clear to everyone in the room, made the choice and moved on. On corporate projects it can take take weeks or even months to get to an answer for a small decision like this.

Having this trust + power combo allows the team to flex to meet the agreed outcomes. To deliver SMARTY, we adjusted our scope to fit the time we had. This included making some tough decisions about what would make it into the first release. This would not have been possible in many other environments.

We used a mix of technologies on the SMARTY build. Both battle hardened, productive tech we know well, like Ruby on Rails, and new tech, like Kubernetes, React, Docker and Azure.

By maintaining a mix of new and tried and tested tech, we could take sensible bets on new tech without jeopardizing project timelines.

We wrote central bits of the platform, like a core backend API layer, in Ruby on Rails. Rails isn’t the cool kid on the block anymore, but it’s hard to beat for what you get out of the box and what you can add in from the community. By exposing a simple API to the frontend, written in React, we could largely decouple it from backends. That gave the teams a great deal of independence.

Our backend API layer acted as a middleware to a variety of vendors we needed to integrate with. For instance, one vendor provided a set of Mobile Virtual Network Operator (MVNO) functions. Often, custom functionality was being built into these solutions at the same time as we were developing ours.

There were several advantages to maintaining a frontend/backend split:

• Integrating with a moving target often means things changing, rework and extra cost. By keeping this logic in the backend, we kept the complexity in one place and ensured it didn’t spill out to parts of the frontend too.
• Early on, as the vendor backend wasn’t fully developed, we could stub data responses and not block the frontend work. When the real APIs became available, we swapped out the stubbed data for the real thing, with no extra development impact on the frontend.
• The frontend and backend teams communicated over this consistent API interface. It served as a contract between them. By adhering to this spec, the teams could develop and estimate independently.

Sometimes you have to stop, take a step back and look at what’s in front of you. Today’s technology, the abstractions it presents, and the tools available to every developer on the planet are incredible.

A small team of developers can achieve a lot when unencumbered by legacy technology and process.

Want authentication in your app? Hey – there’s a library for that and it takes 30 seconds to configure. Want to run your app on any platform? Install Docker, configure this little thing and run this command. Want your app highly-available and geo-redundant? Oh, that comes as standard, you don’t need to do anything.

This is the world we live in now, so why the big team? We built SMARTY with a fantastic group of engineers, but there were only four of them: 2 Ruby on Rails/devops engineers and 2 React engineers.

Why is this great? It means they can focus on the product, the client needs and most importantly, on the customer.

In short, the engineers can use their time to solve business problems and deliver huge value.

We wouldn’t have been able to hit a tight timeline, working with new tech and trying to integrate against a moving target without the right mindset.

A focus on outcomes is really important. Initially, the biggest outcome we were trying to get to was “build and launch within 6 months”. Everything else fell in line behind this.

This meant we weren’t focused on features delivered – we only needed the features that supported a successful launch. And the features that we developed didn’t have to be all singing all dancing. In the first instance they just had to work.

By contrast, other objectives – good test coverage, minimal defects reported, feature completeness – while still important, had to play a subservient role to the outcome.

Having said all this, the bottom line is simple.

In 2017, a small team with enough autonomy, smart tech, and ability to adapt to changing requirements, can build great things, very very quickly.