The Hyped

The next category includes ideas that may have value but are unlikely to make a significant difference in matters that count: productivity of the software process and quality of software products. Under this heading we may include:

- Pair programming, hyped beyond reason. As a practice to be applied occasionally, pair programming is a useful addition to the programming team's bag of tricks. But there is no credible evidence that it provides major improvements to the programming process or that it is better than classical techniques such as code reviews, and no reason to impose it as the sole mode of development.

- Open-space working arrangements. There is no single formula for the layout of a working environment. What we do know is that it is essential to provide simple, obvious opportunities for informal communication. Beyond that, many office setups are possible which will not endanger a team's success. (A related point appears, however, under the "good" ideas of the next section: avoiding distributed development.)

- Self-organizing teams. A few teams are competent and experienced enough to man-age themselves, like a conductor-less orchestra. Most are not. Each situation calls for its own organizational solutions and there is no reason to impose a single scheme on the entire industry.

- Working at a sustainable pace. All great advice; death marches are not a good management practice. But advice can only be wishful here; these matters are determined by economic and organizational pressures more than by good intentions. They are not specific to the programming world: like a company that is responding to a Request For Proposals, a researcher who is facing a conference submission deadline will work through the night to meet it. The most software methodologists can do is to argue that such practices should remain the exception.

- Producing minimal functionality. It is always a good habit to question whether pro-posed features are really needed. But usually they get introduced for a reason: some important customer wants them. It is easy to rail against bloat or heap scorn on monster software (Microsoft Word and Adobe Acrobat are common targets), but try to remove any functionality and brace for the screams of the outraged users.

- Planning game, planning poker. These are interesting techniques to help estimate in advance the cost and time of development activities, but they cannot be a substitute for more scientific approaches. In particular, they are open to the danger of intimidation by the crowd; the voice of the expert risks being smothered by the chorus of novices.

- Members and observers. In project meetings, the views of the people most seriously involved matter most. This trivial observation does not deserve the amount of attention that the agile canon devotes to the distinction between "pigs" and "chickens".

- Collective code ownership. The policy governing who is permitted to change various parts of the code is a delicate decision for each project; it depends on the nature of the team and many other considerations. It is pointless to prescribe a universal solution.

- Cross-functional teams. It is a good idea to encourage developers to gain broad competence and to avoid dividing the projects into narrow kingdoms of expertise each under the control of one person. Beyond this general advice, there is little a method can change here to the obvious observation that special areas require special skills. If one of your developers is a database expert and another is a concurrency expert, you will not ask the first, if you have a choice, to resolve a tricky deadlock issue, or the second to optimize queries. This observation is another reason why the agile scheduling policy of picking the highest-business-value task in the pipeline is simplistic and potentially harmful.

Taken from : Agile!: The Good, the Hype and the Ugly