Posted on

Medication

If you check out the Agile Manifesto, you find that we often medicate with the things listed on the right in the Values section.

Medication is usually in the form of a pain killer of some kind. The whole right side of the Agile Manifesto lists various forms of medication that enterprises, departments and teams use to relieve various forms of pain.

Examples of pain-killing medications:

  • Processes and Tools
  • Comprehensive Documentation
  • Contract Negotiation
  • Following a Plan

Lets look at each in turn:

Process and Tools

We medicate away from facing [Individual and Interactions] by focusing on processes and tools. We focus on these, and way from [Individual and Interactions] because we might have to get real and face the reality of people and interacting with them. We might have to get some new social skills! Ouch, that smarts. Where are my pills?

Comprehensive Documentation

This usually manifests as the need for “perfect” and “comprehensive” requirements. We medicate with these, and avoid dealing in the reality that what we must create is [Working Software]. We focus on perfection in requirements, and away from STARTING. Starting is risky and who knows what might happen? The reality is we cannot learn till we pay attention, and we do not pay attention till we start. Got that? OK, so START NOW with your imperfect non-comprehensive requirements. It’s going to be (perfectly) OK.

Contract Negotiation

OK, OK we need to know what to build. I agree. Let’s also agree that it is unreasonable to expect everyone to know exactly what they want, 100%, at the start of the process. We focus on contracts instead of [Customer Collaboration] because this stuff is hard. So, we medicate with the contract. It gives a sense of control, see? That stops the pain of dealing with what is in fact an uncontrollable, increasing complex, high-change world.

Following a Plan

“Planning” usually shows up as “prediction-in-drag”:  in effect, a wild-ass guess masquerading as planning. If prediction is so very easy, why isn’t everyone a stock market winner? See it? Prediction is difficult… and way over-rated. Plans are great and we need a direction … and a general way to move in that direction. But let’s not pretend we can predict very much at all. Instead, let’s [Respond to Change]. Ouch, that hurts because I might have to change my beliefs to address any really unusual changes. I might have to re-factor my model of reality.

That’s a whole lot of hard work, making edits to what I currently believe.

Ouch, that smarts. Where are my pills?

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.