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.

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.

#iambaskers

I am dedicating this inaugural post to @Baskers.  This time last year, I would not have felt able to speak as freely on the subject of the baseless pillorying she has received from certain 'journalists' as I have been doing over the last week.  Now I am no longer a public servant myself, I feel a duty to take advantage of my free citizen status and make my voice heard.  The irony of this is not lost on me, and has got me thinking. Hard.

A week has gone by, and we still don't know what the outcome will be for Sarah personally.  As Tom Watson observed, this is a big test for government transparency. I can only hope that those concerned are well-informed enough to make the right decision.  

In the meantime, I have been wondering where this will leave the Public Servant 2.0 in the longer term.  Sarah has been ably defended by many articulate and enlightened people in blogs and in the mainstream media, so what are the themes that emerge from this discourse?  What will we want to say in our defence if/when this happens again?  And why should it be a defence?  Why don't we draw a line in the sand and assert our right to be doing what we do, on our terms, as long as we do it responsibly.

I know that there is good guidance such as Participation Online in place, and overarching professional codes apply.  These serve their purpose from the organisational perspective, but what should we as individuals get out of the deal? 

It would be good to be able to put forward a statement of principles of engagement that we as a community can point to in these situations, in simple terms so as to be widely comprehensible.  Here is a starter for ten.  I welcome all comments and contributions!

The Baskers Principles [working title]

Public sector workers who make good use of social media can deliver great benefits, both to the organisations they work for, and more importantly to the public they serve.

In return, we ask that:

We are trusted to further the discussion on how to deliver better public services by the most effective means available to us, in line with our professional codes

We are allowed to identify ourselves and take responsibility for our opinions and actions

Our professional presence is judged professionally, and our personal presence personally

We are supported in the face of ill-founded criticism [or blatant bullying!] in the online world as we would be in the offline world