Lots of conventionally-managed software projects do not include reliable execution by deadline, or are on budget, or to all features of the specification; it’s a rare `managed’ project that meets even one of these goals, let alone all three. Those projects do not appear to be market conform when it comes to cost, and those projects misses most of the time the ability to adapt to changes in technology and economic context during the project lifetime, either; the open-source community has proven far more effective on that score.
I was wondering if James Dobson statements could be backed up with our Gridshore thinking which is based upon the Open-Source community process and it can in my opinion.
Lets sharpen the saw by reacting on this post.
1) Agile and Discipline
Open Source projects are despite to the fact that they are executed anywhere, anytime, anyplace in its nature Agile but above all more Disciplined I ever saw at non Open-Source projects. When it comes to CMM level 2 and 3 KPAÂ?s like tracking & oversight, Requirements management, Configuration management, Quality Assurance, Peer reviews, etc. they cannot be beaten. While conventional projects are desperately looking for tools and guidelines to become more mature the open-source community already have those for years (SourceForge, CollabNet).
How is this possible? Linus Thorvald, who had successful positioned himself as the gatekeeper of a project in which the development is mostly done by others, and nurturing interest in the project until it became self-sustaining, has shown an acute grasp of the Â?principle of shared understanding”. This resulted in a severe effort of many converging wills. The Â?principle of command” is effectively impossible to apply among volunteers. To operate and compete effectively, volunteers who want to lead collaborative projects have to learn how to recruit and energize effective communities of interest according to the Â?principle of understanding”. This leads to the second point of James.
2) Bottom up Organizational Change
An often-heard way is that traditional development management is a necessary compensation for poorly motivated project members who would not otherwise turn out good work.
The key is to work with, not against, human behaviour Â? Steven Covey
Human beings generally take pleasure in a task when it falls in a sort of optimal-challenge zone; not so easy as to be boring, not too hard to achieve. Another important aspect are the colleagues they going to work with (great people are looking for great people) and last but not least the believe in success. A happy person is one who is neither underutilized nor weighed down with ill-formulated goals and stressful process friction. Enjoyment and ambition predicts efficiency.
The moment there is open-source competition for a `boring’ piece of software, customers are going to know that it was finally tackled by someone who chose that problem to solve because of a fascination with the problem itselfÂ?which, in software as in other kinds of creative work, is a far more effective motivator than money alone.
Feel the power of team work :
A drop of water easily gets dried, a pool of water hardly gets dried Â? Eric Raymond
Having a conventional management structure solely in order to motivate, then it is probably good tactics but bad strategy; a short-term win, but in the longer term a surer loss.
Many people would expect a culture of self-directed egoists to be fragmented, territorial, wasteful, secretive, and hostile. But this expectation is clearly falsified by (to give just one example) the stunning variety, quality, and depth of Linux documentation. It is a given that programmers hate documenting; how is it, then, that Linux programmers generate so much documentation?
3) Wisdom of crowds versus individuals
It’s doubly important that open-source projects organize themselves for maximum productivity ) by self-selectionÂ?and the social milieu selects ruthlessly for competence. It is a belief that open source has been successful partly because its culture only accepts the most talented 5%-10% or so of the programming population.
ItÂ?s not the technology that makes the difference but the people you work with. Of course great colleagues and willingness to learn is not enough.
Â?We are not short on practices, we are short on practiceÂ?
ItÂ?s my belief that this will have positive effect on both employee satisfaction as on the effectiveness. The success of the open-source community sharpens this question considerably, by providing hard evidence that it is often cheaper and more effective to recruit self-selected volunteers from the Internet than it is to manage buildings full of people who would rather be doing something else.
4) Reinforcing positive loops whilst trying to break negative loops
The strongest argument the open-source community has is that decentralized peer review trumps all the conventional methods for trying to ensure that details don’t get slipped and deadlines are kept.
The most important input for a production process is knowledge – Toyota
The strength of the open-source community is that a lot of reviewers and beta-testers are good programmers too. Because source code is available, they can be effective programmers. This can be tremendously useful for shortening debugging time. Given a bit of encouragement, reviewers and beta-testers will diagnose problems, suggest fixes, and help improve the code far more quickly than you could unaided.