I’m Mark, a Product Manager in Plymouth on the Local Land Charges Team.
You may have read how Land Registry is creating a Local Land Charges register, which will host the data of 326 English local authorities. As this work is well underway, I thought I would give you an update on the build of the register.
We’re using agile techniques with Scrum to develop the service. We’ve just completed Sprint 6 which signifies over 12 weeks into the development. We’re operating two-week sprints, with a three week ‘Sprint 0’ where we formed as a team:
The team is currently in the Alpha phase, which is focused on understanding the functions required by local authorities to update the register either through a web browser or via an integration with existing local authority software.
The key to making our service delivery a success is to identify and work with a range of users to ensure the service we build meets their needs. This requires capturing user stories and then asking the team to construct solutions to meet the need, all the time testing different ideas with the users to ensure we remain on track and have understood the need correctly.
We use the illustration below to show the shape of the entire service and the scope of the Alpha phase. Many users require access to the Local Land Charges register – each with different needs and requirements. This is why it is so important that we invest heavily in user research.
We want to develop a product which is simple, intuitive, fit for purpose and allows local authority staff to maintain the register. There will be a digital service accessed via a web browser for users to add, update and archive charges on the register. Our preferred solution is that the current systems in local authorities will update the register automatically wherever possible.
To understand this area we’re working with the suppliers of local authority software to ensure that technical decisions are made which will enable integration to be as smooth as possible. The suppliers have also been invited down to meet the team in Plymouth so they can see how we’re developing the register and help us build the digital interface (API) in a way that meets their needs.
Building the system
On that note, we often get asked about the technologies used by our team. Given the vast range of technology available in the digital world today, we have let the 19 members of the team decide what works best for them, balanced against things like the stability of each technology chosen, the support available for a technology when things go wrong, the learning curve to use it, and whether we already have skills in a particular thing.
For the Alpha, we’re developing in Python as we already use that in Land Registry for some of our other digital services and it works well for us. We’re using modern build and deployment technologies such as Docker and Jenkins. As for the database technology, the team have trialled MongoDB, but decided on PostgreSQL and PostGIS, making sure that the service supports the user need for identifying land charges using geography (spatial queries).
Another area we often get asked about is our approach to registers within government. We’ve been working with the Government Digital Service to make sure we implement a register according to the published specification, and we’re going to write a separate blog to describe our journey so far; watch this space!
I hope you have found this blog useful and if you’re interested in helping us build this service then please get in touch.