Successfully reported this slideshow.
Your SlideShare is downloading. ×

Practical agile TechExeter

Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Loading in …3
×

Check these out next

1 of 50 Ad
Advertisement

More Related Content

Similar to Practical agile TechExeter (20)

Advertisement

Recently uploaded (20)

Practical agile TechExeter

  1. 1. Practical agile. Ian Ames @IanAmes https://medium.com/@IanAmes Lessons learned the hard way on our journey building digital products.
  2. 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. 3. Objective • Share real world experiences • Promote discussion • Learn!
  4. 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. 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. 6. A new Agile adoption scale!
  7. 7. Mary Poppins agile business scale AgileTraditional Land Registry
  8. 8. How we used to build products and services
  9. 9. How we build services now
  10. 10. User needs first Service Design Microservices Continuous Delivery
  11. 11. Start with user needs
  12. 12. Credit: Martin Eriksson
  13. 13. 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.
  14. 14. 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!
  15. 15. 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.
  16. 16. Service Design
  17. 17. Government Service Design Manual Credit: John Waterworth
  18. 18. Service Design Helix Credit: Matt Edgar
  19. 19. 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.
  20. 20. 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.
  21. 21. Benefits
  22. 22. 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!
  23. 23. Ceremonies • Daily stand ups • Planning and refinement • Show and Tell • Retrospective Credit: Her Majesty
  24. 24. 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).
  25. 25. Microservices
  26. 26. Credit: Paul Downey
  27. 27. 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.
  28. 28. 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.
  29. 29. 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).
  30. 30. 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.
  31. 31. Continuous Delivery (Well nearly)
  32. 32. How we used to deploy
  33. 33. How we deploy now.
  34. 34. Our approach to Devops • We have a separate webops team for deploys to prod and pre-prod. • One place to go.
  35. 35. 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.
  36. 36. 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.
  37. 37. 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…
  38. 38. Credit: John Allspaw & Paul Hammond.
  39. 39. Credit: John Allspaw & Paul Hammond.
  40. 40. 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…
  41. 41. Stuff we haven't figured out yet. Credit: Dan North, Richard Durnall
  42. 42. 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!
  43. 43. Thank You Ian Ames @IanAmes https://medium.com/@IanAmes
  44. 44. 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

×