Monthly Archives: May 2008

Project Uncertainty PrincipleThis came to my mind when I was watching this lecture, given by Ricardo Semler at the MIT Sloan School of Management, in 2005.

At some point in the lecture, Ricardo talks about intuition, and how intuition is very useful to solve problems, but still is not accepted in the corporate world.

In his words, talking about the chess match between Kasparov and Deep Blue:

How is it possible, at all, for something with 4 moves (Kasparov) to play something with 4.000.000 moves (Deep Blue)?

…. There is only one thing that he has that the machine has not, and that  is intuition.

…. Where are we putting intuition to play in the corporate world?

And this thought stayed in my head. Why the majority of people find it so difficult to accept intuition and to deal with uncertainty? In Ricardo’s words, why are we willing to trick ourselves and everybody else into thinking that we have control?

And why is this topic relevant to software development?

Because that’s one of the reasons that make agile methods so difficult to be accepted. Most people are not prepared to accept that the project duration can’t be precisely measured. Or that the scope should be flexible, because we still don’t know (oh my God!) what is important and what isn’t. And that the decisions we make should not be based on a complex function point calculation, but in simply in the team’s intuition?

Instead, they prefer to develop software in ways that have failed for many and many years, but still thinking on having control over all the project. They find easier to believe in an excel-calculated estimate for the total project of 170.1234hs than in an estimate that says “roughly 1 month”, and they hope to deliver software within fixed budget, size, scope and quality (good luck with that).

As Ricardo cited, it doesn’t matter if you are wrong, but you have to be precisely wrong.


This topic comes from some discussions that went on in a mailing list I participate, and also between me and my flatmate, about how productivity should be measured in agile projects, and how is it related to capacity.

I wanted to write this post for some time right now, but today I’ve realized that somebody had already written about it, so I decided to give my opinion too :-).

I totally agree with Simon when he says that velocity is not productivity. As I mentioned in another post, one should be very careful when applying any measure, specially productivity measures, and capacity isn’t one of them, in my opinion.

One simple example that makes me reach this conclusion is bug fixing. If you consider capacity = productivity, how should you count bug fixing stories? They are certainly not adding business value, they are actually delivering business value that was supposedly already delivered, but you can’t deny that the team spent time fixing bugs, and that these points should be considered in the estimation and also in the team’s velocity.

Simon also wrote about how to measure productivity, or even better, how to say if a team is performing well. In his post, he wrote

I prefer to measure productivity in terms of the goal and getting stories done is not the goal, generating revenue is. Getting stories done is the means to achieve the goal.

Productivity is perhaps better represented by the revenue generated per iteration per unit of story estimation, e.g. £10,000 per ideal pair day.

This topic was also covered by Martin Fowler in this post. As Martin said,

So maybe you can’t measure the productivity of a team until a few years after a release of the software they were building.

Despite understanding what both says, I find kind of difficult to specify the performance of a software development team if you link it to the revenue generated by the project. I agree that in order to obtain the best results, the considered system should be as broader as it can be (as Deming proposed).

But I also believe (along with Goldratt) that a team has to have a goal, and this goal should be very carefully considered, since it will drive all team’s actions when they are developing software. Including the client’s business in this equation makes it too complicated, since you don’t have any control in how the client is using your work to generate revenue, and as Martin said, it could take years in order to obtain a good result.

If a team doesn’t have a goal, how could it pursue its objectives? Which are the objectives? If agile is about constant and rapid feedback, should I receive feedback based on which criteria? What should the team try to improve when performing retrospectives?

In my opinion, if you have a client that is specifying which stories are more important to the project, and that is why it is really important to bring the client inside the project, at this moment should the measure end, on stories accepted, which will deliver business value (but might not, if for some business reason the software isn’t used anymore, for example).

Until this point a team has the conditions to change and adapt itself to get better results, and deliver more business value. After it, not anymore.



Get every new post delivered to your Inbox.

Join 836 other followers