Going agile

ByMichele Ide-Smith

Going agile

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 🙂

This content is published under the Attribution-Noncommercial-Share Alike 3.0 Unported license.


About the author

Michele Ide-Smith administrator

5 Comments so far

John GoodePosted on12:13 pm - Jan 2, 2011

A cool post! We introduced Agile SCRUM in the last company I worked for (Immediacy). Sadly it’s being ripped out now by *non-believers* and anyway, the product is being retired…long story, ‘nother time.

Absolutely vital is to know your team(s) velocity. And this is a good question to ask any Services company touting their *Agile* development capabilities.

To many, agile means cut the paper-work, cut-code straight-away. Eeek!

However, how does an Agile supplier get past *procurement*, get through contract negotiations — which have only ever become more rigorous lately — to the point of being able to deliver a great service?

The point is clients want a fixed set of features for a fixed price. They like the idea of variability in the course of software development (responding to change) but are forced to frightened into old-fashioned change control processes along with contract re-negotiations.

Perhaps it is an education process? One that starts from the inside with internal developments teams. A process that educates organisations that:

1. software development is complex. It’s difficult to specify/document and difficult for people to not change their minds about what they want during development.
2. they are not best suited by inflexible contracts.
3. pseudo Agile companies can be spotted from 100 paces.

Michele Ide-SmithPosted on2:30 pm - Jan 2, 2011

Thanks for your comment John. I think any process including procurement will need to be modified to suit more Agile methods of solution delivery. There is a comment by Paul Freeman on an older post I did which mentions changes to processes (http://www.ide-smith.co.uk/?p=375).

However, when defining a specification as part of a tender process, there is no reason why you can’t specify user stories rather than having a supposedly water tight specification of what the solution should be. In my experience of waterfall it doesn’t matter how detailed the specification is, as soon as you start investigating potential solutions and suppliers you change your requirements specification to adapt.

I think you’ve hit the nail on the head. It is all about education. And being Agile also means accepting that failure is part of the learning and improvement process. And if public sector organisations don’t get more comfortable with iterative approaches to delivering services, they will never learn, adapt and improve fast enough to keep pace with the fast changing world we live in.

Good luck in future Agile ventures! It’s definitely not easy as ultimately you will always come across people who are not willing to accept and manage the risks associated with any large-scale software development. And Agile methods are an easy target because everything about being Agile seems from the outside to be so fluid and undefined.

Tweets that mention   Going agile by Michele Ide-Smith — Topsy.comPosted on8:44 pm - Jan 2, 2011

[…] This post was mentioned on Twitter by Dominic Campbell, John Moore, Paul Clarke, Carl Haggerty, LouLouK and others. LouLouK said: I missed this yesterday: A simply brilliant explanation/lessons learnt of agile in local gov from @micheleidesmith http://bit.ly/e89uLe […]

William Wardlaw RogersPosted on10:49 am - May 12, 2011

This is great stuff.. My friend is running Lean Start Up meet ups in London at the moment. Be interesting to get people from the micro-org world looking at some of the larger systemic challenges through that framework.

Not sure how to share e-mail with you on here but my full name on FB will get a message to me. And I believe we swapped messages in ’08 around realtime consultation.. but can’t seem to surface your contact.

AndreaPosted on9:38 am - Jun 14, 2011

I am currently researching the use of agile methodology in non-IT projects in health services, do you know of any good examples or people to contact about this?

Leave a Reply