Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

Lessons learnt from agile in local government

2 705 vues

Publié le

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

Publié dans : Technologie
  • Login to see the comments

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 />