Must business people and developers always work together daily?

Question

Business people and developers must work together daily throughout the project.

from Principles behind the Agile Manifesto

Does this not violate Joel 8? Compulsory daily meetings with non-technical people don't really fit "peace and quiet, think only about the implementation" mood.

Or is point 8 about actual sound in the room and nothing more?

Answer 1

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.

Answer 2

No, it doesn't mean "Compulsory daily meetings with non-technical people"

In the then prevailing Waterfall model of development, requirements were gathered, written-down and signed off in the first phase of the project. After this, the development team will go through analysis, design, development and testing sequentially with no interaction with the business people. Pretty much when the development and testing is complete, the finished product will be delivered to the business people with a demo. This often resulted in nasty surprises, including in some cases the business people rejecting the product outright saying, "this is not what we asked for".

The why "work together daily" is answered in the other principle:

Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

Let me describe how this was put into practice in the most popular Agile software development framework, namely Scrum, with examples from one of my previous projects.

• The Product Owner (PO) is the primary conduit to channel the business people's (stakeholders) needs, feedbacks and comments to the dev team.
• When the designers are ready with the initial look and feel of the web pages, they will meet with the business people, coordinated by the PO, to get their feedback, make necessary changes and get final approval.
• When requirements clarifications are sought by the dev team, the PO may be able to give the answer or consult with the domain experts among the business people and then give the answer.
• When ready, stories are first tested by the dev team and then given to the PO/concerned business people for further validation testing.
• At the end of the two week sprint, a demo of the developed features are given to all interested stakeholders and their feedback is sought.

So, it is not "Compulsory daily meetings with non-technical people". There is frequent interaction and opportunity for the business people to provide feedback. They can guide the product to meet changing market needs. They won't be surprised by the finished product.

Answer 3

The idea being expressed here is that there should be no barriers to technical and business teams working together as often as they wish to. As Bogdan suggests, this can be understood as a reaction to some more formal methods of governance which expect communications to be channelled through detailed requirements documentation, hierarchies and minuted meetings.