Lessons learned the hard way on our journey building digital products.

1. Practical agile.
Ian Ames
@IanAmes
https://medium.com/@IanAmes
Lessons learned the hard way on our
journey building digital products.

2. Wakey Wakey!
With the person sat behind you,
you have 2 minutes to discuss:
• Most surprising thing you have
learnt?
• Most useful thing you will take
away?

3. Objective
• Share real world
experiences
• Promote discussion
• Learn!

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.

6. A new Agile adoption
scale!

7. Mary Poppins agile business scale
AgileTraditional
Land Registry

8. How we used to build
products and services

10. How we build services
now

11. User needs first
Service Design
Microservices
Continuous Delivery

12. Start with user needs

13. Credit: Martin Eriksson

15. User Research
• User Researchers in the team.
• Every Sprint.
• Team actively encouraged to
go.
• Research using prototyping
and the live service.
• Includes assisted digital users.

16. Benefits
• 5 participants can identify 80%
usability problems.
• Team gain greater
understanding of what works
and what doesn't in the
service.
• Service ultimately end up
clearer and easier to use.
• Happy users!

17. Top tips!
• Be aware of Stakeholders/user
need conflict.
• Watch out for morale in the
team.
• Dont forget you are domain
experts!
• Test the whole service, not just
the website or app.

18. Service Design

19. Government Service Design Manual
Credit: John Waterworth

20. Service Design Helix
Credit: Matt Edgar

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
fungible.
• Not everyone wants to work in these
teams!
• Not all of these roles are best filled
by IT people.
• Open plan offices are terrible team
spaces!
• Avoid sharing key resources
between teams.

23. Benefits

24. Servant Leadership
• Remove barriers from the
team progressing.
• Coach and mentor
• Emotive listener
• Ego-less
• Knows when to solve
problems and when to push
for self resolution.
• Hard!

25. Ceremonies
• Daily stand ups
• Planning and refinement
• Show and Tell
• Retrospective
Credit: Her Majesty

26. Top tips!
• Report progress in terms that
business stakeholders care
about (value).
• 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).

27. Microservices

29. Credit: Paul Downey

30. Benefits
• Decoupled, easier to change.
• Decoupled, better fault
tolerance.
• Horizontal scaling.
• API based, easy to re-use over
the internet.
• Technology agnostic, you can
pick th technology best for the
service.

31. Challenges
• 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
systems.
• 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
some!)
• Identify features needed for
the service versus enterprise
needs.
• Keep an eye on the size of
your micro services.
• Ensure clear ‘contract’s’
between services.

35. Continuous Delivery
(Well nearly)

36. How we used to deploy

37. How we deploy now.

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.

41. Benefits
• Smaller change = less risk
• Easier to deliver fixes quicker.
• Develop and Master code
stays closer together reducing
merge conflicts.
• 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…

43. Credit: John Allspaw & Paul Hammond.

44. Credit: John Allspaw & Paul Hammond.

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…

47. Stuff we haven't figured out
yet.
Credit: Dan North, Richard Durnall

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!

49. Thank You
Ian Ames
@IanAmes
https://medium.com/@IanAmes

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.
http://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-
cooperation-at-flickr
• Continuous Delivery - Jez Humble. https://continuousdelivery.com/
• Spotify Engineering Culture - Henrik Kniberg -
https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/
• Kanban and Scrum, making the most of both - Henrik Kniberg.
https://www.infoq.com/minibooks/kanban-scrum-minibook