Today I heard interesting thing. Our deadline for committing to plan for next year was moved to later, some time in the middle of June instead of being as planned. "I hope it will help us to get better estimates" we were told (this was my interpretation, the original was probably a bit different).

I was quiet as I would not be able to change that decision in any way. Still I wonder how giving us 2 or 3 weeks more will improve our ability to estimate 12 following months. Why management feels better to guess what 20 people can do in 12 months than estimating only 1-2 months, performing planned tasks and then checking where we got.

But that is not the reason for this post. It reminded me important information I have found in Implementing Lean Software Development: From Concept to Cash some time ago.

Goldratt believes that the key constraint of projects - he considers the product development to be a project - is created when estimates are regarded as commitments. [...] Since the estimate will be regarded as a commitment, the estimator accommodates by including a large amount of a "safety" in case things go wrong. However, even if things go well, the estimated time will be used up anyway, since estimators don't want to look like they over-estimated.

and bit later in the same chapter:

In fact, if half of the activities don't take longer than their estimated time, the system will not achieve the desired improvement.

This is that important bit of information - when all tasks are achieved in estimated time we cannot be sure we did not waste time. But when some of them (ideally 50%) take longer than estimated time then one of the possible reasons could be that our estimates are very close to minimal time needed, thus waste is minimized.

A few hours ago I have signed http://manifesto.softwarecraftsmanship.org/. Looking back at it I really do not understand why it took me whole day to decide so - it is no-brainer for anybody who takes his work seriously.

I am the 978th. There are 1012 signers at this moment and growing faster than I can check it is still valid number.

I found following sentences regarding quality in Art of Agile Development while commuting to work this morning.

The best way I know to reduce the cost of writing software is to improve the internal quality of its code and design. I've never seen high quality on a well-managed project fail to repay its investment. It always reduces the cost of development in the short term as well as in the long term. On a successful XP project, there's an amazing feeling - the feeling of being absolutely safe to change absolutely anything without worry.

I wish more people were aware of this and acted accordingly. I have to make sure this happens at least at my present and future jobs.

Continuing reading The Art of Agile Development I have found another gem for me. (Well, there were more, what I mean here something I can relate to my past experience).

Project I had been working a year ago in my former company went very well. We were using Scrum (or what we believed is very good approximation of Scrum in our environment) and I was proud that our team is delivering a lot features with rather stable velocity.

But then reading this book I have found following:

On the other hand, if your velocity is rock solid, try reducing slack by committing to a small extra story next iteration.

Of course, it makes a lot of sense. How could we know that we are using our time effectively if we did not try to finish a bit more? If we tried to commit to a bit more work we could either finish it all or our velocity would stay approximately at the same level. Small fluctuations of velocity is not big problem, but having stable velocity is probably suspicious.

I am currently reading The Art of Agile Development that I've bought at Javapolis last year, but I did not get to it sooner.

I am close to middle of it and I am sure it is the best book I have read about agile development, because it says what, why, how, when not and alternatives (if they exist).

What inspired this post was reading chapter No Bugs. I could not stop thinking about it and I have shown it to all colleagues in my team. It contains something that should cause envy among the most of programmers.

However, XP teams can achieve dramatically lower bug rates. [Van Schooenderwoert]'s team averaged one and a half bugs per month in a very difficult domain. In an independent analysis of a company practicing a variant of XP, QSM Associates reported an average reduction from 2,270 defects to 381 defects [Mah].

and later on

For example, [Van Schooenderwoert] delivered 21 bugs to customers. Working from Capers Jones' data, Van Schooenderwoert says that a "best in class" team building their software would have generated 460 defects, found 95 percent of them, and delivered 23 to their customer. In contrast, Van Schooenderwoert's team generated 51 defects, found 59 percent of them, and delivered 21 to their customer. At 0.22 defects per function point, this result far exceeds Capers Jones' best-in-class expectation of two defects per function point.

It is very hard to imagine something like that even I think projects I've been working for last few years were better than average regarding bug count (I have no data to prove that to you or even me, it is just feeling).