Photo by tanakawho. http://bit.ly/cBOklT
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.