‚Č° Menu

QAME, a framework for understanding software teams

There’s a tool used by some anthropologists for understanding cognitive landscapes that was defined by Alan Barnard in his book “History and Theory in Anthropology” (2000) which I find useful and might be helpful to others working with teams or organizations. It’s called QAME, this web which stands for Question, Assumptions, Methods, and Evidence.

Often, when we are new to a team or organization, or find ourselves as members or participant observers in any group that has a unique set of stories and histories in which we have not shared, it’s natural that we assume a certain set of shared assumptions in order to make sense of what we see and hear. Much of the stress that comes from integrating one’s self with a new group arrises from the gradual discovery, not always explicit, that those assumptions are not shared by others.This is a product of cultural conflict; in this case when two world-views with different fundamental assumptions about how the world works and what to do about it co-exist in one group.

QAME is a framework for establishing the fundamental assumptions and working theories of a group, and it’s particularly useful in a business or organizational context where goals are generally more concrete and less sensitive than might be found in other groups of people, such as a family, clan, or tribe.

QAME was described by Barnard as a way of talking about different theories of anthropology. It can be a handy tool for understanding what a theory is designed to do and which of several theories might be most applicable to a situation. If you define a theory as a set of guiding principles coupled with a set of processes and practices designed to accomplish a goal, you’ll realize that in many situations people are exercising such theories every day. Understanding the working theory of a team could be very valuable in understanding why the team behaves the way they do (culture).

I’ll demonstrate how it can be useful by applying it to two QA teams with which I’ve worked.

I’ve worked with enough teams in the past few decades to see a lot of very different behaviors, and while the two examples I’ve chosen may seem to represent two stereotypes, I can assure you that both exist in the wild. However, these responses below are not from real people, but were created for the purpose of illustration.


The Q stands for “question.” What question(s) is the theory designed to address.

Team A: How can we help our team to create software that our customers love in the most efficient and effective way possible?

Team B: How can we win the bug hunt this release?

The A stands for “assumptions.” What are the common assumptions that those following the theory agree upon (expressly¬†or subconsciously)?

Team A: We are all working as a team, despite our different specializations, toward a common goal and everyone is doing their best, even when they have an “off” day.

Team B: Programmers are sloppy and we’re here to clean up the mess. There is some level of bugs which is acceptable to management and by inference, to our users.

M stands for “methods.” What practices and tools do practitioners of the theory use to address their questions?

Team A: We work with everyone from the client to the users to optimize the entire value chain using tools like TDD, automated acceptance testing, and user interviews.

Team B: QA Leads write test cases for us to execute and we report bugs using our standard bug report form for later prioritization by PMs.

E is for “evidence.” What types of evidence are meaningful to members of the group?

Team A: We track results of user surveys, the state of the automated tests on the CI server, sales growth, and other metrics as we find them useful.

Team B: We track bug count per build and who wins the quarterly bug-hunt.


Both of these respondents would describe themselves as a “tester” but clearly they working with different theories. It would be very tempting to make value judgements at this point, but there are some other principles anthropologists subscribe to that apply here.

One is called “holism” and it means that behaviors and cultural artifacts/traits are considered only in the greater context of the cultural environment in which they occur (you can’t separate QA practices from management incentives or hiring practices, for example). It would be a mistake to judge either of these testers without considering the nature of the environment in which they work. You might also be tempted to judge them on the basis of what you consider to be appropriate in your experience. That is what anthropologists called “ethnocentrism.” Rather, anthropologists value “cultural relativism” which means that cultural phenomena can only be judged within the cultural context in which they occur.

In my opinion, both of these teams evolved a theory that was well-suited to their environment and each may represent the best possible adaptation to the pressures, expectations, and realities in which the different theories operated.

 

Comments on this entry are closed.