In the classic form of development projects, the users gather together and create the specifications, the design document that details exactly what the new system needs to do. The developers then create the system. The users then test it. Finally it is implemented and the system goes "live".
The problem is that accounting (and other) systems are too complex to get the specifications perfect the first time. Often system development projects devolve into a finger pointing exercise where the developers blame the users for constantly changing their minds and the users blame the programmers for not giving them what they asked for.
Agile development solves that problem by recognizing up front that programming is an iterative process. The goal then is not to get the design perfect in one document, but to put the developers and customers together so there is ongoing communication and knowledge transfer.
What does this mean for me?
If you are having custom development done on your accounting system, talk to the developers about their methodology. Don't be put off by acronyms or PowerPoint slides. Make sure you get concrete answers to the key questions:
- How will you learn our requirements?
- How will we check your understanding?
- How will we check the status/progress of the project?
- How are our people involved?
- How will the new system be implemented?
- How will it be tested?
- How will we work together to ensure the success of this project?
The last question is the key to a successful project. You need to be involved with the developers at all stages. As they design an input screen, for example, they should immediately show it to a knowledgeable user. As questions come up, they should be answered immediately, not relegated to a list of outstanding issues in a design document.
That's what it means to be Agile.