Tuesday 8 February 2011

On privacy and unprotected tweets

So, the PCC has ruled on the @Baskers case, the headline is 'Twitter messages are not private', and Twitter is full of insightful comments along the lines of 'Well, duh' and 'Who knew?'

But when everyone has finished feeling smug, they might like to consider what the real privacy issue is here.  This is not about whether a comment made in an open forum is considered publicly available - of course it is.  This is about whether there is a public interest in making it into a news story. In the case of @Baskers, there was no news, just tabloid bullying.  Hoorah, we are all equally exposed to being selectively quoted to bolster a paranoid and vindictive world view! It is sad that the industry regulator didn't or couldn't recognise this, and it will be even sadder if people kerb their freedom of expression in response to the random attacks of the redtops.

Wednesday 26 January 2011

My experience of using Agile methodologies in a non-tech project

Following UK Gov Camp 2011, there has been a lot of interesting discussion of the use of Agile methodologies for policy development in my Twitter feed and on public sector blogs, including these from Michele Ide-Smith and Curious Catherine. This has prompted me to reflect on my experience of using Agile methodologies to manage a non-technical project.

For anyone who is unfamiliar with Agile, it is an approach to software development - but don't let that put you off! I am not a techie, but working alongside techies allowed me to see the potential of this approach. As the name suggests, it's main characteristics are responsiveness and adaptability. It takes an incremental approach to product development which incorporates the review and refinement of your processes, and the demonstration of work in progress to your 'customer(s)', with a view to incorporating feedback, adapting requirements as necessary, and ensuring that the final product is as right as it can be.

In practical terms, I  found Henrik Kniberg's guide to making the most of Agile methodologies a useful starting point.

Why I decided to try using Agile:

The project I was working on was the development of guidance for the government sector on managing digital continuity (ie ensuring that you can access and use your digital information in the way that you need to, over time and through change).  This was one workstream within a wider project aiming to understand the problem of digital continuity, and provide a guidance, training, and tools to help the government sector manage it.  There were a number of reasons that this struck me as being well suited to Agile methodologies.

I had approached the first phase of guidance development using 'traditional' project management approach, and encountered a number of issues.  Despite having notional agreement from the wider team on our approach to drafting and reviewing the guidance, and the structure and broad content, I had trouble getting the input and engagement I needed.  The guidance was seen as my responsibility and was not a top priority for those whose expertise I needed, but who were focused on delivering other aspects of the project.  As a result, timescales slipped but without it being apparent that this would happen; much as I tested document structures and partial drafts on colleagues, at the end of the process the full draft didn't seem 'right' to them;  thinking on key issues moved on during the course of drafting etc. etc.

Reflecting on this, I felt the key things I needed to improve the situation were:

  • Stronger collective ownership of the guidance as an output of the project as a whole
  • Better understanding of what was stopping people contributing, with a view to overcoming those issues
  • Flexibility in the guidance development process, so that we could incorporate new ideas and changes of focus as we went along, rather than spend a long time producing something that had been superseded
  • More adaptability in terms of who did what, so that we could better accommodate the competing demands on peoples time
In addition to this, it was vitally important that we validated the guidance with those who would eventually have to use it, to ensure that the form and content suited their needs.


How using Agile worked out:

Overall, the switch to Agile worked extremely well for us.  Production 'sprints' of 4-6 weeks really  focused the team and helped us achieve more within tight timescales (despite initial scepticism in some quarters that flexibility = disregard of deadlines).  The effort we put in up front into identifying packages of work ensured much better understanding and agreement to what our guidance 'products' should look like, the amount of work likely to be involved, and our priorities overall. The visibility of tasks and tracking, and regularity of stand up meetings increased individual accountability and the sense of collective ownership of output and issues, which in turn led to better problem solving and people focusing their effort where it was most needed.

Inevitably, there was a settling in period while we worked out how to make Agile work best for us.  An the Agile approach didn't solve the issue of competing demands on the time people could devote to guidance, but it made it clear where the problems were and adjust resourcing or expectations accordingly.  It also allowed the team to see and accept where the guidance had to become a priority and deadlines had to be set.

In fact, the team adopted of Agile-inspired management for the project as a whole.