Developing Software Together

A couple of days ago, I wrote the article Well Crafted Code Will Ship Faster. It contains some reasoning why well crafted code is also cheaper and faster, and some ideas what you can try next to get there (like, “first do things right, then do the right things”). This article sparked an interesting discussion on Twitter.

We should stop using misleading generalizations for concepts that exist on a scale. That's my point. Benjamin Reitzammer

I agree the science we have is crap but does that mean we should stop trying? Christoph Neuroth

At a conference, I was listening to a talk by a “famous” speaker. I was rather unimpressed - He was switching topics in a confusing way, and the talks also was a bit boring. But it was OK(ish).

But then he based one of his arguments on the Chaos report. Now, you know, I am really skeptical when someone uses the chaos report - especially data from before 2015 - to back up their arguments. Especially when they talk about agile software development.

This is the third article in the mini-series “Why Do We Need Those Estimates”. Never miss one of my articles: Readers of my newsletter get my articles before anybody else. Subscribe here!

The reasoning goes like this: “Our customer only hires us on fixed price. We need detailed estimates to calculate that price, so we can even enter the bidding process”. Of course, there are variations to this reasoning. But the bottom line always is: We need estimates for our customer.

In this article I first want to discuss fixed price projects, and then move on to other ways for running a project. Then we’ll look at how estimates fit into this picture, and what kinds of estimates are useful and what kinds are not.

Next year, I will co-organize a conference about IT management. It will take place at the Slovenian city of Piran, right at the mediterranean coast:

www.advanceit.io

This is the second article in the mini-series “Why Do We Need Those Estimates”. Never miss one of my articles: Readers of my newsletter get my articles before anybody else. Subscribe here!

One of the reasons teams and managers need estimates is to know how far they are in the project and when it will be finished. The reasoning is simple:

• We know how far we are by dividing total estimated time by total elapsed time.
• We know when we will be finished by adding up all the remaining estimates.

Never miss one of my articles: Readers of my newsletter get my articles before anybody else. Subscribe here!

I have worked with several clients who do detailed, task-level estimates (in hours). Or at least detailed story-level estimates (in Story Points or Person Days). And for most of them, their process seemed to work fine. From their point of view. But I always had the feeling that they didn’t realize their full potential. That there was some waste in their process. Of course, I also told them. They hired me as a consultant, after all.

Their answer (most of the time): “But we need those estimates!”

This, of course, begs the question…

Never miss one of my articles: Readers of my newsletter get my articles before anyone else. Subscribe here!

I have seen some implementations of agile software development and heard about several others that faced major difficulties. Difficulties that shouldn’t exist in an agile project - Or that was what I thought. Then I re-read the Scrum guide, and the “three pillars” caught my particular attention.

Never miss one of my articles: Readers of my newsletter get my articles before anybody else. Subscribe here!

Lately I have been writing a lot about Estimates and #NoEstimates. I am not particularily for or against estimates and estimating - I think they are a tool that can be used well or badly. I just got interested in #NoEstimates because of some things I have experienced in the last few years while consulting clients.

Here are some things I have seen regarding estimates and estimation:

Never miss one of my articles: Readers of my newsletter get my articles before anybody else. Subscribe here!

I am still thinking about estimates and #NoEstimates, and I am still writing my findings down here. In the last article, “A Spectrum Of Effort Estimates”, I wrote about different ways of estimating software development effort. Today, I want to explore what an estimate really is.

Never miss one of my articles: Readers of my newsletter get my articles before anybody else. Subscribe here!

In the last post, I wrote about how you can get started with #NoEstimates when you use story points right now. Today I want to write about different kinds of estimates. [You might be also interested in: What is An Estimate, Anyway?]

There are different techniques to come up with an effort estimate, and the estimates themselves are different. We can classify these techniques and estimates along a spectrum with different axis: