When you’re developing a product it’s really important to get a good understanding of your users and the problem you’re trying to solve. It’s really easy to get caught up in all the cool features that your product could have one day, but once you think you’re on the right track, there’s nothing better than actually trying to build something small to test your theory and discover new stuff.
Since the start of the year, the team working on the Digital Mortgage have focussed on just that.
First we were ruthless and identified the absolute bare minimum that we felt we could build and still produce something that worked – in our case, something that created an online mortgage and something that let someone else look at it. Nothing more than that to start with and definitely the first versions of both, not the finished article.
You may already know that agile teams work in short, focused “sprints” and in Land Registry we tend to run each sprint for two weeks. So with our focus firmly on putting something into a live environment as soon as we could, the team set to work. We weren’t coming from a complete standing start, the team had already done a lot of hard work exploring how a lot of the individual elements would work, but what really impressed me was that within two weeks we had something that we could deploy.
But there’s a lot more to putting something into a “production environment” than writing the software. You have to create that production environment for a start and design our network and security so that customers can reach it over the internet while keeping Land Registry’s computer systems safe. All that work took a little longer, but while we still only in our second sprint we were able to put what we’d built into live. Meanwhile, the team was already working on the next version of the service, with just a little bit more functionality, and we were ready to “upgrade” to that a few days later.
What’s most interesting to me is how the act of doing something – even if it’s only a small first step – uncovers stuff that you didn’t expect. When we went to do that first upgrade it didn’t go as smoothly as we expected… but by “doing” we were able to figure out how to make it easier next time around. And we found a bug which we’ve already fixed. All before any customer touches the service.
I’m really keen that we practice this process of making small improvements and putting them live as soon as we can. Do it again and again until it becomes second nature for the team. That way, as we continue working with customers who trial the service early on, we’ll be able to keep improving it based on what they tell us. And that thinking should remain even when the service becomes “live” for any customer to use. If we spot it can be better, we should make it better as soon as possible.