Download to read offline
Uploaded byIan Ames
Practical agile TechExeter
- Land Registry registers land ownership in England and Wales and has transitioned from a traditional to a more agile way of building products and services. - They now take a user-centered approach with user research in each sprint, focus on service design with multi-disciplinary teams, build using microservices and continuous delivery to deploy updates. - The transition has been challenging and requires clear objectives, executive support, breaking down silos, and ongoing communication but provides benefits like more adaptable and user-focused services.
Practical agile TechExeter
- 1. Practical agile. Ian Ames @IanAmes https://medium.com/@IanAmes Lessonslearned the hard way on our journey building digital products.
- 2. Wakey Wakey! With theperson 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 realworld 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 Agileadoption scale!
- 7. Mary Poppins agilebusiness scale AgileTraditional Land Registry
- 8. How we usedto build products and services
- 10. How we buildservices now
- 11. User needs first ServiceDesign Microservices Continuous Delivery
- 12. Start with userneeds
- 13.
- 15. User Research • UserResearchers in the team. • Every Sprint. • Team actively encouraged to go. • Research using prototyping and the live service. • Includes assisted digital users.
- 16. Benefits • 5 participantscan 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! • Beaware 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.
- 19. Government Service DesignManual 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! • Tailorteam 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.
- 24. Servant Leadership • Removebarriers 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 standups • Planning and refinement • Show and Tell • Retrospective Credit: Her Majesty
- 26. Top tips! • Reportprogress 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.
- 29.
- 30. Benefits • Decoupled, easierto 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 isfirst 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. • Teambuild 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! • Tryto 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.
- 36. How we usedto deploy
- 37. How we deploynow.
- 38. Our approach toDevops • We have a separate webops team for deploys to prod and pre-prod. • One place to go.
- 40. Our approach toDevops • 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! • Makesure 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'tfigured out yet. Credit: Dan North, Richard Durnall
- 48. In summary • agiletransformation 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.
- 50. Useful Resources • GovernmentService 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