My name is Kirsty Elderton and I am a Prince2 accredited practitioner. There, I’ve said it.

I know Prince2 gets some bad press these days — often with good reason. However, whether you love or hate Prince2, it is also the methodology that the Public Sector and in particular Local Government have invested most heavily in.

Like it or not, if you are delivering in the public sector you are at best likely to rub up against some Prince2 legacy. At worst, a head-on collision with a full-on Prince2 programme office policing every aspect of the project.

At FutureGov, we have been working with a number of local authorities on a range of different projects, some light touch on project management and some requiring something a little more detailed. Within these projects, we have done our best to develop products and ideas in an Agile (with a capital ‘A’) way.

But there are tensions: Developers are committed to developing in an Agile way, but project managers often need something a little more “fixed” for clients.

We thought it would be useful to reflect on some of the lessons learned along the way and some of the behaviours required to create a successful managed and Agile project.

1. An Agile Attitude?

The one thing I know for sure is that there is no clear-cut definition of what an Agile Development Methodology is. Even within our own team we have different ideas and approaches for developing a product and running projects.

But there does seem to be a few characteristics that stand out as helpful:

• Know the problem you are trying to solve. As much as possible, keep that problem simple. Bigger problems can feel overwhelming so best to start with something small and then iterate and enhance regularly.
• Pay attention to the group or team process that sits around “Agile working”. By being intentional about this, we can use collective energy to come to new understandings and possibilities for the product. Valuing multiple perspectives is helpful and healthy, and means the development of the product sits squarely in the middle as everyone’s responsibility.
• A team with the ability to have difficult conversations, to debate dilemmas and that can name and frame issues (more on this later).
• To get good quality and regular feedback from users, listen to this feedback and base iterations on this.
• Pace is important. There should be a deliberate plan to pick up pace and build energy around one or two things. Equally important is to plan some thinking time or review time in between these “sprints”. It sounds kind of obvious but to use the sprint metaphor — you can’t sprint a marathon and most products and projects are more like a marathon than the 100m. Plan for the uptime and the downtime.

3. Frame the Problem Correctly

Another important aspect is to really attack the problem but to go easy on the person. This can be tricky if sometimes it feels like the people are the problem.

Always be clear on what the problem is you are trying to solve and this becomes much easier. Einstein once said: “If I had an hour to save the world I would spend 59 minutes defining the problem and one-minute finding solutions” Don’t waste time, debating and finding solutions to problems that don’t matter.

4. Agile Does Not Mean No Rigour

At FutureGov we want people to do their very best work and in turn, deliver the very best products and services for our customers. Rigour is an important aspect of this, rigour in planning, rigour in evaluating, rigour in testing, rigour in evidencing and on it goes. Agile should never be an excuse for lack of rigour.

That’s how I feel about Agile, coming from a Prince2 background. What are your thoughts? What has worked for you? Leave your comments below.

Originally published at https://blog.wearefuturegov.com on May 9, 2013.