Split the Bills B2B Project

Screen Shot 2018 07 12 At 17 17 55

​Hive IT were engaged by Split The Bills to lead the development of a new platform for their business clients. We worked hand in hand with their existing team, adopting new cloud technologies and agile ways of working to transform the flexibility and capacity of their IT team.​​

the challenge

Split The Bills had identified the need for a new service that would bring real value to their business customers, whilst also streamlining manual back office processes. UX design, back end system integration and front end architecture was needed to bring their idea to life.

There was also a strategic need to adopt new agile ways of working and new cloud based development tools to increase flexibility and delivery capacity of their existing IT team. Recognising our skills and experience, they engaged Hive IT to help them achieve these goals.

the result

The new service is now live after a mammoth effort by the entire team to overcome the challenges faced during the project. This new service means that Split The Bills have enhanced their existing product offering, are attracting new customers, and can support their wider team to really focus where they’re needed.

We engaged the Hive team to help us create a product which would allow our customers to track their energy usage throughout the year, something we’d wanted to do for a long time but struggled to make a reality for many reasons. As part of the delivery, we also asked Hive to help us develop improved ways of working which we could continue to use for future projects. Hive seamlessly integrated with our existing development team and their wealth of experience was the key to our success. The importance they placed on user experience and customer input allowed us to create a product which fits our users’ needs rather than just our own.

Lauren White
Business Change Manager
iterative process illustration
1.

approach

From previous experience we knew that embedding within a team is more than just turning up on-site on day one. We wanted to build an effective, cohesive and collaborative team with Split The Bills.  To achieve this, we tried to gain a better understanding of the business as a whole prior to the work commencing. We spent time outside of work with the Split The Bills team in social settings and made an effort to understand how Split The Bills technically worked on a day-to-day basis. Laying these foundations from the outset ensured that we built transparency and solid relationships, allowing the whole team to feel more comfortable with each other and gaining early visibility of any pain points.

mixing bowl of colours illustration
2.

Thoughtworks consultancy

Split The Bills had organised for ThoughtWorks (a well-renowned industry consultancy) to provide an initial 2 week consultancy to determine the product vision for this project in context of the wider business directives. It was mutually agreed that Hive should be on-site during that consultation period to understand the solution as it emerged and be fully involved in its inception.

During the consultancy we worked with Split The Bills and Thoughtworks to:

  • Investigate the technologies required for the project;
  • Complete technical spikes;
  • Participated in workshops allowing us to get an excellent oversight of the overall business;
  • Identify and set up base tools to be used over the course of the project;
  • Define a sprint structure; and
  • Plan and agree the backlog, including Sprint 0 tasks.

STB Retrospective
3.

project flow

During Sprint 0 we began to lay the project foundations such as the initial application skeletons and the continuous integration/delivery pipeline . We worked hard to define ways of working which would provide the greatest value to the team and the project. This included (though is by no means exhaustive) organising Three Amigos sessions, defining the definition of ‘done’, deciding how and when to release code and defining acceptance criteria for testing. These ways of working were reviewed and adjusted by the team following retrospectives throughout the project.

It wasn't all smooth sailing though, Sprints 0 to 2 weren't without their difficulties. It became apparent that the team and business expectations were optimistic and as a team we were over estimated our sprint deliverables (which is perfectly normal at the start of an Agile project). The hope that scrum master responsibilities could be split across team members wasn’t viable and we soon realised that the MVP scope was unlikely to fit in the available sprints. Despite these setbacks, we maintained an excellent relationship. We talked, we iterated, we evaluated, we found new ways of working - and we realigned expectations. By taking a step back and evaluating what was and wasn't working, we were able to pull together as a team and drive the project forward.

By Sprint 3, things settled down. The adapted ways of working began to come into force, we became more accurate in our estimates, and we adjusted how sprint planning was conducted.

different demographics as people illustration
4.

user centred design

Split The Bills had given Hive the directive to take a user focused approach to delivery. This meant ensuring that our user research and design team had a very structured backlog for Sprint 0 so that their work could feed in to the development team. Prototypes were developed based on the defined MVP from the ThoughtWorks consultancy. These were then paired down to provide a Sprint 1 delivery prototype for the reference of the development team. The research team also conducted workshops with key business stakeholders to understand their users and the aims of the product.

Following Sprint 0, the research team took the prototypes out to users, conducting face to face user testing, remote user testing utilising Lookback and telephone interviews. The analysis of this research was fed back to the team and wider stakeholders, with recommendations given for adaptations. These were taken on board resulting in changes to the planned MVP design and functionality.

The user research team continuously and iteratively completed user testing through much of the project lifecycle. They also continued to provide updated prototypes and designs to match with the sprint deliverables. By starting their research and design during Sprint 0, they were able to feed their findings in to the backlog ahead of the development teams upcoming sprints. The user research and engagement in this project was a success and helped add value to the changes in the deliverable.

laptop with various source lines illustration
5.

technical solution

Split The Bills’ day-to-day operations are based around Salesforce (an enterprise CRM), thus the new customer facing application needed to be able to integrate with it seamlessly. The challenge here would be to accept data from Salesforce in real-time and transform it into a format that would be easier to work with in the new application’s domain. A decoupled solution was also desirable to enable the business to move away from its reliance on Salesforce in the future.

To solve these integration challenges, the development team decided to create a data pipeline between both systems. The first part of this pipeline involved subscribing to Salesforce via PushTopics, using a separate microservice that would act as the ‘conversion layer’. In the second part, the ‘conversion layer’ would sanitise and restructure the incoming Salesforce data before publishing it to a message queue (implemented with Apache Kafka) for the customer facing application to consume.

The customer facing application was built as a single page application, using a Spring Boot REST API for the backend and Vue.js for the frontend. Proposed prototype designs from the user research and design team were accurately followed in the frontend UI. Supporting this application, we used a PostgreSQL database for persistence, Redis for caching, and finally Auth0 for user authentication, role and API security management.

To coordinate the continuous integration and deployment of the entire system, we employed a combination of GitLab CI and Kubernetes. Our builds were containerised using Docker before being deployed to Kubernetes environments. We opted to use Kubernetes as it made maintaining and deploying all of the infrastructure easy.

6.

the finished product

Early in the project, we realised that achieving the full scope of the originally proposed MVP would not be possible within the project timeframe. Consequently we worked with Split The Bills to re-prioritise tasks which needed our input to push the product as far as possible. This meant that by the end of our involvement, there was a clear product roadmap and the remaining tasks were achievable for the existing Split The Bills team.

The product moved into a ‘live’ state after two further sprints following our involvement. Split The Bills held an internal celebration to mark the launch and feedback has been very positive. The sales team are also using the feature to demonstrate to potential clients, providing new opportunities to increase their revenue.

get in touch

related case studies