Your SlideShare is downloading. ×

Lessons learnt from agile in local government


Published on

Presentation from UKGovCamp 2011 #ukgc11 about lessons learnt from going Agile in local government.

Presentation from UKGovCamp 2011 #ukgc11 about lessons learnt from going Agile in local government.

Published in: Technology
  • Be the first to comment

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 1. Lessons learnt from going Agile in local government
    Michele Ide-Smith
  • 2. Before
    It took ages to get development underway
    Stakeholders were impatient to see results
    Developers felt micro-managed
    Lots of long, tedious meetings
    Projects dragged on, and on, and on
    There was unfinished functionality
    Stakeholders didn’t get what they expected
  • 3. The waterfall model
  • 4. After
    Projects show results much more quickly
    Clear expectation of time and cost up front
    Stakeholders are informed and involved
    Requirements can and do change
    Developers have more autonomy
    Functionality gets finished and deployed (mostly)
  • 5.
  • 6. Scrum method
  • 7. Example backlog
  • 8. Example burndowns
  • 9. Top lessons learnt
    No silos – everyone must buy in to Agile
    Estimation is still important
    Agile might not suit all dev projects
    Sprints need dedicated resource
    Don’t skimp on planning
    Build multi-disciplinary teams
    Nuture collaboration
  • 10. 1. No silos
    Projects have dependencies
    Sprints require tight coordination of resources and other workstreams (inputs/outputs)
    Get buy-in to using Agile methods across the organisation through early education
    Avoid unnecessary blockers!
  • 11. 2. Estimation is still important
    Developers break down user stories into tasks
    Estimation using complexity points
    Developers must learn their velocity (progress in each sprint)
    Or their burndown (backlog progress) will resemble a flatline
  • 12. 3. Agile may not suit all dev projects
    Agile works well for mature products
    Can lead to quick progress and great results
    New projects with unknowns carry more risk
    Still possible to have an unfinished product
  • 13. 4. Sprints need dedicated resource
    Scrum roles need dedicated resource
    Other work commitments are blockers!
    Product owners should attend daily stand ups, planning and review meetings
  • 14. 5. Don’t skimp on planning
    Plan ahead of development Sprints
    Sometimes called ‘Sprint Zero’
    Set up environments for dev and testing
    Conduct user research
    Start design work
    Technical feasibility
  • 15. 6. Build multi-disciplinary teams
    Think about the complete user journey
    How will software be implemented in a mature, working website?
    Include content writers, UX’ers and sys admins in the team
  • 16. 7. Nurture collaboration
    Avoid sending long emails
    Co-locate developers, product owners, consultants, UX’ers and content writers
    Otherwise, use phone conferencing and virtual meetings
    Stick designs up on wall spaceor windows
  • 17. Barriers
    Cultural: silos, lack of management buy-in
    Lack of dedicated resource during sprints
    Lack of dedicated meeting rooms for daily stand-ups and other meetings
    Little or no wall space for collaborating on and reviewing designs
  • 18. Remember the 12th Agile principle
    “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.”
  • 19. For more info:
    My going Agile blog post
    My barriers to Agile web design post
    Agile manifesto and principles
    Scrum Alliance