Tuesday, 8 September 2015
Imogen Levy, Delivery Manager explains what being Agile means, what it’s good for and how we at City Hall have been using Agile methodology for the new website project.
Agile methodology, simply put, is a bit-by-bit approach to getting stuff done. You build stuff gradually from the start of the project, instead of delivering it all at once near the end (the Waterfall approach). The difference between a more traditional Waterfall approach and Agile is that Waterfall needs you to have clearly defined requirements at the beginning. It's a sequential process. Whereas Agile is flexible and highly collaborative and your requirements are expected to evolve and change.
It provides good common-sense principles for getting stuff done.
The Agile manifesto says:
- We value: Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
In the web team we have been using agile project management technique for the new website project which is now in its beta phase (please go check it out!)
As delivery manager (AKA project manager, scrum master) it is my job to make sure the project team are able to do what they need to do to get the job done and remove any obstacles that might be getting in the way. According to the Government Digital Service (GDS), ‘They enable the work a team does rather than impose how it’s done. It’s not about micro managing!’
A typical Agile project will also have the following additional roles:
- Product owner - typically a project's key stakeholder. This person needs to have a vision for what is being built
- Business analyst - the link between the business and the developers of a product, helping to discover the user needs and the solutions to addressing them
- Stakeholder - anyone who is potentially affected by the development of a software project
- Agile team members - consisting primarily of developers and testers, but may include other roles such as technical lead, system architect, technical writer, user researcher and designer
For the beta.london.gov.uk project we work in three-weekly ‘sprints’ - which basically means a time-boxed bit of development work (sprints are usually between one to three weeks, depending on the project). We have a daily stand-up meeting where project progress is discussed and any issues raised. The key to the success of this meeting is to keep it short and sprint focused.
We have regular sprint planning meetings and try to be at least one sprint ahead in terms of planning. At the end of each sprint, we have a retrospective which is a meeting where the entire project team reflect on what went well, and not so well during the sprint. The outcome is a list of actions to help the project run more efficiently. In the first week of each sprint, we also host a 'show and tell' with City Hall staff to demo the latest features completed in the previous sprint. We wrote a bit about 'show and tells' in a previous blog post if you'd like to know more.
What's more, some aspects of Agile methodology have been absorbed into other areas of the organisation.
Graham Lane, Manager of Business and Development, Technology Group (TG) says “Some of the Agile techniques, such as daily stand-ups, are really useful in areas beyond purely project work. Our Service Desk and Business Teams both have brief, daily stand-ups. They help all of the team stay up to speed about what is happening each day.”
According to Shruti Morjaria, Technical Delivery Manager, Technology Group. “Agile allows for change with the understanding that something else in the plan should give way for that change. This helps TG because inevitably, there will be changes and Agile allows us to be able to manage that within the current sprint. But it also protects the supplier by ensuring they aren’t being overloaded with more work than they initially planned to do.”
“Daily standups give the whole project team a quick insight into what happened the day before and what's planned today. It gets things moving by getting the right people talking to each other. Most importantly, it flags up problems which need to be resolved before the project can move on”.
“Retrospectives are useful because they identify the project team’s view of what went well and what could have gone better. The lessons learnt from these are then used to improve the way we work for the next sprint. Constantly learning from our mistakes allows us to continually improve our processes. It is also a way of recognising good work which has its own motivational benefits. ”
To find out more about agile project specifics GOV.UK have excellent resources in their Government Service Design Manual.