Notes:
When I joined the project no one was quite sure what needed to be installed in order to build the software – I spent two days experimenting with different version of the JDK, the EJB container and so fourth before I could get the [small] part of the system I was working on to compile. (I'd been on the project for three weeks before I'd worked out how to build and deploy it all.)
The first process innovation I made was to write up what I'd had to do to get things working and put this documentation on a webserver running on my workstation. (I could tell this was useful because I recorded hits whenever a new developer joined the project.)
The documentation of the system was the code, and the requirements varied from a screen layout with minimal explanation to a verbal "I want to be able to edit <list of fields>". There was never any specification of client-server interactions. (This for a system with large numbers of clients.)
There was no unit testing or smoke testing regime – and it wasn't even easy to determine if the result of a check-in would compile.
Finally the pressure was on developers to release a piece of work in order to begin the next. Problems in code that had been released were generally fixed by whoever found them or handed out to the next person available – not the original author. Even when they did go to the original author some time had usually elapsed. This slows bug fixing by almost an order of magnitude.