lessons learnt from agile in local government

Lessons learnt from going Agile in local

governmentMichele Ide-Smith

BeforeO It took ages to get development

underwayO Stakeholders were impatient to see

resultsO Developers felt micro-managedO Lots of long, tedious meetingsO Projects dragged on, and on, and onO There was unfinished functionalityO Stakeholders didn’t get what they

expected

The waterfall model

AfterO Projects show results much more quicklyO Clear expectation of time and cost up

frontO Stakeholders are informed and involvedO Requirements can and do changeO Developers have more autonomyO Functionality gets finished and deployed

(mostly)

Scrum method

Example backlog

Example burndowns

Top lessons learnt

1. No silos – everyone must buy in to Agile

2. Estimation is still important3. Agile might not suit all dev projects4. Sprints need dedicated resource5. Don’t skimp on planning6. Build multi-disciplinary teams7. Nuture collaboration

1. No silosO Projects have dependenciesO Sprints require tight coordination of

resources and other workstreams (inputs/outputs)

O Get buy-in to using Agile methods across the organisation through early education

O Avoid unnecessary blockers!

2. Estimation is still important

O Developers break down user stories into tasks

O Estimation using complexity pointsO Developers must learn their velocity

(progress in each sprint)O Or their burndown (backlog progress)

will resemble a flatline

3. Agile may not suit all dev projects

O Agile works well for mature productsO Can lead to quick progress and great

resultsO New projects with unknowns carry

more riskO Still possible to have an unfinished

product

4. Sprints need dedicated resource

O Scrum roles need dedicated resourceO Other work commitments are

blockers!O Product owners should attend daily

stand ups, planning and review meetings

5. Don’t skimp on planning

O Plan ahead of development SprintsO Sometimes called ‘Sprint Zero’O Set up environments for dev and

testingO Conduct user researchO Start design workO Technical feasibility

6. Build multi-disciplinary teams

O Think about the complete user journey

O How will software be implemented in a mature, working website?

O Include content writers, UX’ers and sys admins in the team

7. Nurture collaboration

O Avoid sending long emailsO Co-locate developers, product

owners, consultants, UX’ers and content writers

O Otherwise, use phone conferencing and virtual meetings

O Stick designs up on wall space or windows

BarriersO Cultural: silos, lack of management

buy-inO Lack of dedicated resource during

sprintsO Lack of dedicated meeting rooms for

daily stand-ups and other meetingsO Little or no wall space for

collaborating on and reviewing designs

Remember the 12th Agile principle

“At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.”

For more info:O My going Agile blog postO My barriers to Agile web design postO Agile manifesto and principlesO Scrum Alliance