#ukgc11 session on Agile lessons learnt in local government
In advance of this year’s fantastic UKGovCamp (aka #ukgc11) I pitched a session idea on lessons learnt from using an Agile project management method to manage web development. My idea for the session arose after some interest in a blog post I wrote recently and the discussion on the UKGovCamp forum thread.
So on the day I came armed with my slides and stood in line to pitch my session. I was joined by Stefan Czerniawski and Catherine Howe, who pitched a second session to explore the potential for applying Agile principles to policy. This is an area I am very interested in, but as I have limited experience of working with policy makers I ended up taking more of a back seat in their session, to observe, absorb and blog some loose notes.
Thankfully Catherine has written up a brilliant blog post about the session. Which is a relief, as I was flagging a bit at that point and was finding it hard to stay mentally alert. I think I used up all my energy facilitating the first session and also felt a bit ropey from having stayed out too late the night before – my only regret about the whole day!
The session went far better than I could have hoped for. It was well attended and resulted in an open and fascinating discussion about the practicalities of implementing Agile methods and applying them effectively.
Photo by Paul Clarke
There was a real mix of participants. Some with loads of experience and some who knew very little about Agile, but were curious to find out more. In preparing for the session I hadn’t really considered that some of the participants wouldn’t be familiar with the Agile manifesto, terminology or methods like Scrum and the roles involved. So I did my best to explain the concept of Agile and the Scrum method in simple terms in limited time and some gaps in my own knowledge. But I realise that pitching the session at the right level, to address the varying experience and understanding of those in the room, was a challenge. I look forward to Julia’s notes on the session (as mentioned in her write up of the day) as a relative Agile newbie.
I explained that we have used the Scrum method in my organisation (a county council) for about 18 months for web development projects, with varying degrees of success. Here are the slides I presented in the session:
Notes and reflections from the session
The following notes are written up from memory, as I was too busy talking (as usual) to write down anything during the session. I haven’t attributed these insights to individuals (in case I do so incorrectly!), but they were a combined effort of the participants who attended.
It can be difficult to introduce Agile methods when senior managers are sceptical. I recommended starting small by applying an Agile method to development of a mature platform, rather than choosing a project with significant risks and unknowns.
Someone asked if you can do Agile covertly. And the consensus was – yes absolutely! Agile can fit within existing, more traditional project management processes quite neatly, e.g. within the ‘product delivery’ phase of Prince2. It was even suggested you could do Agile within the ‘implementation’ phase of a waterfall method and by the time you get to the ‘verification’ phase, you’ve already done the testing you need to. Business people don’t want to know how you are delivering something, just that you deliver results.
But…and there are two big buts…
- You do need the product owner involved. It can be very hard to persuade product owners to be involved in sprints and attend daily scrum meetings. Good planning ensures key individuals in the organisation are available when you need them to be.
- The scrum master has a key role to play in negotiating with product owners and other senior business stakeholders who insist on the delivery of particular features and refuse to compromise over the scope or prioritise their requirements.
When a development team learns their velocity over time, introducing someone new to the team can throw things off balance. Estimation poker can help the estimation process, because developers have to discuss and resolve why there are differences in their estimations.
Developers can sustain their pace when working in sprint cycles. Following a waterfall method can result in a huge rise in stress levels as you approach a big bang launch and everyone is working overtime to get a product finished. Instead there are small rises in stress levels at the end of a sprint, but developers should be able to leave work at 5 pm and maintain their pace in a sustainable way.
The velocity of the team (progress over a series of sprints) can be greatly improved by having a UX designer produce designs in advance of the sprints.
Agile involves developers in business strategy, so they work towards achieving business objectives.
Although the Agile principles promote face-to-face communication and co-location of teams is often cited as being important, it is possible to use geographically dispersed teams if you make good use of technology. An example was given of how a team which is distributed worldwide use Skype to manage daily scrums.
Not everything gets finished at the end of a sprint. Developers must be prepared to throw code away.
Be flexible about the method and techniques you use e.g. user stories could be written up on cards and stuck on the wall, kept in a spreadsheet or a specialist application.
Agile can be applied outside IT contexts. One participant said that his organisation has applied Agile principles to business strategy projects.
I’d like to extend my thanks to Dan Hardiker, Andrew Woodward, Catherine Howe and Sharon O’Dea who all pitched in with excellent insights based on their experiences of working in an Agile context. I personally learnt loads from the other participants.
Which goes to show if you’re willing to share your own experiences, you get back a bucketful of new insights and knowledge from others in the process!
This content is published under the Attribution-Noncommercial-Share Alike 3.0 Unported license.