Most organisations think in terms of web projects, but successful websites like GOV.UK are developed through ongoing iterative and agile development. How can we reconcile this difference in thinking?
In this post I want to focus on one of the two cornerstones of their success and look at why it can be so challenging to implement elsewhere.
That cornerstone is their agile approach.
Agile web design
I’ll be honest. I am not a big fan of Agile (with a large A). Proponents of Agile can be a little fanatical for my tastes and like any system, it works better in some situations than others. However, taking an iterative, agile (with a small a) approach to developing websites has been shown time and again to be incredibly effective. Without a doubt it has been instrumental in the success of GOV.UK.
The element of agile that seems to have proved most effective is their move away from specifying everything upfront. No extensive invitation to tender, no long specification of functionality.
Instead the Government Digital Service takes each new service they want to bring online through five phases. These are:
Setting aside retirement (which is the process of taking a website offline), each phase helps define the final deliverable until the point of going live. Even once the site has been designated live, continual monitoring encourages further refinement.
Why then, despite this being proved to be an effective technique, does this approach not happen more often? As I pointed out in my post ‘no more web projects’, the problem lies in the way both organisations and many of their suppliers think.
The problem with agile
Organisations like issuing invitations to tender. This is because they like clearly defined projects with a fixed investment and what is perceived as minimal risk.
The idea of asking a web designer to simply go through a process of discovery, alpha, beta and live, without a clear vision of what will emerge at the end does not fit nicely into this world view.
Not that web designers are much better. Agencies in particular do not always fit nicely into this model. Agile demands a collaborative approach with internal staff, which is not compatible with many agencies thinking. Working with a client this closely, without specifics being tided down seems like a risky business, especially when working on a fixed price.
What is so impressive about the Government Digital Service is that they did not allow these constraints in thinking to hold them back. Instead they formed a team to work on an Alpha.
Using both internal and external staff
The team formed by the Government Digital Service consisted of both internal people from within Government and outside contractors (freelancers).
This team came together to work on the Alpha version of the service, while a permanent team could be formed for the longer term. This mixing of internal resources and outside expertise proved effective. Although GOV.UK is now mainly developed by internal staff (many of which were previously outside contractors) it does still pull in external experts where appropriate.
External contractors were not hired to fulfil a fixed brief at a fixed price, but were instead hired on a time and materials basis for a fixed term contract. It was expected that by the end of this contract an alpha would be completed.
This is not that unusual an approach. After all many large organisations regularly hire staff on a contract basis. These staff worked in-house alongside internal staff so there was little concern about whether they were pulling their weight.
One can easily see how external contractors could be used alongside internal staff to form a web team capable of working on a new site or service, without the need for complex specifications or fixed price proposals. The question is, where does this leave agencies?
Do agencies have anything to offer in the GOV.UK model?
The approach outlined above is a simple one. Identify what kind of roles you need to develop the next stage of your web service (be it discovery, alpha, beta, live) and see who you have internally to fill those roles. If you do not have the people, or they are too busy, hire in outside contractors to fill the gaps.
Unfortunately there are two problems with this. First, it can be hard to find the right people and second your needs may change through the life of a particular stage.
Its hard to find outside contractors
Finding the right people for these roles is time consuming. Unless you are plugged into the web community, the chances are you are not going to know the first place to look for a good designer or developer. Even if you find yourself a great lead who can source people for you, they could just as easily struggle to find good people with the time to work on your project.
In addition each person requires individual contract negotiation and requires management.
The people you need may change
Then there is the problem of changing requirements. Going into an alpha phase for example, you may believe that you will need a designer for the entire period. However, what happens if you don’t? You are now stuck paying a member of staff you do not need.
Equally a need might turn up that you hadn’t expected and you will be left struggling to find somebody to fill that role.
With an agency you don’t have these problems. One supplier means one contract. There is an established team of people (with a track record of successfully working together) with a wide variety of expertise. These people are easily accessible without the need to search or struggle with availability. The team makeup can be kept flexible because you are dealing with one organisation rather than many individuals.
But what about the fact that agencies tend to work on fixed price, well defined projects? How would an agency actually work on a GOV.UK style project.
What would an agency driven agile project look like
It has been suggested by some that agencies are just not compatible with the agile, iterative model, but I can see no reason why.
As I see it there are two ways that a client could engage a company like Headscape on a GOV.UK style website.
First, they could engage us in just the same way they would an individual contractor. They could buy man-hours on a time and material basis for whatever period they want. This time could be spent on one particular individual or they could pull in different people at different times.
The alternative is that an agency could be engaged to manage and run an entire phase of the project (e.g. discovery or alpha). Instead of the client being responsible for managing the process it could fall to the agency to form the team (from both their own team and those of the client) and make sure the project is complete. The project could be run as a fixed price project where instead of specific functionality being defined, the deliverable is a working alpha ready to take into the beta stage.
To be honest, the contractual arrangement between agency and client is actually simpler than between client and multiple freelancers. The challenge is in creating an integrated project team.
Forming a joint client/agency project team
Whereas freelancers are used to working within other organisations, most agencies are more familiar with working in relative isolation. The team within an agency doesn’t often work hand in hand with clients.
Of course at Headscape we do things a little differently and take a much more collaborative approach. Working as part of a joint team is just the natural evolution of this collaboration.
Isn’t multiple locations a problem?
Admittedly agency members of the newly formed joint web team probably wouldn’t work on site as much as some freelancers. However, I really do not see this as a problem. There are no shortage of examples of highly effective web teams who work remotely. Just one such example would be 37 Signals who successfully run a team spread around the entire globe.
Yes, I accept that there are benefits to working in the same room (something encouraged in Agile). However, there are also big advantages to having some time apart too. I would argue that agile, collaborative development can be done remotely with a considerable degree of success thanks to tools like Basecamp, Hipchat and Google Hangouts.
How would an agency/client team be structured?
Based on our experience of working with past clients, they are normally too busy dealing with the maintenance of their existing website to dedicate considerable time to the next phase in its development. In such cases it makes sense for the agency to initially take the lead.
The agency could assign a service manager from their staff who will own the vision for the next site. This service manager would then form an Alpha team to work on the new site. As with the GOV.UK Alpha this team would consist of client staff (where they can be freed up) and external contractors (staff from within the agency).
This new team would work through the discovery and Alpha stages together. As the project moves into Beta and towards live the agency would need to start looking to transition that team gradually across to internal staff, where agency staff are still being used.
In some cases this process will simply involve training up existing internal staff, while in other cases it would mean helping the client recruit new people to fill roles that have been identified.
The ultimate goal is that by go live, the client has an established internal web team capable of running the website going forward.
Of course in some situations the client may make a decision that they do not want to run the site entirely in-house, in which case the agency can continue to make up at least some members of the web team. However, the web team could never be entirely made up of agency members. And that is the crux of the issue.
The crux of the issue
With only a very few exceptions, there is no scenario where a website can be produced in isolation by an external contractor. In almost every circumstance it requires internal staff. The reason for this is simple, you cannot afford to employ an outside contractor forever.
Websites do not have a set shelf life. You will always need a website and so your website will always require maintenance. It will always need an owner who is iterating and improving it over time.
This is what GOV.UK shows us. It shows us that an ongoing cycle of iterative development is required to ensure a website remains useful. You may require outside help to get you started (as GOV.UK did), but ultimately it is you that has to own and evolve your site.
“Be different” image courtesy of Bigstock.com