This document discusses lessons learned from adopting an Agile approach to development projects in local government. It describes some common challenges with traditional waterfall models like long development times and unfinished functionality. The document then outlines benefits of Agile like faster results, adaptive requirements, and deployed functionality. It provides examples of tools like backlogs and burndowns used in Scrum methodology. Finally, it lists the top lessons learned which include breaking down silos, continuing estimation practices, assessing project fit, dedicating resources to sprints, thorough planning, and cross-functional teams.

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

2. BeforeIt took ages to get development underwayStakeholders were impatient to see resultsDevelopers felt micro-managedLots of long, tedious meetingsProjects dragged on, and on, and onThere was unfinished functionalityStakeholders didn’t get what they expected

3. The waterfall model

4. AfterProjects show results much more quicklyClear expectation of time and cost up frontStakeholders are informed and involvedRequirements can and do changeDevelopers have more autonomyFunctionality gets finished and deployed (mostly)

6. Scrum method

7. Example backlog

8. Example burndowns

9. Top lessons learntNo silos – everyone must buy in to AgileEstimation is still importantAgile might not suit all dev projectsSprints need dedicated resourceDon’t skimp on planningBuild multi-disciplinary teamsNuture collaboration

10. 1. No silosProjects have dependenciesSprints require tight coordination of resources and other workstreams (inputs/outputs)Get buy-in to using Agile methods across the organisation through early educationAvoid unnecessary blockers!

11. 2. Estimation is still importantDevelopers break down user stories into tasksEstimation using complexity pointsDevelopers 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 projectsAgile works well for mature productsCan lead to quick progress and great resultsNew projects with unknowns carry more riskStill possible to have an unfinished product

13. 4. Sprints need dedicated resourceScrum roles need dedicated resourceOther work commitments are blockers!Product owners should attend daily stand ups, planning and review meetings

14. 5. Don’t skimp on planningPlan ahead of development SprintsSometimes called ‘Sprint Zero’Set up environments for dev and testingConduct user researchStart design workTechnical feasibility

15. 6. Build multi-disciplinary teamsThink about the complete user journeyHow will software be implemented in a mature, working website?Include content writers, UX’ers and sys admins in the team

16. 7. Nurture collaborationAvoid sending long emailsCo-locate developers, product owners, consultants, UX’ers and content writersOtherwise, use phone conferencing and virtual meetings Stick designs up on wall spaceor windows

17. BarriersCultural: silos, lack of management buy-inLack of dedicated resource during sprintsLack of dedicated meeting rooms for daily stand-ups and other meetingsLittle 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 postMy barriers to Agile web design postAgile manifesto and principlesScrum Alliance