When Agile Estimation becomes pointless

If a team has to deliver a certain amount of functionality by a certain date, then the act of estimation becomes an act of commitment. The team has essentially committed to cost, schedule, quality and scope. There are no levers left. In such a situation, velocity becomes a target rather than just a measurement. Targeting velocity makes points based estimation a charade. The team is better off estimating in real days in this case. It helps the cause of commitment. Points based estimation is useful when you agree to the following:

1. Plan the story list for a release with only about 70% must-have functionality and the rest as negotiable. This implies it is potentially okay to release (go into production) with just that 70% functionality.
2. By definition, estimates are approximations. Software estimates are more so.
3. It is counterproductive to insist that your IT vendor/team deliver x points of functionality by date y. Scope negotiation does not mean x remains x. Yes, sometimes only the contents of x need change. At other times, x may become x ± delta. This is not a rip-off. It doesn't make business sense for your IT vendor to rip you off because you won't give repeat business if you are ripped off. Without repeat business, your IT vendor is likely to become uncompetitive because the cost of new business development is very high.

"Embrace change" is a two way street. IT delivery team should embrace changes to requirements and priorities. Clients should also embrace changes to scope when delivery work proceeds at a different pace than originally expected.

The Tragedy of Commons based Peer Production

In my previous post, I mentioned how authors of small but useful open source projects often struggle for compensation. Using a FOSS/commercial license is one option but it could go either way. They wouldn't really have to resort to compulsory payment if donations were forthcoming from users/organizations who commercially benefit from it. Therein lies the tragedy of 'Commons based Peer Production'. Only a tiny minority donate. This is detrimental to the growth of all forms of free digitial distribution (indy music, books, software etc). It also makes for an unhealthy society. Big leap? Bear with me.

The bulk of financial transactions in G20 economies happen between:

1. Corporations (B2B)
2. Corporation and citizen (retail - citizens pays corporation, wages - corporation pays citizen)
3. Corporation and state (taxes - corporation pays state, state funded projects - state pays corporation)
4. Citizen and state (taxes - citizen pays state, pension/welfare - state pays citizen)

But what about transactions between citizens? When this goes towards zero, we get a unhealthy society. Centralized services, mostly helpless consumers (citizens). Donating money to the creators of 'digital stuff' that we enjoy is a great way of changing the status quo. The internet has provided a great platform for disintermediation but it will only work if we choose to participate in the process.

We could also try to build momentum within our organizations towards this. Companies that commercially benefit (however indirectly) from free software could set aside some money annually for donations. The beneficiaries could be decided by a poll within the company. After all, this is also part of CSR. Plus it will make for good PR copy.

Open Source authors' struggle for compensation

I guess we all know the difference between free as in speech (freedom) and free as in lunch (gratis). All open source software confer certain freedoms of use, modification and redistribution. None of them are required to be made available to users at zero cost. Yet, I don't know of a single significant project that is open source and fully paid, i.e. no version available at zero cost. Reasons typically offered are:

1. It is the freemium business model - Give away the basic software and charge for enhanced functionality or support.
2. It is not enforceable - Users will simply build the software from the source code and there is no way you can get them to pay.

#1 is okay for projects run by companies. It is often not feasible for projects run by individuals. This a big category of small useful pieces of software (think libaries, plugins, utilities). These people try (in vain?) to make some money via advertisements or by appealing for donations. It is a sad reality that they get no compensation from commercial software/organizations using their work. These people should relook at #2.


I suspect payment is very enforcable against commercial enterprises. Just add a line to your EULA saying "It is illegal to use this software for commercial purposes without paying for it". Most companies would pay a small fee (say $50 for a full version but without support) for a useful piece of software. Either that or their lawyers would blacklist the software. At least you wouldn't have legions of freeloaders just using the software without contributing anything (money, bug reports/fixes, documentation) back. The argument that even freeloaders help spread the word to someone who might eventually buy something is a trifle bleak. Of course, all power to you if are doing this altruistically or if you are happy with the other rewards (fun, learning, reputation).

Giving software away at zero cost means you have to depend on services for income. You either offer your services as an employee (day job) or as support (adding value to what is given away). Either way, it is a model of pricing input instead of output. Scales only with people. Or you have to fall into a category where you can be adopted by a big foundation like Eclipse or Apache or Mozilla.  Good luck with that.