Becoming Agile

A man climbs a staircase

Photo by tanakawho.

Well, it’s been a busy few weeks at work, and now that I’ve got a little free time I thought I’d get down to writing about it.

3 weeks ago we released V1.0 of CitizenScape, our latest product, to our Virtual Town Hall pilot group and we’re just about to release V1.1 for testing on the staging server. It’s been very busy, but we’re working hard to get tagging and taxonomy support into the product, which, we feel, will enhance the product enormously. More on that another time.

We’ve also launched our EuroPetition product; a project that takes our E-Petitioning application and enables it to be used Europe-wide to create and promote petitions to the European parliament / council. There’s still a little bit to do here for some of the territories, but on the whole it’s done and dusted.

With all the busyness, we’re having to tighten our processes and manage our time a lot better. We’re developing using the Scrum methodology – one of the Agile software development practices; and trying to work pragmatically.

We’ve recognise that, in the past, we have been poor at meeting deadlines. Sometimes this hasn’t been our fault – the deadlines have been set by a third party and we’ve not had the opportunity to provide an input; and sometimes it’s been that we’ve simply been bad at estimating the time that things will take.

We’ve adopted the Scrum process because we wanted an iterative process – one that would enable us to meet deadlines and plan the detail more; I’ve always felt that the more ‘traditional’ waterfall methodologies plan for the ‘big picture’ in an all or nothing way. If you run late you miss a deadline with little or nothing to show for it.

We’ve redressed this in a number of ways:

  • We’re working in fortnightly sprints, and ensuring that we have working products at the end of these sprints.
  • We’re prioritising the features so that we have the most useful application sooner, rather than later.
  • We’re asking for client feedback sooner, so that we fix issues or misunderstandings at the earliest opportunity. (Although we need to get clients more involved, still.)
  • We’re releasing little and often, and to a published, public schedule. Having the dates out in the wild means that we are more determined to meet them.

I wouldn’t say that we’ve fully adopted Agile or Scrum – we’re using what works for us and will review how effective it is over the coming months. Where there are inadequacies, we’ll introduce new methods to fill the gaps. Measuring our success at developing to the timescales and feature lists will be paramount to ensuring we can properly analyse our success (or lack thereof).

Things we need to do now to make life easier:

  • Align our release timetable to the sprint cycles. Currently the release (for client test) falls in the middle of a sprint, which isn’t ideal; it makes sprint planing a little difficult (for someone who is relatively new to such things).
  • Reinstate morning scrum meetings. We used to do these when we were using index cards for development stories but, since we’ve started using Pivotal Tracker, I’ve neglected to hold these on a regular basis. This is very remiss of me; not only do they help me to understand how we are doing compared to our desired progress, but they also provide a mechanism for the teams to discuss issues and resolve problems that may otherwise be overlooked.

So in conclusion, then, we’re getting better and there’s more to do. Having to release two major applications almost simultaneously has brought home the need for tighter development processes that allow maximum flexibility. We believe that Agile development and the Scrum methodology are appropriate for the work we do and the way we work.

Next time I hope to be able to introduce our thoughts and solutions to tagging, taxonomies and the semantic web, some feedback on the applications we’re launche,; and an update on our progress with Agile and Scrum. Until then, good night.

The Crowd Sourced Council: Review

Yesterday, I attended “The Crowdsourced Council: online tools for participative policy making” in London (twitter #tcsc). It was a very interesting and informative day and I’ve come away with a lot of good ideas and glimpses at some of the tools that Councils and other public bodies may be using to engage their citizens in the future.

My interest in attending the conference was fuelled by the CitizenScape product that Public-i have created, and for which I am, at least partly, responsible. In particular, I am interested in the potential integration of these products into CItizenScape, either as widgets or via APIs. This is subject to a number of factors, including product take up, availability, popularity, etc. However, my interest is in the technical, rather than the strategic, aspects of integration.

The event was split into 3 sections – after a brief introduction by Domanic Campbell (Managing Director, FutureGov), the first half was a brief ‘pitch’ (for want of a better word) from each of the 6 companies, followed by a period of ‘milling around’ – looking at each product and chatting with the reps – and rounded off with a question and answer session.

The Products

The products on show were (with weblinks and twitter feeds, where available):

I’m not going to do an in-depth review of each company / product – suffice it to say that each, in their own way, has a part to play in citizen engagement and bringing councils and communities together.

By the way, it’s interesting to note (to me at least) that quiet riots is using uservoice as its feedback channel.


All in all I found each product to be a potential feed for the CitizenScape platform. Some are more readily integrated than others, with widgetised versions of themselves that can be embedded (Yoosk, for example) although I would prefer to have API access as this will provide better access to meta data – which is, in part,  CItizenScape’s USP. Some spokespeople were more technical than others, so there’ll be a bit of follow-up required in order to complete the research into the viability of each of these products.

As I said at the start of this piece, there’s still a long way to go with getting councils using tools such as these, and so the timescales for implementing the integration of any of these is very much up in the air. The exceptions to this might be audioboo and quiet riots as they are not predominantly centred around council involvement – they are out there, content is being created and we should be listening to it and presenting it alongside the blogs, petitions and other feeds we are already taking.

Square Pegs and Round Holes

A round hole in a wooden plankThis post is more of a brain dump than anything else; just a place to put my thoughts.

I’m currently architecting the ‘cluster manager’ application for the EuroPetitions EU project that we are a part of. This is a fairly easy piece of work, a simple dashboard with some APIs through to external ePetitioning systems.

Ideally, I want to use the flexibility that our CitizenScape product provides, but ‘widgetising’ the cluster manager in order to incorporate it seems like a lot more work than necessary. The proper way to do it would be to create an external cluster manager application and then provide a widgetised version to CitizenScape. The alternative is to incorporate the code for managing EuroPetition clusters into CitizenScape. Here are the plusses and minuses, as I see them, to these two approaches.

External Cluster Application


  • Appropriately architected
  • Easier development / maintenance, particularly where multiple developers are involved.


  • Potential integration issues
  • Widgetisation may limit how the cluster manager can function
  • Time constraints (this has to be done in 15 man hours – and counting)

Cluster Manager in CitizenScape core


  • Can use existing core code / helpers / views / templates – should reduce development time


  • CitizenScape code muddied with non-core functionality
  • CitizenScape database schema muddied with non-core structures


Much as I hate to say it (due to time constraints), I’m going to do it the proper way. I can’t imagine that this application will not run for a long period of time and I need it to be easily maintainable. So here’s what I’m going to do:

  • Create the cluster manager as a new application / schema
  • Develop the ‘business logic’ / models in full
  • Create an API controller and views to supply widget-compatible snippets to CitizenScape.
  • Create the CitizenScape widgets to incorporate EuroPetition cluster management into the CitizenScape platform.

Right, now that that’s sorted, I’d better get on with it…