In digital terms, culture is an application platform consisting of a core operating system kernel and associated components, modules and low-level applications. This implies We can hack culture by screwing with these cultural platform elements.
The operating system, components, modules and low-level applications of culture are actually our stories and narrative. Thoughts become things, and stories are highly organized, memetic compositions of related thoughts. Stories are culture-things with structure and content. Changing culture is an exercise in selectively hacking specific stories– the essential modules and components that constitute the core cultural platform.
Computer programs are written in a programming language. The programs are stored on digital media. Cultural programs– stories– are written in a natural language. The stories are stored in your head. The stories are the cultural software in your head. The language you use determines how the stories can be told.
Well understood stories get memorialized in writing– in language. Languages have a vocabulary, a syntax, and some rules and conventions. Modifying language is a way to make a change (to refactor) all the stories in that language. To hack culture, hack the stories. The most efficient way to hack all the stories (at global scope) is to hack the language.
There is a rule in English that says We capitalize “I” and not “We”. This implies “I” is more significant than “We”. Anyone can chose to capitalize We. In so doing, “We” gets on an equal footing with “I” in sentences composed in the English language. By capitalizing We, the signal in writing is that “We” is at least as big, and as important, as significant, and as valuable as: “I”.
“We” is just one example. Anyone can choose to hack language and see what happens. If that language hack of yours comes into widespread usage, the language changes globally. As language goes, so goes story and narrative. As story goes, so goes the culture.
To hack your culture, hack your language.
Story and Language: Why Do You Care?
Language is the code of culture.
Stories and narratives are core, platform applications that execute the cultural operating system. Repeat: The culture is the operating system, composed of the stories– the core applications. The language is the code used to create these core ‘applications’. If you have no stories, you do not have a culture.
Dave Logan has all this covered in TRIBAL LEADERSHIP. You listen to the language- the code– of the stories you hear. That tells you the level of the culture. The level dictates what the culture can aspire to. What it can do.
What it is capable of doing. And being.
Example. You show up. People are talking in ‘We’ language and telling ‘We’ stories. That’s a tribe that can dominate their market space. That’s a tribe that can get to Stage 5 in the TRIBAL LEADERSHIP stage development model of culture. This Stage 4 tribe has the capacity to reach Stage 5 and be world-changing.
Another example. You show up and people are speaking ‘I’ language. The stories are all heroic in nature. He did this, she did that. I think this; I do that. Hear it? That’s Stage 3 culture. “I am great. (You are not.)”
This culture can function in a minimal way. It cannot change the world.
To change the culture, change the stories people are telling. There are many ways to do this. It’s not a trivial task. I explain some specific techniques in THE CULTURE GAME book. When you change culture, you change the stories. This is an axiom that does not change.
The culture is the operating system.
The stories are the core components and core applications that make up the operating system. They encapsulate what the culture means. This operating system is composed of stories.
The language is the high-level (story) programming medium.
Last thing: recall that the best computer programmer is up to 10X better than the average. This is ALSO TRUE for those who ‘code’ stories.
Interested in culture? Wise up about story. There is no better place to start than the web site www.GetStoried.com. That site has a boatload of tips, techniques and specific guidance on how to leverage narrative. The individual responsible for that site has PLENTY to teach you.
Michael Margolis is a brilliant man who knows more about narrative than ANYONE I know.
Tell him Dan sent you, and that you want to know how to get a bigger story.
Everything is framed by language. Change the language and you are changing the game. This is as aspect of culture covered in my book, The Culture Game.
Naming things makes sense of the world, yet it can be bad for teams. Ironically, naming things reduces the flow of We. That is because the names are literally symbolic of things. Names create very real divisions.
Nominalization is one way we make sense of things. Nominalization assigns names to things and reduces them to nouns. Nominalization is a linguistic device that allows you to turn a verb (and other word types) into nouns. It’s a trap that can limit perception and thinking at the level of We. Nominalization creates opportunities for division to occur. For example, this cannot be that if this is not(that). I am describing the divisions: these divisions reduce the flow of We. Nominalization creates linguistic (and therefore very real) division inside the mind of groups.
On the other hand, anything that increases the flow of We is insanely great. Some specific, named socio-technologies that help do this include:
- Core Protocols
- Open Space
There are others like these; I have a name for them as a group.
When I tell you the name, it is sure to reduce the flow of We in the community of readers. Why?
Because as soon as I divulge the name, then the discussions start, describing: how this is not that, how this is inferior to that, how that is crap compared to this, and so on. Eventually, I have to tell you the name, so We can talk about it. There is no other way. I plan to wait until at least a few people comment on this post, to get the ball rolling. That is the signal I am waiting for. If I do not get any comments, that is my signal to wait. See also: semiotics.
Kanban and Scrum are Verbs, Not Nouns
Is it just me? The Kanban community folks appear to encourage and be fond of bashing Scrum. This is unfortunate since the Kanban and the Scrum are so closely related. These are not distant cousins but rather, brothers. They both encourage a generative flow of We.
Positioning Kanban as superior to Scrum and vice-versa is contributing to a sense of meaningless around the word Agile. Agile is beginning to mean “whoever had the biggest ego and yells loudest. Whoever can grab the socio-apparatus of the Agile community (The Scrum Alliance, Agile Alliance, the conferences etc) to steer them. Whoever can advocate their position even louder and more convincingly.”
Exhibit A is the artificial debate between which is better for Agile teams: Kanban or Scrum. Yes, Scrum fails in some organizations and does not create much improvement in results. Kanban also suffers from these failures, typically in the same organizations.
In general, any failures of either are related to the culture in the implementing organization. In either case, Scrum and/or Kanban, the organizations doing the implementation need pain-killing drugs (commonly called a prescription) and a doctor (commonly called a coach). If they do not need a prescription or a doctor (to help them heal) they’d already be healthy, right?
Language is the Key
In the post The Flow of We I discuss nominalization, the act of changing verbs and adverbs (and other kinds of words) into nouns. Click the link to learn about it. We all do it all the time. It creates space to compare, contrast, disagree, and debate. Naming people, places and things is the primary way we make sense of the world we live in.
Scrum and Kanban are most useful to us in the English language when referred to as verbs, not nouns. We Scrum, and we Kanban. When we Kanban, We pay attention to the flow of work items through our group. We work with upstream and downstream partners to increase the flow of value. When We Kanban we increase the flow of We, by paying attention, as a group, to things that matter, like work items, classes of service, cycle times etc.
Likewise, we Scrum. When we Scrum, we first agree to some basic understandings, about roles and meetings and rules. Then We Scrum. When We Scrum, We open conversational space to discuss the actual details of requirements. We time-box most of these discussions. After We do some work, We reflect formally during a meeting We call “the Retrospective”. We also timebox this meeting.
Scrum is a verb. We Scrum. Kanban is a verb. We Kanban.
The Kanban community already realizes this, well below the level of collective awareness. What, you disagree, and do not think so? Guess again.
Check out this poster and slogan again, it says:
[Yes] … we Kanban. THAT is using the word Kanban as a VERB.
Post Script: 3 hours later, I already got three emails on this from folks out there. Moral of story: language matters.
Scrum Language: the term Scrum “Master”
Here is something I get a lot when doing Agile coaching: I hear comments about Scrum terms and words. One of them is ‘Scrum Master’.
‘Master’ associates with acquisition of complete knowledge or skill. However, ‘master’ also associates with:
- One having authority over another
- One that conquers
- One having control, especially over a slave or animal, also the employer of a servant
People who know Scrum know that the Scrum Master is supposed to be a servant, a servant-leader.
And that is the problem. Language frames reality.
Here is a term that refers to a servant as a ‘master’. I understand that Jeff and Ken mean the other kind of master, the master of a skill called Scrum. However, not everyone hears it that way. I know because I get comments on this matter and questions, all the time from Agile coaching clients new to Scrum. They are hearing “authority over”, “control over a servant”, etc.
Language matters !
Are you getting these comments and questions about the term ‘Scrum Master’?
Let me know.