Your SlideShare is downloading. ×
0
Lessons learnt from going Agile in local government<br />Michele Ide-Smith<br />
Before<br />It took ages to get development underway<br />Stakeholders were impatient to see results<br />Developers felt ...
The waterfall model<br />
After<br />Projects show results much more quickly<br />Clear expectation of time and cost up front<br />Stakeholders are ...
Scrum method<br />
Example backlog<br />
Example burndowns<br />
Top lessons learnt<br />No silos – everyone must buy in to Agile<br />Estimation is still important<br />Agile might not s...
1. No silos<br />Projects have dependencies<br />Sprints require tight coordination of resources and other workstreams (in...
2. Estimation is still important<br />Developers break down user stories into tasks<br />Estimation using complexity point...
3. Agile may not suit all dev projects<br />Agile works well for mature products<br />Can lead to quick progress and great...
4. Sprints need dedicated resource<br />Scrum roles need dedicated resource<br />Other work commitments are blockers!<br /...
5. Don’t skimp on planning<br />Plan ahead of development Sprints<br />Sometimes called ‘Sprint Zero’<br />Set up environm...
6. Build multi-disciplinary teams<br />Think about the complete user journey<br />How will software be implemented in a ma...
7. Nurture collaboration<br />Avoid sending long emails<br />Co-locate developers, product owners, consultants, UX’ers and...
Barriers<br />Cultural: silos, lack of management buy-in<br />Lack of dedicated resource during sprints<br />Lack of dedic...
Remember the 12th Agile principle<br />“At regular intervals, the team reflects on how to become more effective, then tune...
For more info:<br />My going Agile blog post<br />My barriers to Agile web design post<br />Agile manifesto and principles...
Upcoming SlideShare
Loading in...5
×

Lessons learnt from agile in local government

2,009

Published on

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

Published in: Technology
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
2,009
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
15
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

Transcript of "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 />
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×