Forgive me reader, for I have sinned. It’s been some time since I last posted to this site.

I haven’t stopped writing, but instead have been trying to ’seed’ my new site with content. There’s only so many words in my head at any one time! Anyway, it’s now ready to be revealed to the world.

A year and a half ago I was promoted into management at the company I work for. And then I was left to work it out for myself. Thrown in the deep end.

I’m a resourceful kind of guy so I managed to find many resources to help me become the best manager I could. The more I studied the topic, the more I wanted to have my say on it too. I wanted especially to talk about people management (leadership) from the ‘vertical’ slice of Software Development. That’s what I’ve done as a career for many years, and it’s who I’m now leading. So, without further ado, I present http://geek-herding.com

While this blog will continue, I’m going to be restricting it to thinks that aren’t work related as I want to really push Geek Herding.

I’m interested in your feedback, though if you’re not in the software development industry, or interested in leadership and people management, it might be a little bit boring.

On the other hand, if you’re interested in either topic, I’d love it if you:

• Read the articles
• Commented on the articles
• Promoted the articles (if you’re tweeting, please use #geekherding so I find the tweet!)

Even better, I’m going to be looking for Guest Bloggers soon, so have a think if you have anything you might have to say on the topic.

Marketing: I have an idea for a new product, how long will it take to build?

Developer: We’d need a more complete spec.

Marketing: OK, but just putting your finger in the air ..

Developer: Maybe two weeks, so call it four.

January 23, in the customer newsletter:

Marketing: Our new product will be released on Feb 28th! Huzzah!

Sound familiar? I’m sure this happens again and again in software development companies the world over. I’ve certainly experienced it many times.

The problem, of course, is made up of many issues. Here’s three obvious issues:

1. Marketing just have an idea for a product. There’s no detailed spec. There’s no screens, no functional spec. yet they expect an estimate.
2. The developer provided an estimate without qualification
3. Despite a long history of ‘bad’ estimates from developers, marketing believed the estimate and passed it on to customers.

And here’s two more not-so-obvious, but very real issues:

1. The estimate give by the developer is given in isolation. Even if accurate, it totally ignores existing workload.
2. A new product (or feature or enhancement) isn’t just about writing code.

Fixing the problem

Let’s break the problem down into the listed issues and explore each of them.

No detailed spec.

When there’s an idea mooted, a lot needs to be considered before going to market. But if you were to write a detailed spec for everything  –  including mockups for every screen and functional detail for every action — without discussing the basic concept with every stake holder, you’d often waste a lot of time.

So the normal practice is to discuss the idea with each stake-holder to get a basic understanding of the project.

Imagine you rang someone to build you a pergola and you had not measured the size you wanted or considered any of the details like materials. Before you go ahead and research all that detail, you need to know if the project is even feasible. So you ring a random builder. What’s the best way to get an estimate without tying each other down to price? I like to call it the zeroes method. ie, “how many zeroes”?  Will it cost two-zeroes? $0 to $99? Or three? $100 to $999? Four? Five?

For development, I think the best question (at this stage) is what time-unit are we looking at? Is it days? Weeks? Months or Years?

The developer gave an estimate without qualification

OK, so it’s what was asked of him. And we do like to please. At first the developer doesn’t want to give an estimate. After all, he hasn’t seen the full scope. But then he figures that marketing aren’t dumb, they know that without a full scope there’s no way the estimate can be anywhere near accurate. So he caves in and thinks about the product.

The developer’s initial thought is ‘2 weeks’. But he’s aware that things never go as planned and so ups that to a month. (Note that he’s switched units .. when you hear that happen, it’s a good sign that the estimate is just a guestimate)

At this point the developer should have said: I cannot give you any reasonable estimate that will assist with product planning without a full spec.. But I understand that you don’t want to spend the time writing a full spec if the development time isn’t feasible. From what you’ve told me *thus far*, we would be looking at weeks rather than months. That said, I’d be happy to give you a proper estimate once the full spec is clarified.

Marketing believed the estimate

This is probably the biggest mistake in this scenario. Marketing always want estimates. Developers give estimates. Development always takes longer.

There’s a two-fold problem here:

First, marketing treated the estimate as an actual estimate rather than as a finger-in-the-air estimate based on a totally inadequate solution description.

Second, they compound this mistake by believing the number. The developer knows that estimates are always wildly optimistic, so he says “Maybe two weeks, so make it four”. But marketing should, by now, also know that anything the developer says is wildly optimistic and say to themselves “It’s always under, so let’s make it 8″.

Once both parties have over-estimated, we now have enough information to write a full spec but not enough to to to market.

* * *

Now, let’s consider those other two issues that compound the problem. These two issues exist even when the developer is making an educated estimate based on a fully delivered spec.

The estimate is given in isolation

When a developer is asked how long something will take to write, even if he has every bit of information he needs, the answer will be given in man-time, not clock-time. This means that a four-week development job will take four man-weeks. Or 20 developer-days if you prefer.

An estimate of four weeks only means “in four weeks time” when:

• he is sitting around waiting for the next project to start
• the previous project has no outstanding bugs that will need fixing
• he doesn’t need to provide assistance to customer service
• he doesn’t have meetings with his manager or team or company
• he doesn’t need to help the boss set up his new laptop
• his brain isn’t also worrying over the global financial crisis
• there are no public holidays and he has no annual leave booked
• he doesn’t get sick
• … and probably another thousand or so caveats.

When marketing is given an estimate from a developer, they need to consider scheduling as well as the actual estimate. They need to consider that the estimate is in man-days rather than calendar days.

A new product isn’t just code

This issue has nothing to do with the developer, but has everything to do with communication between marketing and the product owner (or whatever your company calls the person who manages the entire product).

If a developer estimates (once given a full spec) four weeks and the scheduler says it will start in two weeks and the developer will have around 80% of his time to give to the project, then the estimated date for completion of development is in 7 weeks time.

But that isn’t a go-to-market date. That is the date at which the documentation team can start to prepare the new user manuals. It’s the date that customer service can begin to learn how to support the product. It’s the date that user acceptance testing can begin. It’s the date from which the accounts team can get their billing systems ready. It’s certainly not the date that the product is going live.

In order to estimate the go-to-market date, every one of these (and many other) tasks need to be similarly spec’d and estimated. Will user-acceptance testing take two weeks? What if there’s serious usability problems? Does the acconts department need the developers to do some extra coding in order to be able to properly bill the service? If there’s any changes to the service after UAT, what does that mean for documentation.

So, given all that, why is only the development team expected to estimate the time to build before there’s any sort of spec? And even after there’s a spec, why isn’t anyone else expected to talk about time estimates?

Wrapping it all up

Before there’s a complete spec, any estimates are finger-in-the-air. This should never be assumed, both parties need to agree on this every time:

“I’ll give you a finger-in-the-air estimate, but I need you to understand that it is no way binding or anywhere near accurate”

Give finger-in-the-air estimates as a time unit:

“Weeks rather than months”

If there must be a number, over estimate until you have every bit of detail — on both ends:

“I think two weeks, so I’ll say four”

“He said four, so I’ll think eight”

Agree that once there is a full spec, a tighter estimate will be given, but that it is given in isolation:

“Now I have the full spec, I’ve mapped it out to take about 12 weeks to write the code. However this is 12 weeks in isolation. Experience shows that between everything else that happens, I get the equivilent of 60% of my time I can dedicate to a single project, therefore you should expect the project to go to UAT in 20 weeks.”

Acknowledge over and over again that development isn’t the only part of the project:

“While I’m happy to give you this estimate based on the full spec, we need to agree that after I’ve finished writing it there will be an undefined amount of time required to do user acceptance testing as well as sales, support and accounts product training and anything else that needs to happen before the product goes to market.”

If I haven’t made it clear already: Never assume the other party is thinking about things in a complete and rational manner. Even if you’re “just a developer”, make a list of things that need to happen after you’ve finished, before the product is released, and ask how preparation is going for each of them. You’ll earn a lot of kudos for knowing to think about these external things as well as possibly saving yourself (and the company) a lot of grief.

Time has passed and now high-fiving is the norm. It’s a great way of saying “well done” or “I agree”.

There’s also developed a guerrilla version where someone says “High Five!” and just as you’re about to make contact they yell something like “Telstra rules!”  It’s too late. You’re committed. You find yourself ‘agreeing’ to the absurd statement.

I now think that there’s not enough high-fiving in the world. High-fives cheer you up and make you feel good.

Obviously Improv Everywhere felt the same so they headed down to the escalators at a New York subway station to hand out high-fives to everyone.

You can read and see more of their high-five campaign over at the improv everywhere blog.