They still think Waterfall's a really good idea...

I read a bunch of project management blogs - they (almost) all take agile approaches as read. I'd hoped this meant that everyone now understands that agile methodologies give better results than waterfall with lower risk. But maybe agile types are more likely to blog. Or maybe I'm just selecting content that I already agree with.

Last week I was handed a project spec to read that was decomposed into 4 themes:

1. Integrate the microsite fully into our website's strategic architecture
2. Do some interesting archive exploration work
3. Do some more really flashy archive exploration work
4. Add some really really flashy UGC and social network features

This is intended to go a number of agencies to tender for lots and lots of money. There's something wrong with this picture.

What's the problem?

You don't need to know the project or the host site to see that this spec is looking to deploy rather more than the Minimum Viable Product. We're probably not in a position to go live with a beta, and we're commissioning this site from an agency so we can't launch then keep releasing new features. That pushes the boat out, but this spec is clearly well beyond the MVP even under our circumstances.

The risks are familiar:

• Less likely to have a complete release on time
• More likely to incur poorly controlled changes and change-request costs

If we reduce the scope to parts 1. and 2. we can deliver a really great site, using an agile approach, and consider further down the line whether the site needs these particular fancy features or if something else would work better.

Retaining parts 3. and 4. automatically means Big Design Up Front, with complex features planned before basic ones have even been delivered.

Who thinks this is a good idea?

In a word, clients. They still seem to think if they specify the solution up-front they can get exactly what they're asking for.

This is a slightly separate problem from their thinking they're in a good position to specify solutions. A client may well take my advice that "we can't offer you this (at acceptable cost / within the timescale / without breaking the laws of physics) but we can offer that instead". But either way they think we can and should promise something specific. Six months before we code it.

I think the problem's one of education. I've seen scads of books, seminars and websites extolling the virtues of agile, all aimed at technologists. I doubt anyone's ever even explained to my project stakeholder what the difference is, much less why one might be better than the other.

I guess I'd better start educating them!

And then there are the agencies...

True coincidence - the very same day I read this spec I bumped into a non-technical friend who had just been commissioning a new website for his charity. All specified up-front, waterfall all the way. I told him the agency are going to murder his budget on the change requests. He already knows their change-request charges are high.

We know there are some agencies who want to write valuable software well and who battle to educate their clients and exercise agile methodologies.

I'm sure there are many more who'd like to do so, but find it easier to sell work with a waterfall plan.

And I'm just as certain that there are plenty of black-hat agencies who strategically promote waterfall plans to their clients and extract high change costs. Frankly they give our professions a bad name.

Guy

Do It Right or Do It Right Now?

A question I face in software projects on almost a weekly basis: do we implement the feature Right or do we do it Right Now? Of course ideally we want to do it Right and now, but sometimes that's just not possible.

Case in point: we have a bug in a website that we deployed about a month ago. The bug is fairly serious, it's impacting the user experience and the stakeholders are quite rightly clamouring for a fix. On the other hand their critical date has passed - the bug has already done more damage in the last two weeks than it's likely to do in the next two.

We can fix it right now using a perfectly good proprietary solution or we can wait two weeks for a feature to be rolled out across the corporate web stack, enabling a more standard and simpler solution. There's no doubt that in an ideal world this is the better fix.

There are three ways we can go:

1. Do It Right
2. Do It Right Now
3. Do one now and the other later

On the first project I formally managed we did a lot of Option 3. We called it the Tactical solution and the Strategic solution. Now I have rather more experience, I wonder if I should have been more decisive.

I think the choice you make should come down to business value and risk:

• What is the additional value of doing it Right?
• What is the business cost of delaying to do it Right?
• Does either solution involve appreciably more risk than the other?
• What is the additional cost of doing the work twice?

Additional value of Doing It Right

There must be something that makes the Right solution Right. Is it more robust? Easier to support? A strategic enabler? In our case it moves a lot of the work and maintenance responsibility to another team and delivers a business-standard solution. That's a lot of Win.

If it doesn't deliver any value perhaps it's just an engineer's whim - hey I've been that engineer ;)
Do It Now!

Business cost of delay

Presumably there's some pressure to Do It Now and not later. In our case the bug is making some user interactions fail, alienating the users and probably doing reputational damage. Delaying another two weeks would be significant Fail.

No pressure and no cost? Then you're probably not even having this conversation - hold off and Do It Right!

Solution risks

In my example above there's a significant dependency risk in the Right solution. If I make that decision, I'm relying on another team to deliver in a timeframe that I have to commit to my stakeholders. On the other hand, there's also a small risk that the Now solution won't actually work...

Cost of Doing It Twice

There's a cost to doing anything, and double the cost in doing it twice. I don't care if your project doesn't have an explicit budget - while your team's doing the Tactical then the Strategic implementation they're not burning down your product backlog.

So..?

If the cost of the delay plus the value of doing it Right is greater than the cost of Doing It Twice, then maybe you want to go for both the Tactical ans Strategic solutions..

If not, then does the value of Right exceed the exceed the cost of delay? That should tell you which way to go.

And what have we decided? In the end the engineering team didn't deliver the proprietary solution before the new feature hit the corporate stack anyway.

Guy

ps.

I wrote almost all of this post a couple of months ago, when I planned to build my own website (previous post). That would have been Doing It Right, but the cost of delay just became too high. Posting on Blogspot is Doing It Right Now and I'm really pleased with that decision.

Will I Do It Twice?

Having my own site still has its attractions, and if it's worth it maybe I will. This blog may provide part of that answer...and I think that will form the basis of my next post

Damn - it's almost as if I planned this thing!

Why am I here?

Cause time's a-tickin'.

A few months ago I thought I had nothing to say on a blog. I started making a list and found it was surprisingly long. Plan A was to knock up a quick website. I wrote my first post, did some basic site design...and never managed to find a host for it.

Time's a-tickin' so here I am.

Does the internet need another blog about the internet? I don't know. If some people like what I have to say I'll really be quite flattered. And maybe one day I'll take this blog and put it on my own website.

Which segues nicely to that first post. Damn - it's almost as if I planned this thing!

OK let's see where we go!
Guy