You have to realize that Agile was born as a response to heavyweight software development processes that were commonly used back then (the Agile manifesto was written in 2001), that were documentation driven, rigid, and with fixed linear activities like requirements gathering, design, implementation, testing, delivery and maintenance (mostly Waterfall).

The client was involved only in the early stages of the project, and the idea was that people can sit together and lay down all the requirements needed and describe everything that the software needs to do upfront. Then developers will provide an estimate, a price for the projects will be agreed, a contract will be signed, then the developers will build the software and deliver it to the clients at the end of the project. As already explained by Ashok Ramachandran in his answer, this doesn't really happen in reality because:

• clients don't usually know what they want.
• people can't explain in full details something that they don't know yet how it should look or work;
• people can't plan something in details for a long period of time;
• plans always go astray for various reasons that no one could predict;
• etc.

So in order to avoid these problems, Agile says that you should keep the client, customer, or business people close, and involved in development throughout all the project, not just at the beginning. That's how you make sure you build the right thing and don't have any bad surprises in the end. Developers build something together with the business people, see how it works, inspect the result, make changes to it if needed, decide together what to build next, build it together, inspect the result, and so on ans so forth. You can make sure you build the right thing by having many interactions with the customer (i.e. working together daily, not like in the old ways where you worked with the customer just so you can obtain a signed document of requirements then everyone would bugger off and do their own thing).

Now, as for the Joel Test, number 8 says that programmers should have quiet working conditions. This is because programmers are knowledge workers and do their work with their brains. For this they need to have long stretches of uninterrupted time to be able to focus and "get in the zone" or in "flow". If the working environment is noisy or everyone interrupts you with something, then you can't get in the zone and be fully productive. Joel says programmers should have their own offices, instead of working in open spaces.

Now, Agile usually says people should be colocated because face-to-face is the best kind of communication, so somehow that implies an open space or an open room, which is noisier than private offices, but this doesn't necessarily contradict Joel's 8th test point because Agile is also about people and people values like respect. If some team members need to discuss stuff or ask things to the business people, they can do so by leaving the open room, or ask on chat, or agree on some rules, etc, to allow the rest of their team mates to work undisturbed.

You have to realize that Agile was born as a response to heavyweight software development processes that were commonly used back then (the Agile manifesto was written in 2001), that were documentation driven, rigid, and with fixed linear activities like requirements gathering, design, implementation, testing, delivery and maintenance (mostly Waterfall).

The client was involved only in the early stages of the project, and the idea was that people can sit together and lay down all the requirements needed and describe everything that the software needs to do upfront. Then developers will provide an estimate, a price for the projects will be agreed, a contract will be signed, then the developers will build the software and deliver it to the clients at the end of the project. As already explained by Ashok Ramachandran in his answer, this doesn't really happen in reality because:

• clients don't usually know what they want.
• people can't explain in full details something that they don't know yet how it should look or work;
• people can't plan something in details for a long period of time;
• plans always go astray for various reasons that no one could predict;
• etc.

So in order to avoid these problems, Agile says that you should keep the client, customer, or business people close, and involved in development throughout all the project, not just at the beginning. That's how you make sure you build the right thing and don't have any bad surprises in the end. Developers build something together with the business people, see how it works, inspect the result, make changes to it if needed, decide together what to build next, build it together, inspect the result, and so on ans so forth. You can make sure you build the right thing by having many interactions with the customer (i.e. working together daily, not like in the old ways where you worked with the customer just so you can obtain a signed document of requirements then everyone would bugger off and do their own thing).

Now, as for the Joel Test, number 8 says that programmers should have quiet working conditions. This is because programmers are knowledge workers and do their work with their brains. For this they need to have long stretches of uninterrupted time to be able to focus and "get in the zone" or in "flow". If the working environment is noisy or everyone interrupts you with something, then you can't get in the zone and be fully productive. Joel says programmers should have their own offices, instead of working in open spaces.

Now, Agile usually says people should be colocated because face-to-face is the best kind of communication, so somehow that implies an open space or an open room, which is noisier than private offices. But this doesn't necessarily contradict Joel's 8th test point because Agile is also about people and people values like "respect". If some team members need to discuss stuff or ask things to the business people, they can do so by leaving the open room, or ask on chat, or agree on some rules, etc, to allow the rest of their team mates to work undisturbed.