Is it necessary/recommend/best practice/any other positive to use only one server environment to perform all development, unit testing and QA?

If so, is it then wise/part of Agile to then have only one staging environment before Live?

Considering that this could mean internationally distributed teams of developers and testers in different time zones is this wise?

This is something being implemented by our QA manager. The opinion put forward is that doing all the dev and testing on a single server is "Agile." The staging environment would be a second environment, and then live.

  • 4
    Why would you need to confine it to a single server? Jun 27, 2013 at 21:01
  • 8
    What does team management (SCRUM) have to do with your development / server environment? If anything it would be that the team(s) decide what development environment works best for them and if the team decide that they need separate servers there is nothing in Agile or Scrum that prevents that. Jun 27, 2013 at 21:08
  • This is something being implemented by our QA manager. The opinion put forward is that doing all the dev and testing on a single server is "Agile." The staging environment would be a second environment, and then live.
    – Matt W
    Jun 27, 2013 at 21:18
  • 2
    Do you (or your QA manager) have any references to the practice of using a single server? I guess you think he's making it up. Jun 27, 2013 at 21:44
  • I certainly don't but as he's a professional with years of experience I can only assume he does. I see the dev and test layers as separate from the staging and production layers and, where the team agrees, necessary.
    – Matt W
    Jun 28, 2013 at 6:45

5 Answers 5


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.

  • Thank you. I have read the manifesto and could not see any rules relating directly to specific practices which would state clearly "developers and testers should/must work on the same environment." I would like to know how the decision to move a testing layer is a benefit, or if it is nothing more "doesn't look smooth."
    – Matt W
    Jun 28, 2013 at 6:47
  • 2
    You're missing the point, Agile doesn't specify what tools/environment you use for a reason, because it's up to YOU to decide what's best for YOUR team. There is no best way of setting up an environment, as every team is different, and instead of trying to fit a square peg in a round hole, agile leaves the implementation specifics up to you.
    – Ampt
    Jun 28, 2013 at 12:03
  • Thanks... Your point was exactly what I tried to communicate to the team.
    – Matt W
    Jun 29, 2013 at 8:03

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.

Not the answer you're looking for? Browse other questions tagged or ask your own question.