What are the development practices that are most destructive to productivity? Probably a whole generation of developers will shout in chorus 'waterfall methodologies!' I reckon that's nonsense: I can think of development practices that will cause dates to slip whatever methodology you adapt. The worst practices are those that give the illusion to the participants that they are more productive, whilst ensuring that they actually achieve very little. With somewhat more subtlety, some practices give the developer a sense of purity and good-practice whilst, at the same time tying his mental shoe-laces together to such an extent that output is negligible. The most poisonous practices cleverly conceal the overall lack of progress from the team.

I was once called in to assist a dev team who were working on a database-driven website. It was a relatively young start-up and the development atmosphere was almost monastic. They used almost entirely open-source software, even the database. They did Agile, Scrum, Kanban, TDD, pair-programming, daily stand-ups – you name it, they did it.

I soon identified the problem I was asked to fix, and sat quietly in the corner of the development area, pummeling away at the keyboard, politely declining all their agile practices. After a week, I stopped the clock; it had taken me a couple of days to fix the problem and three days to test it. I invited them to test whether I'd fixed the problem, and they were astounded at how quickly I'd solved it. On discussion, the team confessed that they'd spent months trying to find a fix.

Progress in general seemed very slow, though there were plenty of signs of team activity. One programmer had spent three years trying to develop a sophisticated printing system. I was amazed: I can remember that the person who created the entirety of Lotus 123 from scratch single-handed in assembly code did so in about six months.

Which practice in particular was causing this team to produce so little, despite their obvious energy and enthusiasm? They were 'hunting in packs'. In this context, I mean that instead of dividing the project between them, so that each was given a clear unit of work, the team tackled the same, and most interesting, part of the project collectively. They worked all together on the same bit of code, and had no clear and separate responsibilities.

As a result, everything needed group discussion and agreement. They agonized over code quality and test coverage, and picked endlessly over minor performance issues, but so focused were they on these details, they weren't aware of their total lack of progress.

Most of current development practices are fine, but they generally assist and enhance teams that are already working well as groups. They do not remove the basic requirements for coordinating teams and ensuring that they are working cooperatively and in the most effective way.

Phil Factor.