Your SlideShare is downloading. ×
0
Lessons learnt from agile in local government
Lessons learnt from agile in local government
Lessons learnt from agile in local government
Lessons learnt from agile in local government
Lessons learnt from agile in local government
Lessons learnt from agile in local government
Lessons learnt from agile in local government
Lessons learnt from agile in local government
Lessons learnt from agile in local government
Lessons learnt from agile in local government
Lessons learnt from agile in local government
Lessons learnt from agile in local government
Lessons learnt from agile in local government
Lessons learnt from agile in local government
Lessons learnt from agile in local government
Lessons learnt from agile in local government
Lessons learnt from agile in local government
Lessons learnt from agile in local government
Lessons learnt from agile in local government
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Lessons learnt from agile in local government

2,005

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
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

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

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  1. Lessons learnt from going Agile in local government<br />Michele Ide-Smith<br />
  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. The waterfall model<br />
  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. Scrum method<br />
  6. Example backlog<br />
  7. Example burndowns<br />
  8. 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 />
  9. 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 />
  10. 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 />
  11. 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 />
  12. 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 />
  13. 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 />
  14. 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 />
  15. 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 />
  16. 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 />
  17. 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 />
  18. 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 />

×