Sometimes it’s hard to say the thing we want to see.
As a dad, I’m fascinated by human language development; and as a software maker, I’m constantly engaged in sharing mental models. Atoms spend a lot of time communicating with customers to bring a shared vision to reality. Reflecting on that practice, I recently discovered a sociological model that ties together language and shared understanding, called “interactionism.”
Interactionism is a broad term even when isolated to sociology; in this post, I’m referring to a group of theories that claim that neither our shared culture nor our inherent psyche are singularly responsible for shared understanding in groups. Instead, it’s suggested that the interaction between them allows concepts to be shared and even gives meaning to language.
There are a number of related theories, including Bandura’s Social Learning Theory, Vygotsky’s Social Development and Social Interactionist theories, Situated Learning by J. Lave and finally Mead and Blumer’s Interactionism, but here I’ll refer to the common theme and wrap these up as “interactionist.”
For me, these ideas resonate with the practice of iterative development. One of the key features of delivering continuously is that we grow a shared understanding of success early in the process and refine it over time. While I’ve seen this work experientially, it also encourages me that there are models for learning that suggest the interactions I expect during iterative development.
What can Interactionism teach us about making software?
The central theme is that learning occurs in a social context. Since language development is strongly related to learning, language development in a group builds shared culture and aids mutual understanding of concepts.
Applying this leads to the belief that continuous, direct interaction with a customer allows for social learning across the whole team and a chance to build a language unique to the problem domain.
It might seem obvious that working closely with your clients increases your chance of a successful relationship, but some challenges that commonly get in the way include:
- Either side is busy, possibly owning multiple projects at a time.
- Teams are separated geographically, so close interaction is costly.
- Teams have differing personalities that create gradients to communication. (Procrastinators, close talkers, introverts, visionaries, and programmers may not get along without effort!)
Facing those obstacles, it’s important to have deep reasons for the effort required to overcome them.
What the interactionist theories suggest is that it’s not just time spent together, or simple conversation and empathy that create a path to mutual learning. They point towards specific interactions that create shared understanding. I’ll discuss two of them: building shared language, and communities of practice.
Building Shared Language
When a team breaks out for new territory and starts solving problems together, they tend to create a shared language — especially when they’re working closely together. These languages include more than just names for stories, features, and functions. When your customer is part of the team from the start, shared languages can take on their own cultural symbolism. Just hearing and understanding a new term that the team has started throwing around helps customers and makers identify as a group.
At Atomic, we start this process intentionally during our “research, design, and planning” process. The shared language we build is more than just social bonding; it strengthens empathy and builds intuition. Terminology turns into implicit knowledge, and its use reinforces team cohesion.
According to Vygotsky, humans use tools that develop from a culture, such as speech and writing, to mediate their social environments. Initially children develop these tools to serve solely as social functions, ways to communicate needs. Vygotsky believed that the internalization of these tools led to higher thinking skills.
— Social Development Theory (Vygotsky)
While the quotation above is about child learning, it’s applicable to a team entering a new business domain to write software. In this context, we often refer to the state of “beginners mind,” with the emphasis on child-like learning and open-mindedness. It may be the customer that is new to the technology, or the makers that are new to the domain. Either way, spreading the shoshin around is a good thing.
When everyone on the team feels like they are speaking a unique shared language, they’ll associate strongly with its symbolic understanding. Memory and open-minded communication will require less effort than on a team that requires constant cross-translation.
Communities of Practice
Another way to foster deep identification and intuition within your team is through a sense of community. When we apply this approach to teams working for a common goal, it’s called a “community of practice.” The term is from Jean Lave and Etienne Wenger, and while it’s a big deal in organizational science now, it’s also been a part of the agile conversation since at least 2004.
The idea is that everybody already belongs to a number of naturally-arising communities of practice. They are like anthropological patterns — you already have them, even if you didn’t recognize them as such. They emerge as combinations of domain, community, and practice. With these three ingredients, learning happens in a social, relationship-based way, rather than through deliberate instruction.
In communities of practice, members are “active participants in the practices of social communities and constructing identities in relation to these communities.” The sense of identity is something I see frequently when we engage customers in our RDP process. They know their domain well, but sharing it in an active, hands-on, whole-team environment allows customers to personally identify with that knowledge. It helps everyone understand that the software we are building is not just a set of requirements to be discovered, communicated, and executed, but a combination of technology expertise and domain expertise coming together in a continuous building process to achieve the customer’s goals.
Application
I’ve covered a couple of “interactionist” methods of learning from the social sciences and looked at how they can help us build great software with our customers:
- Build a language amongst your team early to gain intuition and symbolic understanding of the shared vision.
- Develop your team interactions towards a community of practice to promote situated learning in your domain.
References
- Smith, M. K. (2003, 2009) ‘Jean Lave, Etienne Wenger and communities of practice’, the encyclopedia of informal education, www.infed.org/biblio/communities_of_practice.htm.
- Vygotsky, L.S. (1978). Mind and society: The development of higher mental processes. Cambridge, MA: Harvard University Press.