I worked at a company which tried to push agile process upon us in a 'top-down' fashion. I believe this is a cargo cult behaviour caused by a lack of understand

I worked at a company which tried to push agile process upon us in a 'top-down' fashion. I believe this is a cargo cult behaviour caused by a lack of understanding of underling development issues. Late-running projects that don't meet requirements are often a result of poor communication and a lack of concrete requirements. This is clear to most business people. What isn't so noticeable to many is that software development looks a lot like an iceberg. The business domain decisions are visible above the water while the architecture and implementation decisions are below the water line. The fundamental point I am asserting is that software projects grow in implementation complexity at a greater rate than the complexity of the business domain does. Software projects run into scalability issues far earlier than non-software projects. At low-scale, increased centralisation of decision-making and communication increases quality and timeliness. However, at high-scale most companies make the mistake of continuing to increase centralisation on the business-domain and let this centralisation of project decisions be imposed upon the more complex implementation-domain. Doing so can backfire for the following reasons: (1) There are too many decisions which need to be communicated and specced out by one person. (2) Increasing the vertical height of an organisation creates 'chinese-whispers' type communication problems. (3) Business-domain knowledge held by project managers is often not enough to make informed decisions that require specialist technical knowledge. Now I have to be blunt. If your employees aren't high quality enough to make decisions or communicate on their own then there is very little you can do to improve your process. You can try to create mini-hierarchies of lead developers smart enough to make informed decisions and communicate in between groups of drones but this which will not solve implementation problems and yet again the centralisation will create similar issues as before. However, if you've hired smart employees you will have much better luck since you can: (1) scale decision-making and communication completely horizontally -- be careful to avoid coupling problems, (2) help people to form an iterative process that takes into consideration long-term goals, and (3) implement social interfaces (stand-up meetings being the classic example) to simplify and increase the quality of communication. The reason this should be done from the 'bottom-up' is that people aren't so much as following a process but instead are iteratively learning their process. You need to step away to let this happen.