Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Lessons learnt from agile in local government


Published on

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

Published in: Technology

Lessons learnt from agile in local government

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