The agile approach. If you of haven’t heard about it you’re either living under a rock or locked up in an airtight cubicle updating the thousandth revision of your project specification. Developers love it, designers are coming to terms with it, but what about you – the client? Find out how being agile can save you money, minimise risk and give you the best product for your budget.
Why an agile approach is scary
If I was a commissioning a large web project, putting a big wad of my investors’ – or worse, my own – money on the line, the first thing I would want would be a guarantee that my product would be created as per my requirements, on time and on budget. I know, I’m a dreamer. This natural need for reassurance is why we have contracts (I promise to pay you money if I you do X), and why we have specifications (X).
The agile mindset turns this seemingly fool-proof system on its head. Instead of agreeing on the full scope of the project, outlining all the required functionality and drawing a blueprint of the entire system up front, agile practitioners say: Let’s forget about the specification. Instead, let’s write a long list of user stories (i.e. things that you’d like your users to be able to do on the site) and arrange them in order of priority. Every sprint, which usually lasts one or two weeks, we’ll tackle the top stories on the list and add them to what’s already been completed. Furthermore, we’ll stick to your budget and timescale, no questions asked.
Sounds good, right?
Here’s the catch. They won’t be able to tell you how many stories they will complete each sprint, let alone for the duration of the project, though as the project progresses they – and you – will get a fair idea of the project velocity. As a result, when your entire budget has been depleted you will have a fully working version of whatever stories you chose to prioritise, but there’s no guarantee you’ll have everything you wanted from the outset. In fact, I can pretty much guarantee that there will still be a heap of desirable features left on your wish list at the end of the project life cycle.
And that, understandably, is a very scary prospect to any client.
Why specifications are scarier
Now, as scary as the uncertainty of an agile project can be, let’s consider the alternative: a comprehensive and complete, fixed budget specification. At first glance, this is any client’s dream. You tell your agency exactly what you want, and they tell you exactly how much it will cost. But, assuming for a second that it is actually possible to predict the scope of a sizeable project (which is an utter fallacy in the first place), there are two problems with the notion of a “complete, fixed price specification”: The first is that it is “complete”, the other is that the price is “fixed”.
A complete specification is only complete if it is stored in a locked box as soon as it’s written, never to be edited again. It should go without saying that specs don’t work this way. As soon as reality influences a project, be it through internal tests, stakeholder meetings, changes in the industry or real user feedback, it becomes apparent that what one might have thought a simple, quick or intuitive solution at the outset in actual fact is a complex, slow or unintuitive solution when implemented. Likewise, what one thought would be a very useful feature at the outset may turn out to be superfluous following user feedback.
The contradictory nature of specs is that they are written at the beginning of the project, which also happens to be the time when clients, designers, stakeholders and developers know the least about it. Assumptions about technical complexity or usability seldom hold up when developers start coding or real people start using the system, thus the specification is in constant danger of obsolescence. The remedy to this problem is, of course, to assign a person to keep the specification up-to-date, to edit and amend it every time a new feature is suggested or removed (as if!). Which brings us to the second problem: fixed price.
Accepting that a spec is not a one-off, but rather a high maintenance, slowly evolving beast, the implication is that the price will grow to suit the ever-changing scope. By show of hands (or comments below), how many of you, as clients, have been slapped with and extra bill following scope creep on a large project? How many of you have appointed an agency through a tendering process and found that the cost doubled after a thorough examination of the project requirements or resulting specification? How many have come in exactly on budget?
If you raised your hand on the latter question you may be quite happy with yourself, knowing that due to your diligent management there was no scope creep and there were no budget spikes. Think again. On any large project, there is always scope creep. Always. It’s not your fault, it’s not the developers fault – one simply cannot know the exact nature of what one is creating until one has created it. And if you think the scope didn’t change because you didn’t get charged for it – or worse, because you refused to pay for it – it probably just means your agency picked up the bill (and they’re miserable as a result, considerably lowering the quality of your product).
The point I’m making is that your product will most likely not be exactly what you pictured at the outset. Furthermore, by ignoring this fact and believing in the false notion of a “complete, fixed price” specification you run the risk not only of the end product being less sophisticated than envisaged, but also blowing the budget and timescales in the process.
Suddenly being agile doesn’t seem so scary after all.
The Edinburgh trams
Let me further illustrate with a little story. In 2007, a year after I moved to the Scottish capital, Edinburgh Council embarked on a project to create a tram line from the airport on the western outskirts to Leith, on the northern seafront, with an estimated budget of £375 million and completion date of 2009. Hailing from tram-touting Oslo, I was delighted, and I looked forward to swapping my hour-long bus journey to work with a much slicker tram ride. How naive I was.
A year in, I remember seeing signs along the street saying “the Edinburgh trams – taking you to work in 2011”. That’s right, one year into the project the deadline was already pushed by two years and, to anyone living or working in Edinburgh, the rest is history.
Today I’m walking to work, and the trams are still not running. The total budget is likely to top £1 billion, and the tram line will only be half as long as planned. Businesses that lost money and, in some cases, were forced into administration due to the reduced footfall caused by the major roadworks across town have been told the tram won’t even reach them. Both the chairman and the CEO of Transport Initiative Edinburgh (TIE), the committee in charge of the project, have resigned, the former calling it “hell on wheels”.
What went wrong?
The blame for this farce has by and large been put on TIE and the project leaders, a collective of “teachers and social workers who somehow ended up in influential positions” (David McCann of the Edinburgh Evening News), who, in turn blame the German contractors, Bilfinger Berger. Now the alleged incompetency of the parties involved is not relevant to this article, but the way in which the project was run – by means of a “complete, fixed price” specification – is.
With a naive deadline and a very optimistic budget of £375 million, Bilfinger Berner set out to dig up the whole route – 18.5 kilometres – from the airport to Leith. As major roads were crippled by roadworks, it became apparent that rerouting the city’s utility pipes and cables was not as simple as originally thought. On top of this, unmapped caverns, cellars – even ancient burial grounds – were discovered. Complexity quickly escalated, costs spiralled and both the budget and deadlines slipped further and further.
In project terms, this is called scope creep.
To make matters worse the contracts were, once again in the words of Mr McCann, “piss poor and open to interpretation”, meaning disputes – and there were a lot of them – constantly ended up in arbitration. Neither the council nor the contractor wanted to cough up the dough for the unforeseen delays and unpredictable complications, and their relationship, not to mention the development of the project and the city’s coffers, suffered copiously.
An agile alternative
Now let’s imagine another scenario, one in which both parties accepted that unpredictable complications are part of the game, and approached the project with an agile mindset. Instead of trying to build the whole line at the same time, they would start in one end and worked their way to the other. Step by step, kilometre by kilometre.
Sure enough, complications would have arisen. The same tombs would have been unearthed, the same maze of utility pipes and cables would have had to be rerouted. This is simply the nature of any project of a certain scale. Furthermore, the budget would have been just as naive, and the timescales no less so. But here’s what could have been avoided:
- No businesses along Leith Walk – a significant part of the planned route that got dug up but will not see the tram line reach them – would have been crippled and forced into administration.
- The Council may not have bought 27 trams, now out-dated, for a 14km line (that’s a few trams too many!) years before the line was operational
- The several kilometre stretch running along Princes Street probably wouldn’t have broken down and had to be redone as testing would have been possible on the early stretches of the track
- The never-ending roadworks impeding millions of tourists and commuters would have been staged, only affecting a small part of the city at any given time
- Contractual disputes may have been eradicated with a proper agile contract in place
I’m speculating, of course and it’s impossible to predict what could have happened had the approach been different. But, accepting for a moment that an agile process would have been possible, even if the end result would have been the same – a tram line that stops short 4.5km of it’s intended destination – I can’t help but feel they would have got there quicker and cheaper if they started in one end instead of everywhere at once.
The lesser of two evils
The need for an agile process is emerges from this simple, invariably underestimated, truth: It is impossible for anyone to predict the scope and progression of a project until you start working on it. No matter how good a project manager you hire, no matter how detailed the specification, a couple of weeks into a project things always look different from when you signed the contract. And when the inevitable complications occur, three possible outcomes are available: you extend the deadline; you extend the budget; or you adjust the scope.
An agile process presumes that budget and deadlines are fixed, and continuously adjusts the scope to keep them so. The result may be less comprehensive than anticipated but it will work well. A traditional approach presumes that deadlines, budget and scope are all fixed, but ends up changing them all when reality comes knocking. The results may vary, depending on the depth of your pockets or the calibre of your lawyer.
At the end of the day, what is better: a fully functional half, or a non-functional whole? Yes, that is rhetorical.
What you can do
Any project always involves at least two parties – the client (that would be you) and the contractor – and it goes without saying that the success of the project relies on all parties doing their bit. The contractor’s role is simple enough: do the work required within the given deadline and budget. But what about the client? Here’s a few tips on how you can do your bit to ensure the best possible outcome.
Trust your agency.
A big barrier to entry for agile-sceptical clients is the issue of trust. Not surprising, considering you’re paying purely for someone’s time, and that someone is telling you “I can’t promise you everything on your wish list, only that I’ll do as much as I can in the time I you’re paying me for”. That’s why it’s important to find an agency you trust.
When engaging an agency, make sure you get to know their staff (not just their sales team) and find out what their passionate about. Look at their track record and speak to their previous clients and, above all, find people that you like, people that are honest and people you feel comfortable discussing the cold, hard truth with. Remember, for the duration of the project (at the very least), your agency will be your partner – through good times and bad.
Embrace the minimum viable product.
An agile process focuses on establishing a Minimum Viable Product (MVP) as soon as possible and improving it in subsequent sprints. To this end practitioners often speak about ‘core functionality’ and ‘enhancements’ as two separate aspects of the same user story. For example, if your vision is a drag-and-drop multiple image uploader that dynamically orders the files by size, the ‘core functionality’ would be the ability to upload files by any means, and the ‘enhancements’ would be the drag and drop functionality, multiple file capability and ordering. The core functionality and each of the enhancements would be recorded as individual user stories and tackled in order of priority.
Don’t worry if your agency questions your enhancements early on, it does not mean they don’t see the value in them. It is simply the recognition that the MVP of an all-singing-all-dancing image uploader is a working way to upload images. Once this part is working, additional sprints can be used to add the enhancements – or other, more important, core functionality of the overall project.
Get your priorities straight
Having seen how a small part of a big project, such as an image uploader, can be broken down into several user stories, it’s important that you – the product owner – is engaged in the process of prioritising such stories. It’s a continuous, arduous process, but absolutely necessary for the success of the project.
For example, you may know that you want users to sign up to your site, perform a particular action, then pay for said action. But in which order should these aspects be developed? Payment may seem absolutely critical, but what’s there to pay for if the action isn’t implemented yet? Or, a less straight forward example: is it more important that your users can sign up using their Facebook account, or that they can use Google checkouts to pay for the product?
The key to prioritising your user stories is to be brutal and accept that some things, no matter how desirable, are less important than others.
Is an agile process for you?
I’ll be the first to admit being agile is not a silver bullet, and it’s not necessarily the right approach on all projects (especially smaller ones). For starters, an agile approach requires the product owner to be 100% engaged and demands tough decisions on prioritising user stories. It also demands a flexible and enthusiastic agency that you absolutely trust. And it demands that you, the client, understands and embraces the value of starting small.
The demands of agile are not to be taken lightly, but I would argue that they inherently apply to all successful projects, regardless of approach. What product owner would risk NOT being 100% engaged? What ambitious entrepreneur would choose to work with an agency they didn’t trust? What experienced business person doesn’t see the benefit of starting with the basics and enhancing it over time?
At the end of the day agile is about minimising risk, both for you, who don’t want to spend more money than you have, and for the agency, who doesn’t want to spend more time than they get paid for. Now if you still feel like a traditional, ‘complete, fixed price’ specification is the best way to minimise these risks, consider the following statements, also called ‘the three agile truths’:
- It’s impossible to gather all of the requirements at the start of the project.
- Whatever requirements you do gather are guaranteed to change.
- There will always be more to do than time or budget will allow.
Accepting the above statements, it follows that the best way to minimise risk is to apply an approach that doesn’t rely on a complete set of requirements up front, that doesn’t rely on those requirements being accurate, and that doesn’t suppose that time and budget are flexible. And that approach, my friend, is the agile approach.