We have recently delivered a project for Jardine Lloyd Thompson (JLT) to re-design and build their World Risk Review website. We’re currently in the final hardening sprint, doing some bug fixing and UAT. We’ll be able to talk more about the benefits in a case study, once the site has been live for a while and we can look at the analytics. In the mean-time I want to discuss some of the great bits of innovation (both tech and process) we have produced in delivering this project, which was just 8 weeks in total with only 6 weeks of development.
What is World Risk Review?
World Risk Review is a country risk ratings modelling tool that JLT founded in 2006, providing corporations, banks and other organisations involved with international trade and investments with an assessment of short to medium term country risk. This allows users to build well informed strategies to manage political, security and economic risks.
JLT is the only Insurance Broker to have invested in this capability in-house so they required a really modern website that would allow users of World Risk Review to have an intuitive and highly informative experience when consuming JLT’s expert advice.
What did we do?
World Risk Review is made up of three key areas – peril ratings data for each country, key insights (articles, insights, reports and blogs) and news. Red Badger’s role was to make these three areas easily accessible, engaging and informative. With more and more devices being used in the financial services sector, it would also need to work on tablet and mobile. So as well as being visually rich, the site would also need to be lightweight with regard to page size so that it remains speedy on mobile devices.
We designed the site using a visually rich set of dashboards to allow users to consume the data in a really intuitive way, compare different types of data and perform country comparisons. This is underpinned with easy navigation throughout the site via the dashboards and a flexible and fast search function.
How did we do it?
The site is effectively made up of two applications. The main website and a custom built admin console which consists of an analytics section as well as a custom built content management system (CMS) that provides the ability to do inline editing of content, preview of changes and deployment straight into the live environment.
I am not a techie, so I’ll ask the developers of the site to produce some more technical blogs with more detail (They promise me these are to follow!). However, below is a brief outline of how we delivered the project.
Last year we re-built red-badger.com as a static site. We loved the results so decided to follow a similar technical architecture for World Risk Review. The static site generation architecture deploys the site at the time that content is updated so that when users access the site, they are accessing a very simple static page rather than requesting content from a database for each action. The result is a website that is more secure and can serve pages much faster than traditional Content Management Systems (such as Drupal). The site is deployed to an Amazon S3 bucket and distributed via Cloudfront to 51 edge locations around the globe. Originally we were using Docpad as our static site generator (as we had for red-badger.com) but we found it started to really slow us down so we built our own static site generator which brought down the time it takes to generate the HTML from the source markdown documents and Jade layouts from about 90 to about 6 seconds . This allowed us to work much faster and also enabled us to build a CMS where you could preview your changes almost in real-time. Having tested the application around the globe, it is incredibly fast wherever you are, with as little as 10 milliseconds and no more than 300 milliseconds to the first byte.
The final piece of the puzzle and by no means the least important, was to build in analytics. Using the power of Elasticsearch, we built a tag based analytics tool that allows JLT to monitor user behaviour on the site. They can add custom tags to each user (such as “watch list”), filter, sort and search. This gives JLT a quantitative view of customers behaviour to allow them to adapt their future strategy around what their customers want.
Given that we had only 8 weeks to deliver the project of which 6 weeks were for development, we decided to use Kanban as the methodology of choice, reducing as much friction in process as possible and allowing the developers to do exactly that – develop. The backlog was tightly managed by Sinem (the project manager) and the product owner from JLT who was deployed full-time to sit with us in our office every day. I cannot stress how important it was having the product owner integrated into the team full-time. We managed user stories on a Kanban Board and although physical boards are great, the developers managed all tasks in Github. This reduced duplication of effort, increasing productivity. Stand-ups each morning were held around the Kanban board, talking about what we had been doing at story level and we were focussed on getting stories through to delivery as soon as possible so used WIP limits to streamline the process.
To ensure quality control, we used Github flow to manage the process of building new features, ensuring that no piece of code is deployed without first going through code review by a 2nd pair of eyes. There are some simple rules to Github Flow: 1) Anything in the master branch is deployable. 2) To create something new, you create a new branch off of master. 3) You continue to commit to that branch locally until your feature is complete. 4) When you think your feature is complete, you raise a pull request. 5) Another developer then reviews your code and upon sign-off it can be merged to master. 6) Continuous Deployment then deploys your changes immediately.
When delivering a project at this speed, it is paramount that your features are tested properly. To do this, we integrate a tester into the team and get them to test as soon as a feature is deployed. In the past we have used separate tools such as Youtrack as our bug management system. However, in this project, we switched to Github issues. Having one central place for the developers to see all features and bugs together in Github has most certainly helped productivity of the team.
In just 6 weeks of development we achieved an incredible amount. We had an integrated team of Project Management, UX, Design, Dev and Test, all dependent on constant communication to get the job done. We built an exceptionally well designed, useable site on a really innovative tech stack. The use of Kanban, Github Flow and Github Issues proved to be an incredibly productive way to deliver the project. It was a very intense environment of rapid delivery but was lots of fun too. JLT were a great client not just in allowing us to be innovative with our tech and process, but also in the efforts they put in to make this collaborative. We couldn’t have delivered so quickly without their constant involvement.
As always, there is room for improvement in our process and the tech team are looking forward to new technology emerging such as those contained in the Web Components spec. Our project retrospective has highlighted some areas for improvement and we will continue to iterate our process, always pushing to try and provide our clients with better value. We have loads of great ideas about how the World Risk Review site can be improved in future phases but after 8 weeks, it is currently in a great place to deliver a far improved experience for both JLT’s customers and their admin staff.