What is Culture: a primer for Agile

In his 1989 book on organisational theory, Gareth Morgan includes a case-study — “The Creation and Destruction of the Order of Maria Theresa.” The Order of Maria Theresa is an Austro-Hungarian military award given for (purportedly) successfully acting against orders. The motto Se obedece pero no se cumple (“One obeys but does not comply”) perfectly captures the spirit of Maria Theresa. In the case-study the eponymous heroine is managing a petrol station, operating around — and often through — corporate rules to focus on working together to serve the customers. There are numerous examples of the staff working hard to support one another and to serve customers. Despite — in fact, because of — the blithe disregard for rules and policies, the station excelled in sales and customer satisfaction. For personal reasons, Maria decided to move on and was replaced by a by-the-book manager who focused on individual accountability and the letter of the law. This new approach alienated the staff and the customers; the spirit of collaboration nosedived along with the sales and satisfaction numbers.

Click here to download a PDF version of the original case.

It’s easy to see this story as a story of two cultures and to see the Order of Maria Theresa as the embodiment of agile culture, albeit in a very different world from software development or car manufacturing. We can readily recognise culture, but explaining it is more difficult. To get to that explanation, I’m going to delve into some thinking about culture, largely from outside of the agile community. Getting to the essence of what organisational culture is helps inform how to bring about agile transformation.

Shape not Content

One of the reasons culture is hard to define is that it is a broad concept — and can be defined in a wide range of different ways. Many definitions of culture focus on the contents of culture. In the previous post, I wrote about the agile manifesto, scrum values, generative culture, and the Toyota Way. Each of these is cultural content — specific things in a culture that will be familiar to any of us who know agile: variations on a consistent theme that draw a picture of ‘agile culture’. Given we have a reasonably good idea of the content of an Agile culture, that’s not going to be the focus of this post. Instead, I want to understand the essence of what culture is: the container into which we pour this content. The reason for this is that to help a team become more agile you need to understand the shape of the container.

Describing Culture

The agile manifesto is essentially a statement of values. The agile principles are a mixture of norms (“Business people and developers must work together daily throughout the project.”, beliefs (“The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”), and values (“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”)

That’s no surprise: these three things are the building blocks of the sociological definition of culture as the common, shared glue that holds a society together consisting of:

• Norms describe desirable ways to behave, they are commonly shared rules for what is appropriate to do and say.
• Beliefs are ideas that are held to be true, usually uncontested.
• Values are descriptions of what is good: what is deemed desirable or aspirational

Added to these three building blocks, we often see related dimensions, such as material culture, symbols, and language. To use a software analogy, culture can be thought of at the attributes of a class. But this approach describes specific cultures without defining culture.

What, Actually, Is Culture

To get to what culture is, I’m going to draw upon different domains, starting with anthropology. Social and cultural anthropology is the study of how cultures and societies emerge and change over time. Anthropology defines culture as a tool used by society to adapt to nature or as the patterns of meanings that we use to “communicate, perpetuate and develop their knowledge about and attitudes towards life” [Geertz 1973: 89]. These functional definitions bring a very different flavour to understanding culture: the contents of culture, serve the function of creating and sustaining the culture, society, and organisation. To return to the software analogy, we can view culture as the methods of a class.

Cultural beliefs actively help the organisation adapt: a team that is believes that the best architects, requirements, and designs emerge from self-organising teams is more likely act to self-organise, to empower teams, and to help them produce good architecture, design, and requirements.

The second domain I’m going to draw on to define culture is organisational behaviour. Edgar Schein identified three levels of culture: artefacts and behaviours, espoused values, and assumptions.

• Artefacts and behaviours are the things people do and produce. They are material and can be directly observed.
• Espoused values are the things people say about beliefs and norms and can be shared through communication.
• Assumptions are the things we really believe our deepest underlying values. Assumptions are typically learnt or uncovered through inference; they tend to be subconscious and are difficult to articulate or even recognise for those in the culture.

Achieving cultural change that will last means getting to and changing the underlying assumptions that are often poorly articulated, or even understood, by those in the organisation.

To use — stretch — our analogy, if we think of the assumptions as a private parent class, the espoused values as a public child class, and the artefacts and behaviours as an instantiation of the class with both methods and attributes.

The story of The Order of Maria Theresa illustrates the final theme: there is no culture. Or, more precisely, there are many cultures and no single culture. The core beliefs and values of the station team were very different from the core beliefs and values of the parent corporation. Again, this isn’t a new idea. The post-modern critique of culture says that it is far from a shared, monolithic set of shared beliefs, values, and norms within a society.

Cultures are inherently disparate and within a society or organisation: there is usually tension and often direct conflict in norms, beliefs, and values within an organisation.

In a different domain, Geert Hofsteder has spent his career investigating the impact of national cultural differences on corporate culture — initially within IBM. Within Agile — in particularly within Scrum — there is a clear understanding that each team needs to develop its own norms to support the team’s behaviour. Our analogy breaks down even further — but we might think of an application built with different classes using different languages, different data types, and different API models all working together.

Four Lessons About Culture

I’ve explored four definitions of culture: culture as the glue that defines society; culture as the dynamic function that creates society; culture as a multi-level phenomenon, founded on values; and that culture is diverse and often fragmented. This exploration has only scratched the surface of theories of culture but provides valuable insight. The final step is to wrap the theory back in to a more practical understanding of culture by drawing out four lessons.

The first lesson is that culture is adaptive: it helps societies adapt to their environment. Understanding that culture is adaptive means understanding that culture is always changing; it is never fixed and never final. If we think of culture as a river, then culture is found in the flow of the river. The challenge of Agile transformation is not to initiate change, but to shape the cultural change that is already happening and to recognise that the culture will always be changing. In a very real sense, an agile transformation is never finished.

The second lesson is to look further into the shape of culture. Anthropology draws attention to the importance of language, symbols, and ceremonies to culture and that we communicate culture through stories. Culture is not just the river itself, but it is defined by the banks and the rocks of the river. This resonates well with the emphasis in Scrum of the events as rituals and the insistence in the Scrum Guide of maintaining consistency in the language to name roles and events.

The third lesson is that culture has multiple levels and change needs to address all levels. The real lesson here is the counterpoint to the previous lesson. While language is important, it’s not sufficient: not all of the forces that shape the river are visible; much of it is hidden deep beneath the surface and exists in the minds of individuals. A team can adopt the language and rituals of agile but miss the deeper level of culture change — leading to Agile In Name Only.

The final lesson is that culture is naturally fragmentary: within organisations and even within teams, there are divergent behaviours and beliefs. This fragmentation is part of the tension through which culture changes as each group, and even each person, adapts to their local situation. A river consists of multiple currents and tributaries; it is shaped by forces ranging from gravity, climate and geography through to the location of pebbles in the riverbed. Because fragmentation is natural, the right answer isn’t to prevent fragmentation but to use the natural fragmentation to help drive change. In agile, teams are encouraged to develop their own norms that work for that team.

In this post, I have dug into the concept of culture. I reviewed four views of what culture is, all elaborating on different aspects of culture while steering clear of the content of culture, and focusing instead on its nature at the collective level. From these views, I’ve extracted four lessons — understanding the importance of culture as a dynamic process, focusing on language and symbols, attending to the different levels of culture, and accepting the fragmentary nature of culture. In the first post, I made the case that Agile is Culture; in this post, I scanned different views of culture and linking it to Agile. In the next post, I’ll turn my attention to approaches to change management, connecting the individual to culture and applying the approaches to agile. I’ll then look to leadership, before looking at agile coaching in more detail.