practical agile. lessons learned the hard way on our journey building digital products

Practical agile.

Ian Ames

@IanAmeshttps://medium.com/@IanAmes

Lessons learned the hard way on our journey building digital

products.

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?

Objective

• Share real world experiences

• Promote discussion

• Learn!

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.

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.

A new Agile adoption scale!

Mary Poppins agile business scale

AgileTraditionalLand Registry

How we used to build products and

services

How we build services now

User needs first

Service Design

Microservices

Continuous Delivery

Start with user needs

Credit: Martin Eriksson

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.

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!

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.

Service Design

Government Service Design Manual

Credit: John Waterworth

Service Design Helix

Credit: Matt Edgar

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.

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.

Benefits

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!

Ceremonies

• Daily stand ups

• Planning and refinement

• Show and Tell

• Retrospective

Credit: Her Majesty

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).

Microservices

Credit: Paul Downey

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.

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.

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).

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.

Continuous Delivery(Well nearly)

How we used to deploy

How we deploy now.

Our approach to Devops

• We have a separate webops team for deploys to prod and pre-prod.

• One place to go.

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.

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.

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…

Credit: John Allspaw & Paul Hammond.

Credit: John Allspaw & Paul Hammond.

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…

Stuff we haven't figured out yet.

Credit: Dan North, Richard Durnall

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!

Thank You

Ian Ames

@IanAmeshttps://medium.com/@IanAmes

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