≡ Menu

Emic and Etic Approaches to Explaining Team Behaviour

I’ve been intrigued by the idea of self-guided retrospectives. Imagine motivated teams that could collect and evaluate data and reach valuable conclusions without management guidance!

It appealed to me in more ways than one – firstly, order to my principle of empowering teams wherever I can. It also suits my personality. I’m an introverted control-freak, which means I risk manipulating situations even when I’d really rather not be involved at all. I’ve come across techniques by which teams could progress through a retrospective themselves, but I face the added complication that many of our projects have at least one remote team member, because our clients are usually in America or Western Europe. I seized on the idea that Kanbanery, our web-based project tracking tool, could be used to facilitate the kinds of interactions that lead to a valuable retrospective. Of course, the approach would work with any online kanban tool that provides live updates.

Our retrospectives with distributed teams were always very traditional, with either no interaction with physical objects (discussion only) or with a local proxy assisting remote participants. There’s value in collecting ideas on cards and manipulating them as a group, but I don’t like the necessity of treating remote team members differently.

Teams in Lunar Logic are using Kanbanery’s real-time updates features to collaborate effectively. Could we use the same familiar tools to hold a retrospective session? The answer came when I applied a TRIZ technique of reducing the environment to its bare essentials and asked what I had to work with within the constraints I set. If you’re of a more philosophical bent, you might say that I asked of Kanbanery: “What is this thing in itself?”

Kanbanery is intended to visualize the flow of work through a process but essentially it is just a series of lists of items which can be moved between columns, both horizontally and vertically.

Getting Started

Items have certain distinguishing features that help organize your work:

  1. A title field with a larger description field,
  2. The avatar of the last person that handled them,
  3. Checklists, type fields, and check marks just in case you need them.

as well as a variety of other features that weren’t required while preparing for a retrospective.

A Kanbanery-powered retrospective

Thinking of Kanbanery as a series of lists gave me the clue I needed to devise the retrospective exercise.

Newly created tasks appear in the first column, so I called it the ‘Working’ column. I labeled the next column ‘Retrospective Steps’ and in it I placed the instruction cards for conducting the retrospective. There are many methods of conducting a retrospective, but the most common is to collect data from team members about the recent history of the project, evaluate their answers, extract useful practices and discard those that were unhelpful and finally to choose a small set of those changes to implement in the next iteration. I created columns for each of these steps.

We used this process for our last Kanbanery retrospective, which I joined from home while I was ill. Here is how it works. The team members sit at laptops in a room together or in their own offices and start a live call via any teleconferencing system (we used Skype). Because of the shared Kanbanery board, all team members are equal and interact with it in the same way.

The team begins to work through the steps listed in the Retrospective Steps column:

History

  1. They set a timebox for the meeting and write it down in the title of the first card, so everyone knows when the meeting will end,
  2. Everybody reads and all agree to the retrospective prime directive,
  3. Team creates the project history by adding cards and dragging them into the History column in chronological order.

The advantage to using Kanbanery is immediately visible – everyone contributes in his or her own way and time without biasing others. Cards begin appearing like “Got our first paying user”, “Migrated to new test server”, and “Marcin joined the team”. The avatars show who added which tasks.

Ideas

When the time is up, the team members use the checkmark feature to mark the events in the history that they feel good about. The team can talk over, point by point, any ambiguities during this stage.

Afterwards the team, with the history fresh in their minds, brainstorms about the useful practices that might be associated with the highlights of the recent history, about unhelpful practices that might have led to the pitfalls they faced, and to practices they’d like to consider adding or changing to make future iterations more effective. They do this in the same way in which they built the history, by creating cards with ideas in the Helpful and Unhelpful Practices column.

Next the team talks about the practices listed and agrees on three (or any other number) which they will change going forward and they drag these to the final column, What We Will or Will Not Do. The team can look at these decisions and clarify them in terms of how they will be implemented, by whom, and when. After reaching an agreement, they can capture these ideas by using Kanbanery’s “Export to PDF” function to print the decisions onto index cards easily put on the wall.

Practices

Though I participated in the retrospective as a remote member, not only was it a very focused and well-organized retrospective, but also I felt I was actively participating because I could create my own tickets in just the same way the other team members were. The meeting stayed on time, each phase was clear and moved us inexorably to useful conclusions.

Ideally, retrospectives are very interactive activities that take place with everyone in the same room, finding solutions and exposing truths hands-on with appropriate visual tools, but that’s not always possible in this day of remote work and global teams. Here’s a new technique to add to your remote development toolkit. Let us know how it works for you in the comments.
I’ve been intrigued by the idea of self-guided retrospectives. Imagine motivated teams that could collect and evaluate data and reach valuable conclusions without management guidance!

It appealed to me in more ways than one – firstly, order to my principle of empowering teams wherever I can. It also suits my personality. I’m an introverted control-freak, which means I risk manipulating situations even when I’d really rather not be involved at all. I’ve come across techniques by which teams could progress through a retrospective themselves, but I face the added complication that many of our projects have at least one remote team member, because our clients are usually in America or Western Europe. I seized on the idea that Kanbanery, our web-based project tracking tool, could be used to facilitate the kinds of interactions that lead to a valuable retrospective. Of course, the approach would work with any online kanban tool that provides live updates.

Our retrospectives with distributed teams were always very traditional, with either no interaction with physical objects (discussion only) or with a local proxy assisting remote participants. There’s value in collecting ideas on cards and manipulating them as a group, but I don’t like the necessity of treating remote team members differently.

Teams in Lunar Logic are using Kanbanery’s real-time updates features to collaborate effectively. Could we use the same familiar tools to hold a retrospective session? The answer came when I applied a TRIZ technique of reducing the environment to its bare essentials and asked what I had to work with within the constraints I set. If you’re of a more philosophical bent, you might say that I asked of Kanbanery: “What is this thing in itself?”

Kanbanery is intended to visualize the flow of work through a process but essentially it is just a series of lists of items which can be moved between columns, both horizontally and vertically.

Getting Started

Items have certain distinguishing features that help organize your work:

  1. A title field with a larger description field,
  2. The avatar of the last person that handled them,
  3. Checklists, type fields, and check marks just in case you need them.

as well as a variety of other features that weren’t required while preparing for a retrospective.

A Kanbanery-powered retrospective

Thinking of Kanbanery as a series of lists gave me the clue I needed to devise the retrospective exercise.

Newly created tasks appear in the first column, so I called it the ‘Working’ column. I labeled the next column ‘Retrospective Steps’ and in it I placed the instruction cards for conducting the retrospective. There are many methods of conducting a retrospective, but the most common is to collect data from team members about the recent history of the project, evaluate their answers, extract useful practices and discard those that were unhelpful and finally to choose a small set of those changes to implement in the next iteration. I created columns for each of these steps.

We used this process for our last Kanbanery retrospective, which I joined from home while I was ill. Here is how it works. The team members sit at laptops in a room together or in their own offices and start a live call via any teleconferencing system (we used Skype). Because of the shared Kanbanery board, all team members are equal and interact with it in the same way.

The team begins to work through the steps listed in the Retrospective Steps column:

History

  1. They set a timebox for the meeting and write it down in the title of the first card, so everyone knows when the meeting will end,
  2. Everybody reads and all agree to the retrospective prime directive,
  3. Team creates the project history by adding cards and dragging them into the History column in chronological order.

The advantage to using Kanbanery is immediately visible – everyone contributes in his or her own way and time without biasing others. Cards begin appearing like “Got our first paying user”, “Migrated to new test server”, and “Marcin joined the team”. The avatars show who added which tasks.

Ideas

When the time is up, the team members use the checkmark feature to mark the events in the history that they feel good about. The team can talk over, point by point, any ambiguities during this stage.

Afterwards the team, with the history fresh in their minds, brainstorms about the useful practices that might be associated with the highlights of the recent history, about unhelpful practices that might have led to the pitfalls they faced, and to practices they’d like to consider adding or changing to make future iterations more effective. They do this in the same way in which they built the history, by creating cards with ideas in the Helpful and Unhelpful Practices column.

Next the team talks about the practices listed and agrees on three (or any other number) which they will change going forward and they drag these to the final column, What We Will or Will Not Do. The team can look at these decisions and clarify them in terms of how they will be implemented, by whom, and when. After reaching an agreement, they can capture these ideas by using Kanbanery’s “Export to PDF” function to print the decisions onto index cards easily put on the wall.

Practices

Though I participated in the retrospective as a remote member, not only was it a very focused and well-organized retrospective, but also I felt I was actively participating because I could create my own tickets in just the same way the other team members were. The meeting stayed on time, each phase was clear and moved us inexorably to useful conclusions.

Ideally, retrospectives are very interactive activities that take place with everyone in the same room, finding solutions and exposing truths hands-on with appropriate visual tools, but that’s not always possible in this day of remote work and global teams. Here’s a new technique to add to your remote development toolkit. Let us know how it works for you in the comments.
The software world borrows heavily from manufacturing when trying to find good ways to build stuff that works, sanitary and it borrows from psychology when trying to figure out what makes people tick. That’s well and good, but there are other models out there, most notably provided by sociology and anthropology. In my continuing mission to introduce the software world to more useful concepts from my domain, today I’ll share two ways of describing team behaviors.

One of the things I admire about anthropology is that it is unique among the sciences in the way that its practitioners try to remain paradigm-agnostic. Rather than choose to follow, for example, the structural-functionalists with their assumptions, goals, and methods, and disregard the post-modernest school of thought, an anthropologist will use her knowledge of the multiple ways of interpreting the world and choose the ones that are most suited to the study.

Ethnographers (a branch of anthropology) describe culture, which is the learned behaviors and beliefs of a group of people, and fundamentally there are two ways to describe what you see when looking at a group of people. You can compare what you see to what you know about how other groups of people behave. For example, “This team holds daily standups during timeboxed iterations as defined by the Scrum guide and practiced by other Scrum teams around the world.” Anthropologists call this an etic approach. You can also describe a group’s behavior from the point of view of the group. “The team has found that they can achieve their best productivity to date by using four pairs of programmers rotating members daily with two pairs of testers.” This is an emic description (sometimes referred to as an “insider’s” approach). It describes the team’s behavior as they would describe it themselves, without reference to external norms or standards.

The mnemonic I used when I first learned about emic and etic descriptions is that the M in emic refers to Me, and how I’d describe myself and the T in etic refers to Them, and how I’d describe others. Therefore an emic description is how someone describes themselves, and and etic description might be how that person would describe others.

I recently read a striking contrast between the two approaches in an ethnography on a community in Central America which practices infanticide. The ethnologist points out that infanticide is a practice that allows impoverished families to maintain a minimal living standard without the burden of children who for one reason or another are unlikely to contribute to the family’s economic well-being. That is an etic description. Mothers in this group describe such children as being “born without a will to live” and therefore they might feed them last, or not at all, or deny them medical care that the family can’t afford. That is an emic description that serves to remind us that what one calls murder is rarely considered murder by the people involved. Being proficient at using both emic and etic approaches is often the key to achieving the understanding required to encourage change in a group’s or team’s behaviors.

Let’s look at an example closer to home for us software folks. You’re an agile coach, arriving in a new environment with a mission from management to “make this team more agile.” If you, like so many consultants in most every field, favor an etic approach, you will begin by doing a gap analysis between the behaviors and artifacts that you see and those with which you are most familier. That’s useful, and practically inevitable. The next natural step, however, may be less helpful. That is to judge the gaps between what this team is doing and what you consider to be normal as wrong, or indicative of some organizational pathology. This might be a good moment to recall that agile development prescribes no practices at all. It’s about principles. Principles can manifest themselves as practices, but one cannot reverse engineer principles from practices at a glance. Figuring out what motivates a team to act as they do requires a deep understanding of the people and their environment (I feel a blog post on “participant observation” coming on). Here’s where an understanding of emic versus etic descriptions comes in handy. By deciding, as a consultant or coach, to now attempt to prepare an emic description of the team’s behaviors, you force yourself to set aside your preconceptions and engage in meaningful converstations with the team in order to understand how they see themselves. Now you have two tools in your kit, where you might before have had one, and more tools prepares you for more situations.

Neither approach is right or wrong. Both are valuable in different circumstances. Always favoring one or the other will cripple a coach trying to help a team, because the one will constrain him to the limits of the team’s experiences and the other is inclined toward dogma over results. You’ve probably seen both scenarios. Understanding that there are two valid and complimentary ways of describing team behavior is a useful step toward avoiding the fallacies of favoring one over the other.

For another model that can be used to describe team culture, also borrowed from anthropology, see my blog post about QAME.

Visit the Wikipedia entry for more information.

Comments on this entry are closed.

  • Jamie November 14, 2012, 1:21 pm

    I give my colleagues, as part of their training, the book Real World Research, by Robinson. We focus on the sections about participant observation and this continues to be useful to us and our clients. In fact, when overwhelmed by a situation I remind my more junior consultants to remember that their work is observe and that their own feelings are actually a source of information.

    I think your quest to spread ideas about anthropology is a good one but I do think there are some amateurs already out there.

    J