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

1. Lessons learnt from going Agile in local government Michele Ide-Smith

2. 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

3. The waterfall model

4. 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)

6. Scrum method

7. Example backlog

8. Example burndowns

9. 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

10. 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!

11. 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

12. 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

13. 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

14. 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

15. 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

16. 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

17. 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

18. Remember the 12th Agile principle “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.”

19. For more info: My going Agile blog post My barriers to Agile web design post Agile manifesto and principles Scrum Alliance