Monday, 7 July 2008

A few more words on agility.

I wrote in a post not long ago about the importance of staying agile in your development process, and I thought I'd elaborate a little further. I'm now involved in a project which is getting close to entering the development phase, and the last few weeks have highlighted to me where we go wrong and why we go wrong so often when we've got a good idea for software.

The potential scope of the project I'm working on now is huge. The idea itself is nothing new (I can't go into it here for obvious reasons) but the setting and the "take" on the idea is new, and probably better than what the competition has come up with. The guy that came up with the idea (my boss, let's call him M) soon realized that there is real money to be made in an emerging market, and he's received funding from the company board to set up a new department and get the project off the ground. Everybody is really excited about what's about to happen and everyone is "behind" the idea.

All of that is really good and nobody's complaining. However, all this excitement lead to some problems right from the start. M's idea grew rapidly. Scope creep, anyone? More like scope avalanche/flood/torrent (choose your own appropriate natural disaster analogy). And everyone was still just as excited. Except me, probably. Part of my excitement started turning to fear. I saw that if this thing was allowed to take its natural course, we'd crash and burn. Because, quicker than you can say "Waterfall methodology" M (with my help) had mapped out a system so large and so complex that it simply wouldn't be possible to deliver it on time. It probably couldn't be developed in twice the allocated time. And when I pointed out the fact, things got really scary for a while.

M was incredibly keen on "doing something" (I admire this man's energy and passion for his work, I really do). The business leaders thought the idea was brilliant and wanted it to happen, and happen now (heard that one before?). And the fact that there was too much work and not enough time could easily be overcome. The company makes good money these days, so we could have more allocated to our budget.

More money equals more developers equals more lines of code in a day equals faster delivery. Right? I don't think so. In fact, I know it doesn't work that way. And that's what I had to make M and the others see. Before _anything_ had been produced, the company was - potentially - ready to fork out huge amounts of money to back up a project that had done nothing to prove itself except look good on paper. So I put the brakes on. I spoke with M and expressed my concerns. I told him I thought it is incredibly risky to assume that we know everything about what our customers want and develop something so huge purely on a hunch. I told him we should keep the original deadline and pull back the scope so that we could hit the deadline safely. I told him we should limit the available resource and do as much as possible within the constraints of the original budget and resources available. I asked him to read 37Signals' "Getting Real".

And guess what? M skimmed through "Getting Real" and he got it. He understood the point of what I was saying. And so he slowed down.

But the business didn't. They encouraged us to "think big". So we did. In a four day exercise we thought real big and put together numbers and estimates for what it would cost to deliver M's idea, scope creep and all, by the original deadline. And the cost came in at about ten times the budget for the first year. That kind of drove it home: It's a risky and really costly approach.

It's a risky approach because there are too many assumptions, and the main assumption is that we know what the customer wants. In a new project such as this one, where everything hinges on the customer, you should assume as little as possible and instead listen to what your customers want. Launch with as little effort as possible and be ready to change when your customers demand it. That way you'll have a project that can grow and adapt and be successful because it deserves to be - not because it had amazing funding.

So now we're starting small. Thankfully. And guess what? The first deliverable isn't even going to be an in-house development. We're looking at some third party solutions to launch part of the product and build the rest around that third party solution. That way we can build the product in bits and pieces and work it up as required while the out-of-the box solution we purchase takes care of our first deliverable.

So the project is turning back to a more agile approach, and thank God for that. What these weeks have highlighted to me is that there is a very real and very palpable risk of getting carried away when you're working on something new and exciting. It's easy to forget to stop and evaluate what you're doing. And when enough people get excited about the same thing, crowd control becomes difficult. We must remind ourselves that the _idea_ is only the starting point, and in the end it is really the execution that matters.

What happened in the first few weeks of this project is that there was too much focus on the idea and not enough focus on the reality surrounding its execution. Hopefully we've adjusted that balance now, but I'm sure there will interesting times ahead because "speaking agile" and "doing agile" are two quite different things. And I'm sure I'll be writing more about it here.

No comments: