A special way to hold a meeting, which is especially suited if multiple groups of very diverse backgrounds need to do far-reaching design decisions.
I am working a big research project, which includes hardware and software projects. Design decisions must be made, which affect multiple layers (application, compiler, operating system, acceleration hardware). The problem is that subprojects have lots of hidden assumptions, of which they are usually not aware of. For example, a scientific computing programmer assumes relatively efficient floating point instructions from the hardware. She will not even think about checking with the hardware guys, if their architecture supports this. In our specific case, we had a piece of hardware to accelerate thread/task scheduling, which is of major importance for application performance and all layers in between are involved as well. There were lots of unfruitful discussions, because the hidden assumptions never surfaced. As a remedy the questionnaire meeting was a successful tool. It worked like this:
Create a questionnaire of lots of simple questions, which every party must answer before the actual meeting. In addition, everybody should prepare the arguments for their choices.
Everybody should be encourage to provide opinionated choices, so it becomes visible which designs would be favored by whom and why. Some might want a simple implementation, others powerful optimizations under the hood.
In the meeting everybody presents their arguments, which provides the others a view into their hidden assumptions.
Tips for the Questions
Use variations to double check the understanding. For example in our cases, there were two questions, where yes+no would mean one design choice and no+yes would mean the inverse design choice. The answers yes+yes and no+no means the questions was not understood, because that would be a paradox.
Avoid double negation. It makes the questions confusing.
Ask concrete and specific questions. Provide a detailed example scenario, then ask about possible results.
It is fine to answers questions with "I do not care" or "Depends on ...". Sometimes simple questions have no simple answers.
Do not insist on standard solution for the questionnaire as a meeting result. That might simplify things too much.
Example
Let us talk about ranges of numbers, for example 4 to 10. Now a few simple questions:
- How many numbers are in this range? 5, 6, or 7?
- Is 4 in the range?
- Is 10 in the range?
- Should 10-4=6 give the amount of numbers in the range?
- What is the range which includes 0, 1, 2 and 3? 0 to 3, -1 to 3, 0 to 4, or -1 to 4?
There are no definitive answers to these questions. Any definition of ranges is fine. However, within a group the definition should be consistent, so it might become necessary to constitute a common definition. At this point subjective reasons come into play.
Let everyone answer the questions on their own. Then compare the answers. Ask for the reasons, why someone answered so and so. Then discuss and find consensus.
Note the interdependencies between the questions. If you think, a range 4 to 10, should include 10-4=6 numbers, then either 4 or 10 is part of the range, but not both. The last question reveals how unintuitive it is to use -1 to specify a range which includes zero. Combining those two arguments, we conclude that the starting number is included, but the end number is not. For our example 4 to 10, this means 4 is included, but 10 is not. Dijkstra agrees.