I work in a team that manages local government web development projects. We work closely with applications developers in IT and we do most of our development in-house. A couple of years ago we realised noticed a pattern in the way we were working. Some projects had complex requirements and often involved working with new technologies. Bigger projects took 12-18 months to complete, which meant that work on the other web sites or applications had to be put on hold.

Early in the project the teams would have workshops and lots of meetings with colleagues in the relevant council services (i.e. business areas). The project managers would develop very detailed specifications to document the requirements. We would produce wireframes to show how we proposed the interface would look (and sometimes we tested the wireframes with the site users). We would send these lovingly crafted specifications to our development team who would spend a few days reading through our bloated documents, trying to interpret what we meant. The development team would then work up a detailed estimate for the work. Between us we would spend a considerable amount of time negotiating scope and estimates  before agreeing to proceed with development.

At last the developers could roll up their sleeves and start writing some code. The developers would work tirelessly to develop functionality that met all the requirements in the specification. Sometimes the developers weren’t able to complete all the functionality because they encountered problems they weren’t expecting because the technologies were new to us all. When the services got to do acceptance testing, they would ask for additional or different functionality, but by this time we’d used up the budget and run out of time to do any further development. If you hadn’t already noticed, I’m talking about the waterfall development methodology which follows a sequential process as follows:

We needed to find a way we could work more efficiently, improve communication with the development team and services and meet business and user needs more quickly.

Enter Agile

We’re about to change the way we work quite dramatically. We are proposing to use an Agile methodology known as Scrum. The Scrum Alliance defines Scrum as:

A team-based framework to develop complex systems and products.

This means working collaboratively in a small team on short, “time-boxed” iterations of design and development with daily face-to-face communication in the form of a Scrum meeting. The aim is to turn prioritised requirements (or “user stories”)  into working software, but to be adaptive to changing requirements throughout the development process. The Scrum process looks more like this:

Agile is sometimes referred to as a ‘philosophy’, or ‘state of mind’. But local government is not really known for being agile. I often hear people refer to how long it takes to get simple things done in local government.

So how can we best fit the principles of working in a more Agile way within local government constraints? Well we’ve already overcome some of the constraints in making a decision to try using an Agile development methodology, instead of the more traditional Waterfall methodology. I’m going to focus on two areas that we are likely to present us with the biggest issues as we start using Agile for real on our web development projects.

1. Communication and collaboration

One of the principles of Agile states that:

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Another is:

Business people and developers must work together daily throughout the project.

Agile requires frequent face-to-face communication and team collaboration. Some of the barriers that we might face include:

• Individuals who need to work in Agile teams are not currently co-located and meeting rooms are like gold dust.
• Shifting from a culture of long, sit down, round table meetings to disciplined daily stand ups will take some getting used to.
• We sometimes rely too much on email to document (and back up) decisions which is time consuming.
• We may struggle to involve colleagues from services in sprints – everyone has a day job to do.
• Prince2 culture – we’re used to churning out masses of project management documentation rather than relying on face-to-face communication.

2. Designing the user experience

The second area I think will pose the biggest challenge to us will be designing the user experience in an Agile way. By ‘users’ I mean citizens and have deliberately not referred to them as customers. In Scrum the ‘customer’ is usually the stakeholder who represents the business (and often controls the budget). I have written a couple of previous posts on how we are adopting user-centred design (UCD) methods within the Council.

In the past we have produced wireframes to communicate design ideas and, where possible, tested them with users. But wireframes are time consuming to produce and are often produced in isolation, so only reflect one person’s ideas about how something should work. This has caused us problems because we’ve treated the wireframes as ‘blueprints’ and get services to sign them off. But, as Brandon Schauer points out, a wireframe is a static design of a screen and doesn’t convey interactions well. So as a result what we’ve designed in a wireframe can’t be implemented by developers straight off and developers often have to make design decisions in isolation. Ideally we need more two-way communication and collaboration. So we’re going to have to find quicker and easier way to create designs and work as a team.

Techniques like sketching and paper prototyping could help us to rapidly generate design ideas (see Bill Buxton’s book on sketching and Carolyn Snyder’s book or the new Todd Warfel book on prototyping). I’m keen that we can try using sketching and rapid low-fi prototyping as a team, but I think we have a few barriers to overcome. For example:

• Meeting rooms are rarely available to book at short notice for any length of time. We don’t have dedicated space to have informal meetings and offices are meant to be relatively paper free so we can work flexibly (hot desking) if required. This poses various challenges for holding regular, collaborative design sessions and surrounding ourselves with sketches, post-its and other outputs from design sessions during sprints.
• Being a Council we actively promote recycling and consideration for the environment and efficient use of resources, so going crazy with packs of post-it notes may be perceived as a tad frivolous and wasteful.
• There is a strong tradition of using words (e.g. in reports and documents) rather than visual artefacts to capture specifications.
• We don’t have a culture where design is a common place activity – it feels a bit unnatural in the local government environment.

I don’t think any of these barriers are insurmountable, but we’ll be on a steep learning curve. Hopefully I can share our experiences in a few months when we’re a few sprints wiser. I’m curious as to which barriers will prove to be the most significant and what solutions we come up with to get around them.

This content is published under the Attribution-Noncommercial-Share Alike 3.0 Unported license.