4. About Land Registry.
• We register land ownership in England and Wales.
• We safeguard land and property ownership, worth
more than £4 trillion.
• We have 24 million ‘titles’ of land ownership.
• 83% of England and Wales is registered.
5. About Land Registry.
• Founded in 1862.
• Employ ~4500 people at 14 offices.
• In house IT based in Plymouth ~400 staff.
• Gov Dept, running costs covered by the fees paid
by users of our service.
15. User Research
• User Researchers in the team.
• Every Sprint.
• Team actively encouraged to
• Research using prototyping
and the live service.
• Includes assisted digital users.
• 5 participants can identify 80%
• Team gain greater
understanding of what works
and what doesn't in the
• Service ultimately end up
clearer and easier to use.
• Happy users!
17. Top tips!
• Be aware of Stakeholders/user
• Watch out for morale in the
• Dont forget you are domain
• Test the whole service, not just
the website or app.
21. Team make up
• Not just dev and test.
• service manager, product manager, delivery
manager, technical architect, assisted digital lead,
designer, user researcher, developer, content
designer, web operations engineer, performance
analyst, front-end developer
• T-shaping is necessary to avoid massive teams.
22. Top tips!
• Tailor team processes to account for
research and design.
• Avoid team churn, knowledge is not
• Not everyone wants to work in these
• Not all of these roles are best filled
by IT people.
• Open plan offices are terrible team
• Avoid sharing key resources
26. Top tips!
• Report progress in terms that
business stakeholders care
• Don’t become Scrum Zombies.
• Inspect and adapt is VITAL!
• Don’t commit to delivery dates
before knowing velocity.
• Be alert to ‘elastic band’ effect.
• Good coaches help (but they
are very rare).
• Decoupled, easier to change.
• Decoupled, better fault
• Horizontal scaling.
• API based, easy to re-use over
• Technology agnostic, you can
pick th technology best for the
• Team is first so has to build all the new api’s.
• Team gets all the pain of building new things.
• Team slows down to build features not required by service.
• Team slows down further integrating back to legacy
• Stakeholders dont see complexity so question progress
• Team slowly loses will to live.
33. Different approach.
• Team build api, but only for the features required by
the service they are developing.
• Follow up team requiring more features develops
those features on the api.
• Risk, who ‘owns’ the api (support).
34. Top tips!
• Try to identify all of the
services you will need up front
(but you will probably miss
• Identify features needed for
the service versus enterprise
• Keep an eye on the size of
your micro services.
• Ensure clear ‘contract’s’
38. Our approach to Devops
• We have a separate webops team for deploys to
prod and pre-prod.
• One place to go.
40. Our approach to Devops
• Team dedicated to hosting automation and platform
management so devs have less to figure out.
• Not perfect but a good balance.
• Smaller change = less risk
• Easier to deliver fixes quicker.
• Develop and Master code
stays closer together reducing
• Responsibility for deploy and
support means teams think
more about supportability.
42. Top tips!
• Make sure your product owner is willing to balance fixes
versus new features.
• Plan for how to handle sprint commitments when deploying
to prod during sprints.
• Log all changes in one place!
• Keep front line support staff updated with changes.
• Keep examining your branching strategy.
• And finally…
45. More top tips!
• Make prod deploy your definition
of done from the outset!
• Put the work in clearing approvals
in your definition of ready.
• Expect resistance!
• Invest the time in good
acceptance criteria (TDD).
• Automate as much as possible.
• Automate some more!
• Prepare for things to go wrong…
48. In summary
• agile transformation is hard, its a long term investment.
• agile transformation is a means to an end, not the product or
service (this makes funding a challenge).
• Silo’s everywhere!!
• Communication and a thick skin is key!
• Clear objectives and support from the top.
• Don’t lose sight on why you are transforming!
• Talk to your peers in industry!
50. Useful Resources
• Government Service Design Manual. https://www.gov.uk/service-manual
• Dont make me think - Steve Krug. https://www.sensible.com/dmmt.html
• 12 factor app. https://12factor.net/
• 10 deploys a day at Flickr - John Allspaw, Paul Hammond.
• Continuous Delivery - Jez Humble. https://continuousdelivery.com/
• Spotify Engineering Culture - Henrik Kniberg -
• Kanban and Scrum, making the most of both - Henrik Kniberg.