Lessons learnt from agile in local government
Upcoming SlideShare
Loading in...5
×
 

Lessons learnt from agile in local government

on

  • 2,317 views

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.

Statistics

Views

Total Views
2,317
Views on SlideShare
2,111
Embed Views
206

Actions

Likes
3
Downloads
12
Comments
0

4 Embeds 206

http://www.ide-smith.co.uk 180
http://buzz.ukgovcamp.com 24
http://translate.googleusercontent.com 1
http://www.linkedin.com 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Lessons learnt from agile in local government Lessons learnt from agile in local government Presentation Transcript

  • Lessons learnt from going Agile in local government
    Michele Ide-Smith
  • 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
  • The waterfall model
  • 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)
  • Scrum method
  • Example backlog
  • Example burndowns
  • 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
  • 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!
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • Remember the 12th Agile principle
    “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.”
  • For more info:
    My going Agile blog post
    My barriers to Agile web design post
    Agile manifesto and principles
    Scrum Alliance