Agile is:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Set up your development environment to reflect and support these principles.

Scrum is a way to manage your work, not your development environment.

The QA manager might get his idea from the seemingly common interpretation of Agile where a team delivers a completely (QA-)tested product each spring that can be rolled out to the customers and he extrapolated that to reach the conclusion that it can be best achieved with a single development/QA environment.

And it might be one way to implement Agile practices, but it certainly is not the only way. I have worked with scrum in an environment where the development and QA teams were largely separate, and the QA team was the “customer” of the development team. In such an environment, the development and QA teams naturally work on different servers/deployments.

We can’t really advise if a single dev/QA server environment is going to work for you. It depends too much on how you are used to work and how well the different people can cope with the occasional broken build.

One thing is for certain: Agile does not dictate anything with regard to how you set up your development (and related) environments.

It is well established in a waterfall environment that the early detection of bugs reduces cost of fixing them. As analogy, you could think of all waterfall stages happening concurrently.

Therefore, a way of supporting that and reducing waste, you could argue that using one development server could cut costs. As soon as the developer has finished, the Testers can begin doing their work. It eliminates the waste of having to deploy the software to a new environment and the waste of waiting time.

Of course, testing deployment in itself is valuable. Having features in a state of development may cause false positives – unfinished features may ‘work’ and then later regress or testers tell you that it doesn’t work when it isn’t finished. You have to make this judgement call for our own team. We don’t have enough context for a definitive answer.

And in the end, your QA manager doesn’t actually have to do the coding himself. In this context he has a ‘chicken’ role. If your team of developers feel that they can work better or more productively by ignoring him, then they should.

I think teams can work in more agile fashion if they have multiple servers at appropriate levels..

First some assumptions: Two development teams: USA and Pakistan. QA is a separate team and uses nightly build. Development teams are highly productive and do frequent check-ins. They can use a Distributed Version Control e.g. git.

So a developer from Team USA will run unit test on his machine for areas effected by his latest check-in to Local Repository and will then push the changes to the Team Repository. There the complete unit testing suite along with automated functional tests* to be run on Product A. If everything is green then the code changes to be anatomically pushed to Check-Build Repository where integrated tests would run. If still green, then changes to be automatically pushed to Master Repository used for nightly build. That nightly build to be used by the QA next day.

All repositories to have their own application/data/build servers.

*If functional tests are long running then we can have two level of Team Repositories. One for short running tests (e.g. all unit tests, some functional tests) and second for long running functional tests.

Although as Bart says, Agile might not dictate an environmental set-up, the values and principles do indicate best practices where code is aggregated and tested on an ongoing basis. That practice is in direct opposition to the gatepost approach in traditional waterfall environments. Transition through the gateposts suggests an approach is waterfall. High levels of automated integration testing suggests agility.

Bottom Line: You’ve got to have essentially all of the testing done within the confines of the Sprint to meet any Agile Definition of Done. How the code is Released to Market is up to the business. They can RTM weekly, monthly or quarterly and still claim to be Agile, but they need to maintain a Staging site for code that is Done but not Released.