Coverage of council meetings by local bloggers

The coalition government has been pushing for greater transparency of Council decisions and spending as part of their Localism Bill. So I wasn’t that surprised to read Nick Booth‘s post about a recent press release from Eric Pickles.

Pickles has told Councils that they should be allowing hyerplocal bloggers to record public meetings. I’ve heard anecdotes that some Councils refuse to acknowledge hyperlocal bloggers or allow them the same access and rights as local media. So it will be very interesting to see how this latest advice from Pickles is taken on board.

I have been really impressed with the way Richard Taylor (unquestionably Cambridge’s most dedicated hyperlocal blogger) has been covering public meetings. Richard has provided an entertaining yet thorough running commentary of recent Council meetings, enabling those of us who are unable to attend to follow proceedings online, or catch up afterwards.


Software East – UX in software development

Just a quick plug for an event happening in Cambridge run by Software East, which is focusing on user experience in software design. The event is on Thursday 3rd March from 6-9 pm at Red Gate Software.

I was very flattered to be asked along by the organiser Mark Dalgarno to do a short talk on how we’ve embedded user experience design at the Council. I’m looking forward to the other speakers too, which include Rob Kerr and Neil Turner from Cambridge Assessment, Stephen Chambers from Red Gate and Dr. Jenny Cham from EMBL-EBI.

I haven’t attended any of the Software East events before, so I’m looking forward to meeting a new bunch of geeks in Cambridge and talking about UX and Agile development.

Service design - business strategy, democratic engagement, insight and data

Service design and localism

I’ve been doing a bit of thinking recently about a approaches to service design in local government in the light of the government’s localism or Big Society agenda.

The way I see it there should be a balance between the following elements:

Service design - business strategy, democratic engagement, insight and data

Business strategy

Let’s face it, business strategy in local government is primarily about cost cutting right now either through streamlining of business processes, use of cheaper channels, selling / transferring assets and working in partnership.

Democratic engagement

Listening to local communities and working with them to co-produce better public services and outcomes is one of the cornerstones of localism.

Customer insight and open data

This to me is the really interesting element in the triangle. Customer insight is data about what different customer groups want and need, what services they already use and what channels they prefer using. Data can be gathered from channel usage statistics and customer research. Open data is all about transparency and making data about council services, assets, performance and spending accessible.

Once data is out there in the open, it can be used to tell stories, which make it more meaningful. In turn this can stimulate ideas and provide new perspectives on how to deliver services.

So how might this model work in practise? If all three elements of the triangle are brought together:

  • Councils would need to clearly define the constraints – i.e. what cuts they have to make and where – and work with partners to explore new ways of working together to deliver public services
  • Communities, council officers, councillors, partner agencies and other stakeholders will come together in public networks, online or offline, to discuss how they want services to be delivered
  • Data will inform conversations and underpin decisions

Let’s assume in an ideal world that service design is an iterative process, whereby services are analysed, prototyped, tested and improved continually. Ideally each element in this model should be considered at all stages of an iterative process, to make sure one element is not dominant over the others. If business strategy dominates services may not meet community needs and if democratic engagement dominates services may be designed around more vocal groups within the community.

I’m not sure what the impact might be of data being a dominant element in service design. Or if it matters. This is just a way for me to think through service design and localism and I’d be interested in what anyone else involved in service re-design in local government thinks.

Mozilla Thunderbird reminder

Did you forget to send the attachment?

Since I started using email back in the early 1990’s there have been countless times when I’ve forgotten to attach a file to an email. I know I’m not the only one who suffers from this very common phenomena known as a post completion error.

The crazy thing is that errors like this should be considered in the design of software that supports such common tasks as sending an email. Early ATM machines used to give you your money back before your card, which resulted in many people leaving their card in the machine. This was resolved by simply changing the order of tasks, so now you get your card before your money. Which, after all, is the thing you went to the machine for in the first place!

So why in the last 15 years or so has this common error not been tackled in email clients? Well I can’t answer that one, but I was delighted to find this morning that Mozilla seem to have put a neat solution into their Thunderbird email client. Here’s how it works…

When you are writing a new email and mention words like ‘attached’ or ‘attachment’, Thunderbird automatically detects this and pops up a non-invasive reminder at the bottom of the email (highlighted in red).

If you still forget to add the attachment, despite the reminder, and click ‘send’ a prompt pops up in a dialogue window:

A pretty simple but elegant solution to a very common usability problem.

Ironically the way I found out about this was because I was in the process of replying to someone who’d forgotten to send an attachment to an email!

Agile session

#ukgc11 session on Agile lessons learnt in local government

In advance of this year’s fantastic UKGovCamp (aka #ukgc11) I pitched a session idea on lessons learnt from using an Agile project management method to manage web development. My idea for the session arose after some interest in a blog post I wrote recently and the discussion on the UKGovCamp forum thread.

So on the day I came armed with my slides and stood in line to pitch my session. I was joined by Stefan Czerniawski and Catherine Howe, who pitched a second session to explore the potential for applying Agile principles to policy. This is an area I am very interested in, but as I have limited experience of working with policy makers I ended up taking more of a back seat in their session, to observe, absorb and blog some loose notes.

Thankfully Catherine has written up a brilliant blog post about the session. Which is a relief, as I was flagging a bit at that point and was finding it hard to stay mentally alert. I think I used up all my energy facilitating the first session and also felt a bit ropey from having stayed out too late the night before – my only regret about the whole day!

The session went far better than I could have hoped for. It was well attended and resulted in an open and fascinating discussion about the practicalities of implementing Agile methods and applying them effectively.

Photo by Paul Clarke

There was a real mix of participants. Some with loads of experience and some who knew very little about Agile, but were curious to find out more. In preparing for the session I hadn’t really considered that some of the participants wouldn’t be familiar with the Agile manifesto, terminology or methods like Scrum and the roles involved. So I did my best to explain the concept of Agile and the Scrum method in simple terms in limited time and some gaps in my own knowledge. But I realise that pitching the session at the right level, to address the varying experience and understanding of those in the room, was a challenge. I look forward to Julia’s notes on the session (as mentioned in her write up of the day) as a relative Agile newbie.

I explained that we have used the Scrum method in my organisation (a county council)  for about 18 months for web development projects, with varying degrees of success. Here are the slides I presented in the session:

Notes and reflections from the session

The following notes are written up from memory, as I was too busy talking (as usual) to write down anything during the session. I haven’t attributed these insights to individuals (in case I do so incorrectly!), but they were a combined effort of the participants who attended.

It can be difficult to introduce Agile methods when senior managers are sceptical. I recommended starting small by applying an Agile method to development of a mature platform, rather than choosing a project with significant risks and unknowns.

Someone asked if you can do Agile covertly. And the consensus was – yes absolutely! Agile can fit within existing, more traditional project management processes quite neatly, e.g. within the ‘product delivery’ phase of Prince2. It was even suggested you could do Agile within the ‘implementation’ phase of a waterfall method and by the time you get to the ‘verification’ phase, you’ve already done the testing you need to. Business people don’t want to know how you are delivering something, just that you deliver results.

But…and there are two big buts…

  1. You do need the product owner involved. It can be very hard to persuade product owners to be involved in sprints and attend daily scrum meetings. Good planning ensures key individuals in the organisation are available when you need them to be.
  2. The scrum master has a key role to play in negotiating with product owners and other senior business stakeholders who insist on the delivery of particular features and refuse to compromise over the scope or prioritise their requirements.

When a development team learns their velocity over time, introducing someone new to the team can throw things off balance. Estimation poker can help the estimation process, because developers have to discuss and resolve why there are differences in their estimations.

Developers can sustain their pace when working in sprint cycles. Following a waterfall method can result in a huge rise in stress levels as you approach a big bang launch and everyone is working overtime to get a product finished. Instead there are small rises in stress levels at the end of a sprint, but developers should be able to leave work at 5 pm and maintain their pace in a sustainable way.

The velocity of the team (progress over a series of sprints) can be greatly improved by having a UX designer produce designs in advance of the sprints.

Agile involves developers in business strategy, so they work towards achieving business objectives.

Although the Agile principles promote face-to-face communication and co-location of teams is often cited as being important, it is possible to use geographically dispersed teams  if you make good use of technology. An example was given of how a team which is distributed worldwide use Skype to manage daily scrums.

Not everything gets finished at the end of a sprint. Developers must be prepared to throw code away.

Be flexible about the method and techniques you use e.g. user stories could be written up on cards and stuck on the wall, kept in a spreadsheet or a specialist application.

Agile can be applied outside IT contexts. One participant said that his organisation has applied Agile principles to business strategy projects.

I’d like to extend my thanks to Dan Hardiker, Andrew Woodward, Catherine Howe and Sharon O’Dea who all pitched in with excellent insights based on their experiences of working in an Agile context. I personally learnt loads from the other participants.

Which goes to show if you’re willing to share your own experiences, you get back a bucketful of new insights and knowledge from others in the process!


Dissertation research: perceptions of using social media for community engagement

I’ve talked about my MSc dissertation research before on this blog. In fact I originally set up this blog to explore some topics related to my research. Having had a bit of a break after completing my dissertation in August 2010, I have decided to publish it here, spurred on by the kind words of a fellow academic researcher Catherine Howe.

My research question was:

How do the attitudes and perceptions of citizens, Council officers, Councillors to the use of social media for community engagement compare and contrast?

My Master’s Degree was in Human Computer Interaction. If you have a particular interest in research into social media and civic engagement (and quite a bit of time on your hands), I’d recommend the full dissertation (PDF, 2.4 mb).

But if you are a local government officer or someone with less time and patience, then I’d recommend the 10 page (that’s the smallest I could manage!) Executive Summary (PDF, 50kb).

I also wanted to add a little disclaimer. The primary research data was gathered from semi-structured interviews with 18 participants. For purposes of confidentiality the data is not included within either document. Because the research question focused on a relatively new research area, it was challenging to find participants with significant experience of using social media, let alone those with experience of using social media for civic engagement. Whilst the collection and analysis of data followed rigorous qualitative research methods, the quality of the data collected was not as high as I had hoped for. I would therefore advise some caution in the interpretation and application of these research findings.

Please note that the usual Creative Commons copyright license I display on this blog does not apply to the two documents linked above.

You can find me on Twitter if you have any questions, comments, or would like more information about my research.


In the hotseat…

This Thursday 13th January between 1-4 pm I will be in the hotseat, quite literally! I’m hosting a online question and answer session in the Local by Social Online Conference about the social media project I have been involved with in Fenland, Cambridgeshire.

The project aimed to improve engagement with customer groups who were hard to access in Wisbech. The project has been delivered with funding from the Local Government Delivery Council’s Customer Led Transformation programme.

You need to be a member of the Communities of Practise to participate in the hotseat discussion. To become a member of the Communities of Practice platform you will need to register and  join the Customer Led Transformation CoP. You can then join the hotseat discussion thread where you will find the full project case study and some vox pop videos with people who contributed to the project.

If you would like to know more about the project or ask me anything about using social media to engage customers, do come and contribute to the online discussion on Thursday 13th January, between 1-4 pm

By way of a little background, I’ve written about the project before in these posts:

Update on social media project in Wisbech

Fenland social media project

Digital engagement framework adapted for local government

Digital engagement governance

And you can also visit the project blog or take a look at a presentation I did for the Local by Social online conference last November.


Going undercover

Do you sometimes feel like you are the only one who thinks it’s important to find out how your customers use your organisation’s website? Have you ever read user experience design books where you think “yep that all sounds great, if you’ve got loads of time and a big budget to boot, but how am I going to get agreement from stakeholders to spend time and money on that?”

If you feel like you’re struggling to do user experience design *properly* then you should probably read Undercover User Experience Design by Cennydd Bowles and James Box, who both work at the well respected Clearleft, published within the New Riders Voices that Matter series. It’s an easy, enjoyable read and if you’ve ever struggled with introducing user experience design methods or culture into your organisation, you’ll get loads out of this book.

The authors provide clear descriptions of a number of UX methods and deliverables and demonstrate how they can be used in context to better understand your users and design for them. But they also tackle organisational culture and how to work with other stakeholders, including project team members and senior managers. And no matter how good your research or designs are, you won’t succeed if you can’t work collaboratively and influence your colleagues or clients.

I’ve worked in the private and public sector, agency side and in-house. I’ve always worn multiple hats in project teams. I’ve been the project manager, the developer, the user researcher, the information architect, the user experience designer and the product owner. I found this book really pragmatic because Bowles and Fox don’t assume you are a UX consultant working agency side (aka an ‘outie’), but also provide advice for those working in-house (an ‘innie’).

What they really drive home is this: if you’re passionate about user experience and you care enough to try to make a difference, you can do. By going undercover, being disruptive and getting results.

On the companion website to the book they have re-produced the book’s manifesto from chapter one, which reminds me of the Agile manifesto. I particularly like the statement ” UX is a mindset, not a process—it lasts all the way until the site is live, and after”.

“We believe in going undercover. We don’t mean you should skulk around in the dark. As an undercover user experience designer, your mission is to get people excited about UX without them realizing what you’ve done. Unless you’re an expensive consultant or a senior manager, you won’t do this by knocking on the CEO’s door and demanding change. User experience design is disruptive. It asks difficult questions. Good-enough managers in good-enough companies don’t want you to rock the boat; they’re busy worrying about meeting next month’s targets.

We believe in introducing UX from the ground up. Sneak UX into your daily work, prove its value, and spread the message. Results are more persuasive than plans.

We believe change comes through small victories. Putting users at the heart of a business is a huge cultural change. It takes years. But you’ll be surprised what you can achieve with focus, patience, and persistence.

We believe in delivery, not deliverables. Some people practice user-scented design, not user-centered design. They churn out documents—sitemaps, wireframes, specifications—but they’re not interested in what happens next. UX is a mindset, not a process—it lasts all the way until the site is live, and after.

We believe good design today is better than great design next year. There’s no such thing as perfection in design, particularly on a medium as fluid as the web. You’re not here to impress other designers; your job is to make your users’ lives better.

We believe in working with people, not against them. Just as we empathize with users, we must respect and understand our colleagues. We reject elitism and accept that compromise is healthy. Passion is fine; zealotry is not.

We believe in action, not words. Introducing UX into your company is a lot of work. No one will do it for you, so you’d better get cracking. Remember, it’s often easier to get forgiveness than permission.”

If you’re a seasoned UX professional then you may feel you can do all this and more standing on your head. But I would highly recommend Undercover User Experience Design as a good read nonetheless. And for those ‘innies’ among us, particularly those who often feel like a lone voice championing the user, this may well be the book for you and your colleagues. I’ve already lent my copy to two people in my team!

Examples of personas

Using personas for web and service design

I’m a fan of personas. In the user experience (UX) field, personas are fictional profiles of your users based on research data. Personas can bring your users to life and help guide the design process. Giving your personas names, pictures, personal profiles and using believable narratives will help everyone involved in a project to empathise with user goals, behaviours and motivations in a very tangible way.

Personas have been used in web UX design for a number of years. Alan Cooper has long promoted the use of personas as part of his goal directed design method. I have recently been reading an excellent book by Steve Mulder on personas. Turning research data into personas can be overwhelming and I’d recommend Steve’s book if you want a really good understanding of how to develop and use actionable personas.

Examples of personas
Photo by CannedTuna on Flickr

Continue reading


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 :)