One of the things on the hype train is agile development. We have started calling common sense development as agile development. Fair enough. We need to characterize and refer to this type of development model and the word agile fits. I am all in favor of agile development but what most people miss is that the success of an agile project not only depends on the development team embracing agility but also the business users and the client stakeholders doing the same. 

Also you have to spend time defining agility for your project. What does being Agile mean for your project? Short iterations, frequent code drops,continuous feedback loop defined, what tools will you use to support agility, etc. The list goes on. Also will you be following an agile methodology like SCRUM, FDD, etc or are you happy with a simple home grown approach. All of this defines your agility and everyone working on the project (in any level) has to understand the chosen agility approach.

Many large organizations are not technology firms and only care about getting their project done. IT is a tool that helps them perform their core business tasks more efficiently. Often these are people who are ina certain role for years and they do not want to hear any IT mumbo-jumbo. Regardless it is critical to get all the stakeholders together and explain at a high level your development strategy. You must explain to everyone what their role will be in the agile process.

Typical of agile development is to break the release into small iterations. Within (and between) an iteration the development team will make many code drops into a dev/qc environment. What comes out of that iteration is not production quality code. Idea is to get things done in a nice loop where we can incorporate feedback from everyone into the next iteration.  Of course having small iterations is not an excuse to drop code that is riddled with defects. Each iteration should have requirements, design, code, unit testing, integration testing, user and testing team testing.

The key to agility is adaptability. We are continuously getting feedback and incorporating it; to a point where this becomes second nature. The testing team is almost an extension of the development team in agile projects. While there should be an allocated time for formal testing between iterations, the testers should be actively testing functionality within an iteration. What gets delivered into the QC environment, within an iteration, should be some amount of incremental functionality (or bug fixes) that can be tested. Again having testers hooked in early should not be an excuse to skip unit testing. That would be really irresponsible on part of the development team.