Posted on

Tacit vs. Explicit Knowledge

Explicit knowledge is knowledge that you can get out of a book, or a video, or a web page. It is A-B-C, 1-2-3, step-by-step knowledge. This is the knowledge found on Wikipedia, and similar resources like user guides, user manuals, and other books. This is the knowledge most of us understand from school, and other formal learning.

Tacit knowledge requires proximity and experience. It is not readily converted into book form. Knowledge about how to make sausage is a good example. You learn to do it by watching and by doing. Usually, you need a little coaching. It requires that you are communicating with someone that is watching you and coaching as you gain experience and competency.

On teams that build complex products, much of the team knowledge is of this tacit type. Having proximity to the engineers and testers, and listening and watching others who are competent in the craft is how you learn here. It is like watching sausage being made. Difficult differences and unsightly mistakes are part of the recipe in tacit knowledge creation.

Knowledge creation, like sausage making, can be difficult to watch.

 

 

Usually, substantial knowledge is held by the people in a team, the tribe or the enterprise. The knowledge– technical and cultural– is tacit.

A culture is this very real thing, yet it defies description. When you are in it, you are of it, and it affects you, and you get it. Yet it is hard to describe in writing or even to verbalize. The culture of a team, tribe or organization is the set of assumptions, the set of beliefs that are collectively held. It is not easy to reduce this to explicit knowledge.

You must “go to the gemba”, and visit, and get proximity to get a feel for what a team believes and understands about itself. Even then, explaining it accurately to someone else is tough.

In my book The Culture Game, I document a step-by-step, explicit-knowledge framework for scaling Agile, from teams to tribes. The book is intended as an A-B-C,  how-to manual, for the typical manager in the typical organization who wants to spread the essence of Agile. That essence is organizational (what I call tribal)  learning.

 

Posted on

Punctuality and Scrum Values

Ken Schwaber’s book Agile Software Development Using Scrum has a section on Scrum values and explicitly lists five. They are Focus, Commitment, Courage, Openness and Respect. If you poke around on this blog you can find some writing I have done on these in the past.

Many organizations cannot do genuine and authentic Scrum. Why? Often, the reasons are the same reasons these organizations in general cannot execute on genuine punctuality. I notice that genuine and authentic punctuality instantly supports 3 of the 5 Scrum values: Focus, Commitment and Respect.

At a company where I am currently coaching, a VP-level leader implemented a voluntary opt-in Punctuality policy. You opt-in to the commitment. The policy is that if you are late, you pay $1 as a symbol of the culture valuing punctuality. Paying the $1 is an act that de-values tardiness;  it de-values “being late”.

An interesting set of dynamics immediately kicked in. There were many questions about ‘edge’ cases. First the definition of ‘late’ needed to be clarified. We discovered that the clocks throughout the building were all depicting incorrect times. These were synchronized. It was discovered that some clocks were slow and drifted to incorrect times after a few days. So a policy of using the time as depicted by the corporate network was used as the reference time.

Next the question of 1 second late came up, is this really ‘late’. 2 seconds etc. It was discussed and decided, yes, 1-2 seconds late is really, really late. being a bit early is the best policy, and encouraged.

Next the issue of ‘commuting’ from meeting to meeting came up. The operation spans several floors and each floor has like 20,000 square feet. So a policy of shortening meetings from 60 to 55 minutes was discussed.

But, since not everyone opted-in to valuing punctuality, this policy change was not simple to socialize throughout the organization and remains a problem to this day.

Next, the issue of meeting invites via Outlook scheduling was addressed. If you are invited to an Outlook meeting, the options are [Accept], [Decline] and [Tentative]. If you do not [Decline], are you obligated ?  This is an example of a fuzzy boundary and status. The issue was discussed.

A policy was defined that if you are invited, and do not explicitly decline, you are obligated to attend– on time. A policy about using [Tentative] was then defined.

As you can see, explicit examination is required for clarity in even the simplest policy definition for entire groups of people. It turns out that ‘simple’ punctuality is really not so simple after all.

Punctuality supports 3 of the 5 Scrum values: Focus, Commitment and Respect. These values associate with greatness in organizations. To be great, be great at being punctual.

It ain’t as easy as it looks. If your organization is not Punctual, you probably cannot do genuine and authentic Scrum. If on the other hand your culture strongly values Focus, Commitment and Respect, both Punctuality and Scrum are probably very simple to implement. At issue is “alignment” …..on “values”. These are very important concepts to grasp, for all organizations that intend to be great.