There’s been a flurry of conversation on Twitter in the last few days about the potential for the use of agile methods in the public sector. As a result @pubstrat created the hashtag #pubsecagile and started a thread on the UK GovCamp 2011 site.
I wrote a post back in November 2009 about some of the potential barriers to introducing agile methods to manage web development projects in a local government context. In the local authority I work for we’ve been using Scrum to manage web development projects and we’ve learnt some useful lessons, which I’ll discuss later on in this post.
In recent months quite a few public sector bloggers including @brianhoadley, @curiousc, @pubstrat, @publicsectorpm and @loulouk have written about agile methods. Some have touched on using agile principles and methods in different contexts (i.e. to software development) within the public sector. Some of the posts mentioned here suggest applying agile concepts within the public sector in non-IT contexts.
Agile methods such as Scrum, DSDM or XP were originally designed for managing software development projects. I won’t go back over this as I described the differences between the more traditional waterfall methods and agile methods in my previous post. Much of what has been written about agile methods (in books and online) also relates to software development.
The use of Lean methods has also been picking up pace in the public sector in recent years. Lean is a technique developed by Toyota to reduce wastage in their manufacturing processes. Lean has now been adapted for use in the public sector and is ideal for transforming public services to improve productivity and efficiency and achieve the holy grail of doing more with less.
Agile is known as a being a mindset or philosophy rather than a method itself. Looking at the Agile Manifesto it is quite possible to see how the concepts can be used in different contexts to software development. I’ve re-produced the manifesto below and simply changed the word ‘software’ to ‘systems’ (by ‘system’ I am referring to socio-technical systems that comprise people, processes and technology or non-technical systems i.e. just people and processes).
Individuals and interactions over processes and tools
Working systems over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
While researching this post I found a great presentation by David Anderson which he gave at the Agile 2008 conference. David spoke about the potential for using agile concepts in non-IT fields like marketing, design and recruiting. It seems from David’s presentation that even within the agile community the idea of using agile methods outside of IT software development projects was relatively innovative back in 2008.
More recently, the Agile Business Conference in October 2010 (organised by the DSDM consortium) focused on the naked truth of how agile methods are being used in non-IT environments and included a public sector track with an NHS case study. I would be really keen to see how those interested in the #pubsecagile Twitter conversations can tap into existing agile for business networks where conversations are already taking place. Interestingly the DSDM community members government list is distinctly lacking representatives from local and central government organisations.
But my feeling is a more open discussion is needed which as far as possible is agnostic of any particular agile methods. So bring on UK GovCamp 2011!
Where possible I am also trying to follow some interesting and innovative discussions in the agile UX community, for example the Agile UX Retreat.
So onto the second part of this post…
My lessons learnt from going Agile in local gov
1 – Agile doesn’t work in an IT silo for service re-design projects
If you’re going to use an agile method make sure any team members responsible for delivering interdependent parts of a service redesign project delivery and senior managers are on board. You can’t expect other stakeholders to fit into your time boxes when you need them to, or to understand what you are doing. You must clearly outline the benefits of your approach up front and get their explicit buy in. If you don’t have all dependent parts of the project using an agile method you’ll run into blockers (issues) which you just can’t shift, which will impact on your burndown (progress in completing tasks on the sprint backlog) and ultimately the velocity (amount completed from the product backlog in each sprint).
2 – Going agile isn’t necessarily a cure for issues with estimation
One of the drawbacks of the traditional waterfall method is the potential that you can spend far longer than anticipated developing software because the scope is unwieldy and it can be hard to estimate in terms of time and cost. Worse still you might end up with an unfinished product and can’t accommodate changing requirements.
Going agile can provide more certainty and flexibility, but requires the team to estimate user stories from the backlog using complexity points, and then to break them down into tasks and re-estimate. Estimating the backlog should give you an indication of whether you’ll get a working feature or application within the time / budget you have available. The last thing you want is a situation where your burndown chart resembles a flatline on a life support system, because the estimates were inaccurate. The only way a Scrum team can really improve estimation is to keep reviewing their velocity in previous sprints. Which leads to the next lesson learnt…
3 – Agile may not work for all your development projects
If you have a mature application or website, you’ll probably find using agile methods a fantastic way to manage changes on a budget. You have control over the time and cost, but you can prioritise your user stories to ensure that only the changes which bring the most value to your users and the business are implemented.
Using agile methods for the development of new products or services carries more risk. In this situation you are more likely to have unknowns, particularly if you don’t already have a prototype or proof of concept. In this situation there is a danger you could still end up with a half-finished product when using agile methods.
4 – Make sure you have dedicated resources in the project team
If you are going the agile route, make sure you have dedicated teams that can fulfill the necessary roles of product owner, scrum master and those managing the product delivery (e.g. developers, user experience designers, content specialists). Don’t expect your project teams to manage lots of other committments during the sprint as they probably won’t have time. Product owners should be able to attend daily stand ups (in person or virtually) and spend time collaborating with the rest of the project team in planning and review meetings.
5 – Ensure you have multi-disciplinary project teams
I don’t believe that you can effectively use agile methods like Scrum for web development projects unless your project delivery team includes all those involved in creating the finished product. Which for web projects includes content specialists and user experience designers, not just developers. You need to consider how software features will be implemented within an existing website and how users will experience the complete product as part of a user journey.
Most importantly, remember the 12th agile principle!
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
So what about those barriers I identified? Well here’s a quick run down of which of my predictions became actual barriers.
- Co-location – In one project co-location did crop up as an issue, but we quickly solved it by getting the product owner to co-locate with the developers on regular occasions throughout the sprint.
- Meeting room facilities – a meeting room was booked each day at the same time for the daily stand up meetings.
- Culture – we definitely faced cultural issues and lack of acceptance of the Scrum method more widely in the organisation (see lesson 1 above). I put this down to our lack of experience of introducing agile methods and poor communication. But it’s not an insurmountable barrier. Whenever you are introducing any major change to an organisation you need to plan and be flexible, empathetic, patient, cooperative, determined and a persuasive communicator.
- Availability – it was hard to get colleagues in other services and external suppliers to be available when we needed them to be – again this relates to lesson 1 above.
- Fit with Prince2 – the SCRUM process fitted nicely into the ‘managing product delivery’ part of the Prince2 project lifecycle. Where possible the web project manager did not take on any of the team roles (such as being scrum master) but did attend daily Scrums as a ‘chicken‘ to keep in touch. Which meant they were able to continue managing risks and issues and planning ahead for other activities in the project.
- Lack of wall space for collaborating on UX deliverables – it may sound trivial but this continues to be a real problem for our team. But thankfully we are soon moving to an office with a big stretch of empty wall space, which is a huge relief