The notion of transparency is very important in agile methods like Scrum (but not only there). It’s a way of being (being transparent) that should be applied in all cases (Agile, CMMI, whatever, even in projects without a method). In Scrum, the notion of transparency is associated with that of courage it seems to me, implied: who would want to go confront a client to announce very bad news, or who wants to take the risk of admitting that they failed, etc., it’s never simple but it’s essential.

The word courage is quite telling, it must be associated in our case with maturity, experience. In my opinion, the courage of transparency comes with the years, with experience. But here there’s no question of morality contrary to what transparency might imply when we associate it with honesty, but just economic realism, in short when one works in the private sector: maturity! Indeed, and this is why I insist on the fact that this is not exclusively linked to agile projects, the fact of not being transparent with one’s client will systematically result in a loss of productivity and efficiency. The sooner an anomaly is detected, the sooner it must be dealt with, the sooner a misunderstanding arises, the sooner it must be cleared up. Everything we deliberately leave along the way (opaque) will necessarily be found on our path later, and will have to be dealt with at higher costs without a doubt. This is why I speak of productivity and efficiency through transparency. It’s a notion revealed by agile methods because they force us -through constant iteration and frequent exposure of results- to be transparent.

Am I clear? :)

I’m actually bouncing off a comment made today here.