Software Developers are NOT Special

As I was going through Twitterland, I heard this strange sound:

“Coders are special. We are expected to know how to do things we've never done before and estimate how long they will take."

Well, yes and no. The part about estimating how long it will take is definitely true. See, there’s someone paying for your efforts, let’s call him the customer. The customer wants to know when he gets something for his money.

Haven’t done this before?  Maybe the customer hired the wrong gal or guy. Maybe he should have gone with someone who HAS done this before.

Or maybe you’re one of the very special group of people working on actual new technology, most developers aren’t. Statistically, I’m sorry, but you’re not.

For every one, in every profession, there are new tasks to do, or tasks that contain new elements in them. We never do everything exactly the same, because even if we try to control everything, there’s going to be a traffic jam, a communication meltdown, or a small war. There’s always risk involved and that affects our estimations. We still need to give them, though

Developers have hard time estimating as the next guy. There are ways to minimize risks, but eventually, we need to give a due date, because this date means money going somewhere, and the wallet needs to know when and how much.

Sorry to break the illusion. Coders are not special.

Upcoming Presentations: Florida First!

Here’s a short, incomplete list of my upcoming public speaking engagements. When I know, you’ll know.

I’ll be speaking at the Agile Development Practices East Conference on Wednesday November 9th, at the Rosen Centre Hotel, Orlando, Florida. My talk is about “8 Principles for Better Unit Testing”. I’ll be at the conference area throughout Wednesday and Thursday, so if you’re there, come say hi.




Two days before that, November 7th, I’ll be at the Deerfield Beach user group meeting (part of Florida.Net) where I’ll do my “10 Secret unit testing tips” and do a group code kata. They call it a Deerfield Beach Special Edition, and I hope it will be special indeed.

Looking a bit far into the future, I’ll be speaking at the Agile Practitioners 2012 in Israel, on January 31st next year. The topic is not closed yet, so stay tuned and get ready for a surprise.

In the meantime, I’m doing a webinar each month at Typemock. Next week, Wednesday October 26th, I’m doing the  long-named “The Step by Step Guide to Building Effective Agile Development Processes”, so if you haven’t yet, register now!

For more of me, check out slides and recordings at the Events and Webinars page. And if you want to hear and meet me closer to where you live, invite me!

The Agile Time Lords

InfoQ had a round-up of ideas about “How Long Would it Take to Build the Product?”. It was funny (ha-ha funny) to read some of the responses. One person suggested that upfront estimations end up in a fixed scope, which is anti-agile. If I was new to agile, I would read it this way: if you’re REALLY agile, estimations are not for you.

Well, that’s a great way to set up expectations for the new agilist. If you want to pick up the pieces later, that is.

It seems that developers don’t really need estimations. They can work without any planning or time limit (not effectively or efficiently, but they can). True time lords.

But estimations are a tool for the project sponsors. The ones who pay for the project. They want to know when they’ll have something to show for their investment.

If there’s no agile experience in the organization, when the sponsors ask:“when will it be read?y”, they know that they’ll get a date, to which they’ll need to add 6 months, and that at the end they’ll need more testers. It’s painful, but they learned from history, and this gives our poor sponsors some kind of predictability in their life.

If there are already agile projects in the organizations, the sponsors already know that it’s not about fixed scope and date. They’ll get what they can by that date. Sure, they’ll always want more, but they learned to live like that. That’s another way to have predictability in their uncertain life.

But if the organization is in transition to agile, the sponsors are very touchy about these things. They are looking for some predictability, and the last thing they want to hear is: We’re agile now, we don’t give estimates.

Wrong answer.

Forget about pure agile, and give your sponsor confidence this new way of developing software can actually work. That his trusted developers are not some inmates taking over the asylum.

Estimations are a way to introduce predictability and trust to all the project stakeholders. It allows the organization to plan ahead, know when the team needs more people, or to transfer people to other teams, to raise money or just put a date on the calendar when the marketing team can start promoting the new product. It’s not much, but way better than the black hole of uncertainty.

Remember: Agile is about collaboration. And not jut with the customer, also with your boss.

Related Posts Plugin for WordPress, Blogger...
Twitter Delicious Facebook Digg Stumbleupon More