There is overwhelming evidence that defining requirements in detail upfront is phenomenally bad practice, unethical at best in the IT world.
A changed requirement late in development cycle is a competitive advantage provided you can act on it.
Change management is really about change prevention. People that follow change management are worried about scope creep and are trying to prevent it. These people fundamentally do not understand what their jobs are as IT professionals. When you prevent requirements from changing, then yes you might be building something to spec, but you are now building something that people do not want and you are charging them for it. That is not ethical.The best way for communication is face to face communication. If you want to increase the risk on your IT projects, write documentation and create a detailed specification.
Repeatable processes are bureaucracy. What people really want are repeatable results. They want high quality. They want systems that meet their needs in a timely matter. Delivering repeatable results requires discipline.
Agile is highly disciplined. You have to distinguish between bureaucracy and discipline. Bureaucracy is not discipline. Filling up paperwork, documenting requirements, documenting detailed architecture, reviewing them, and getting people to sign off on them, all this is not discipline. This is bureaucracy.
Real disciplined is producing high quality software every few weeks. It is refactoring and cleaning up your code as you go. It is about professionals validating their own work to the best of their ability. Don’t just throw stuff over to QA.
Agile teams are self organizing generalists. Like the military, guys on the ground are allowed to make decisions and adjust. Specialists are risky. If the specialists are gone, everybody is in trouble. We should avoid hand-offs between specialists.
Agile teams are easier to manage than traditional teams. In agile world, you cannot hide anymore, you have to produce.
There is nothing new about Agile. Most ideas of Agile can be traced back to the 60s and 70s. Agilists focus on the things that work and avoid the things that do not work.
There is nothing special about you. Do not come up with excuses for not adopting agile.
