Software Specification Documents (a.k.a. ‘the bad old days’)

Traditionally, the client comes to us with a requirements document (or  ‘software specification’ document) and asks us ‘How much will it cost?

Of course the fastest way to make the sale is to pick a figure that you know to be competitive and close the deal, implying a very simple transaction: ‘You’ve told us you want X, we can provide it for £Y’ What could be simpler! Same as going into a car showroom and buying a car, right? We all understand web systems these days so we just name a price and deliver the product. Oh dear.

In this type of engagement (the ‘Waterfall’ model), client satisfaction tends to move like this:

Client Satisfaction - Waterfall

See? The client’s satisfaction trend looks like water falling down a waterfall. Hence the name.

As a client, a waterfall project has a tendency to go like this:

Month 1

Contract signed. We’re delighted that we’ve found such an intelligent and accommodating agency that fully understands our specification document and has given us such a competitive price with the minimum of fuss. Hell, it was just like buying a car with a 5 month delivery time, and the best cars always have a waiting time, right?

Month 2

Still looking good. We’re impressed with the business acumen of the consultants and analysts. They’ve generated some very impressive diagrams and documents. Colleagues all agree that these guys seem to know their stuff.

Month 3

Wireframes delivered. Wow, that’s a whole bible of wireframes. These guys have delivered a wireframe for every screen of the system and it looks great. Couldn’t be bothered to read all 123 pages and I have some private doubts about whether we understand it all, but we can trust these guys, can’t we?

Month 4

First test release available. Only 10% of the screens have been built so far and we’ve been asked to ‘have a play’. Hmm. Not quite what I thought the system would be like and I can already see some changes we’ll need. Looks like the guys want to finish the first build and then do changes later, which will be additional costs. Erk.

Month 5

SH*T. Yes, the system looks like the wireframes but the list of changes is doubling in size every time I show the product to a colleague and there’s going to be a big overrun. Meanwhile the developers say that they have to finish the first build before they get to changes so they are building stuff we already know we want to change. Stop! Stop!

The Agile approach from a client’s perspective

In an Agile engagement, client satisfaction tends to move like this:

Client Satisfaction - Agile

Month 1

Contract signed. We’ve engaged with an Agile agency that come recommended but must admit we are somewhat bamboozled by the jargon of backlog, sprints, acceptance and releases. Still, Agile is the way to go so let’s wait and see keeping fingers crossed.

Month 2

We went to a couple of analysis meetings where the guys wanted to re-write our requirements as ‘stories’ which seemed a bit like paraphrasing to me, but they forced us to state the business benefit for each requirement which triggered some good debates and insights. And a couple of weeks later we had the first 2 screens up and running! I can actually create a user, get an email, choose a password and login already! I don’t see anything when I login but it’s nice to have that part working so soon.

Month 3

I can now login and see the product management screens. It’s all working well and I can play with the system from home and show to colleagues who have given some useful feedback.

Month 4

We were going to do some automatic product update emails but now that we’ve been playing with the test system for a couple of months we actually decided to prioritise the discount codes feature instead. It’s about the same amount of work apparently so we just swapped one job for the other.

Month 5

The registration, shop, product management, discount codes and shopping cart are all done and working well. No-one has found a bug for 3 weeks and the guys have offered to push the system live with these features a month early, while we add the email alerts that we deprioritised last month.

Happy days!

Agile wisdom says that the client should get immersed with the development team and admittedly this requires a sizable time commitment on the client side.

But our experience tells us that so long as the fundamentals of Agile are in place the project can be run successfully, to a degree at arms-length, which is a better fit for the agency/supplier contract and still delivers the goods with more ‘transactional certainty’ for the client up-front.

For more on Agile development visit Strategic Apps website

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s