#acl +All:read

[[책/함께 자라기]]의 2부. 

 * 1부는 [[../자라기]]
 * 2부는 [[../함께]]
 * 3부는 [[../애자일]]


= 2. 함께 =

초기에는 대상에 대한 지식이 거의 없으니 일을 제대로 나눌 수가 없다. 사실 일을 가장 잘 나눌 수 있는 때는 프로젝트가 완료되는 시점이다. 사람들은 협력이 중요하다고 말한다. 그래서 프로젝트를 할 때 협력적으로 하자고 한다. 그러나 실제 모습을 들여다보면 초반에 일을 세밀하게 나누고 선을 긋는다. 그리고 안녕. 각자 진행하고 나중에 만나서 서로 합쳐본다. 그 속을 들여다보면 협력은 거의 없다.

우리는 협력을 제대로 배워본 적이 거의 없다. 그래서 지금부터라도 협력 방법을 배우고 수련해야 한다.


== 소프트웨어 관리자의 개선 우선순위 ==

조엘 테스트라는 12가지 질문이 있다.

=== 12가지 질문이 개발팀 평가에서 정말 중요한 요소인가? ===

GeraldWeinberg 는 소프트웨어 개발을 잘 관리하려면 세 가지 근본적 능력이 필요하다고 했다.

 1. 복잡한 상황을 이해하는 능력으로, 프로젝트를 계획한 다음 관찰하고 행동하여 계획에 맞게 프로젝트가 진행되게 하거나 계획을 바꿀 수 있어야 한다.
 2. 관찰하는 능력으로, 무엇이 벌어지고 있는지를 관찰하고, 효과적인 적응 행동을 하기 위해 자신이 관찰한 것이 어떤 의미인지 이해할 수 있어야 한다.
 3. 행동하는 능력으로, 어려운 대인 상황에서 우리가 심지어 혼란스럽거나 화가 나거나 아니면 무서워서 도망쳐 숨어버리고 싶을 때에도 적절하게 행동할 수 있어야 한다.

그가 쓴 [[QSM]]의 제목은 아래와 같다.

 1. 시스템적 사고 (Systems Thinking)
 2. 일차적 측정 (First-Order Measurement)
 3. 일치적 행동 (Congruent Action)
 4. 변화를 기대하기 (Anticipating Change)

1,2,3권은 앞서 말한 필수 능력 세 가지와 순서대로 들어맞는다. 마지막 권은, 이 세 가지 능력을 활용해 실제 조직과 개인(관리자 자신을 포함한다. 와인버그는 자신을 바꾸지 못하는 사람은 다른 사람을 바꾸는 일도 할 수 없다고 말한다)을 어떻게 바꿔나갈 것인가를 다룬다.

소프트웨어 개발 비용을 결정하는 요소는 무엇일까?

 * 도구
 * 사람
 * 시스템
 * 관리

GeraldWeinberg는 베리 보엠의 연구에서 아래와 같이 각 요소의 영향을 도출해냈다.

 * 도구: 2.97배
 * 사람: 10.55배
 * 시스템: 25.76배
 * 관리: 64.00배

관리자들이 선호하는 개선 노력은 어떤 순서일까? 정확히 역순이다. 일단 도구 개선부터 시작한다. 자기 자신(관리)을 바꾸는 것은 맨 나중이다. 하지만 실제 효과로 보면 우선순위는 관리가 맨 처음에 온다.


== 협력을 통한 추상화 ==

=== 커뮤니케이션과 협력 ===

=== 백지장도 맞들면 찢어진다? ===

=== 톱니바퀴 실험 ===


둘이서 협력하여 작업하면 서로 시각이 다르기 때문에 두 사람의 다른 시각을 연결해 줄 다리가 필요하고, 그 다리에는 필연적으로 추상화의 요소가 있게 된다. 서로 다른 것들을 하나로 묶어야 하기 때문이다. 반면 혼자서 작업할 경우에는 이런 추상화의 필요가 덜하다.

=== 추상화의 중요성 ===

소프트웨어 공학의 역사는 추상화를 높이기 위한 여정이었다. 그런데, 그 추상화를 높일 수 있는 방법 중 하나가 바로 '다른 시각을 가진 두 사람이 협력하기'이다.


=== 대화하는 프로그래밍 ===

짝 프로그래밍은, 대화를 통해 추상화를 높이게 하고, 하나의 컴퓨터를 사용한다는 점은 그것을 구체화를 통해 검증하게 한다. 구체와 추상이 빈번히 교차한다. 그리고 그 사이에서 '아하'가 터져 나온다.

자신이 작성하는 코드의 추상성을 높이고 싶다면 혼자서 고민하지 말고 다른 사람들과 협동하고 대화하라. 같이 그림도 그려보고 함께 소스코드를 편집하라.


== 신뢰를 깎는 공유인가 신뢰를 쌓는 공유인가 ==

신뢰 자산이 높은 조직은 커뮤니케이션 효율이나 생산성이 높다는 연구가 많이 있다. 신뢰 자산이 높다는 것은 조직원들 간에 높은 수준의 신뢰가 기반되어 있는걸 말하며, 그 신뢰가 줄거나 늘 수 있음을 암시한다.

어떻게 신뢰를 쌓을까?

널리 사용되는 한 가지 방법은 투명성과 공유, 인터랙션이다. 그런데 그렇게 공유하고 소통하면 신뢰가 쌓일까?


=== 공유 조건별 신뢰도 변화 실험 ===

공유의 세 가지 셋팅을 생각해보자.

 하나 공유(share one):: 하나의 결과물을 만들고 하나를 공유하게 함
 최고 공유(share best):: 같은 시간 동안 여러개의 결과물을 만들고, 그 중 자신이 가장 잘 했다고 생각하는 것을 골라서 공유하게 함
 복수 공유(share multiple):: 각자 여러 개의 결과물을 만들고 그걸 모두 공유

하나 공유나 최고 공유가 아마 우리가 흔히 하는 공유 방식일 것이다. 그런데 이 방식은 하고 나면 신뢰가 더 떨어진다. 왜? 이 방식의 경우, 우리는 공유 자리에 기대감보다는 불안감을 갖고 가곤 한다. "상대가 이걸 보고 흉을 보면 어쩌지?" 그리고 그럴 경우 어떻게 방어적으로 대응해야 할지도 대략 생각해두게 된다. 또한, 상대의 시안에 대해서도 솔직한 의견을 내리는 것을 꺼리게 된다. "내가 한 말을 듣고 나를 싫어하면 어쩌지?" 나의 작품이 하나밖에 없으니 '작업물=나'가 되는 것이다. 나름 방어를 해낸다고 해도 자기효능감이 떨어지기 쉽다.


=== 복수 공유의 장점 ===

반대로 복수 공유는 그런 불안감이 상대적으로 덜하다. 또 부정적 피드백을 수용하려는 마음도 더 많다. 여러 개를 준비했으니 그 중 하나를 두고 뭐라고 해도 나에 대한 공격은 아니다. 또 여러 개이니 상대적으로 이야기를 할 수 있어 말하는 사람도 편하고, 듣는 사람도 좋다는 이야기와 안 좋다는 이야기를 같이 들으니 (A안은 이게 좋은데, B안은 이게 안좋고) 마음이 좀 더 편하다.

그리고 복수 공유는 성과도 더 높았다.

경영자나 관리자들은, 그냥 공유만 하게 한다고 신뢰가 저절로 쌓이는게 아니라는 것을 이해하고, 또 그렇다면 어떻게 공유하게 할 것인가 하는 고민을 해볼 수 있겠다.


== 객관성의 주관성 ==

팀장 자리에 있으면 새로운 아이디어 전파가 쉬울 것이라고 생각하는 것은 [[http://agile.egloos.com/5159056|환상]]이다. 그렇다면 주위 사람들을 어떻게 설득해야 하는가? 어떻게 해야 설득할 확률을 높일 수 있는가?

=== 품질은 상대적이다 ===

=== 감정을 배제할 수 없다 ===

다마지오(Damasio. A)와 그의 동료들은 감정과 의사결정을 연결하는 특정 뇌 영역에 손상을 입은 환자들을 연구했는데, 결정과 관련된 인지적 작업에서 문제가 있었다. 식당을 고르는 것 같은 사소한 결정도 엄청나게 고민했고 시간도 오래 걸렸다.

우리는 의사결정을 하는 과정에 감정적이고 직관적인 부분이 큰 열할을 하고 있고, 그런 감정적 부분이 배제된다면 의사결정을 제대로 할 수 없다.

=== 성향과 기질에 따른 애자일 설명법 ===

결국, 내가 설득하려는 대상도, 결정을 내기는 과정에서 감정이나 직관 등, 객관적이지 않은 과정을 거친다. 그렇기 때문에, 상대방을 이해하고 상대에 맞게 설득해야 한다. KAI 성향이나 [[MBTI]] 등을 활용할 수도 있겠다.


== 이것도 모르세요? ==

=== 공감하고 이해하려는 대화 ===

=== 행동을 유도하는 대화 ===

한 팀은 서로 잘 물어보지 않고, 물어봐도 '이것도 모르세요?'의 수준으로 대답해 준다. 반대로 다른 팀은 서로 [[코칭]]을 해주면서 함께 동기와 의지를 북돋워주고 같이 고민해준다. 어느 팀의 사람들이 성장할까?


== 하향식 접근의 함정 ==

우리는 일종의 미신을 가지고 있다. "전문가는 언제나 탑다운으로 깔끔하게 생각할 것이다"라는 믿음이다.

탑다운은 문제 해결 과정을 시간의 흐름에서 볼 때 추상적인 숲에서 출발해서 점점 나무로 내려오는 접근법을 말한다. 그 반대라 할 수 있는 바텀업은 나무에서 출발해서 숲으로 올라오는 과정이다.

탑다운은 더 깔끔해 보인다. 바텀업은 탐색적인 성격이 많다. 여기저기 찔러보고 방향도 바꾸고 한다. 이런 면에서 사람들은 전문가일수록 탑다운으로 사고하고 문제를 해결할 것이라 믿는다. 그리고 실험실 연구에서도 비슷한 결과가 나왔다.

그러나 전문가들은 자신이 자주 접하지 않았던 문제, 어려운 문제, 혹은 잘 정의되지 않은 문제를 접하면 접근법을 바꾼다. 탑다운과 바텀업을 섞어서 쓴다. 뛰어난 전문가일수록 그렇다. 비전문가는 현재 문제가 나에게 얼마나 어려운가에 대한 인식이 부족하며 자기의 문제 풀이 전략을 상황에 맞게 능동적으로 선택하거나 변경하지 못한다. 오히려 탑다운이나 바텀업 중 한 가지에만 억지로 집착하려고 한다. '이번 문제는 복잡하니까 더 철저하게 계획하고 설계해야겠다'와 같이.

하지만 우리는 전문가는 탑다운으로 문제를 푸는 사람이라는 고정된 이미지를 갖고 있다. 게다가 이런 믿음을 협력 방식에까지 확장한다.

기업에서 일하는 방식도 통상 이 탑다운 모형을 따른다. 전문가가 탑다운으로 일하니, 조직도 탑다운으로 일해야 한다는 단순한 생각의 흐름이다. 대부분의 기업에서 직원 숫자가 늘어나기 시작하면 추상 층위에 따라 팀을 나눈다. 각 층위의 전문가 팀이 존재한다. 기획팀, 구현팀, QA팀 등. 그리고 일이 진행됨에 따라 팀 간의 바통 터치가 이루어진다. 위에서 아래 방향으로.

한 연구에서는, 엘리베이터 시스템 설계자들을 모아놓고 그 사람이 설계할 때 사고 수준이 시간 흐름에 따라 어떻게 변화하는지 실험했다.

전문가들은 추상과 구상을 오르락내리락 했다. 특히 '아하 순간'은 방향이 꺾이는 지점에서 왔다. 뭔가 설계에 기똥찬 개선이 이루어지는 순간이었던 것이다.

엘리베이터 설계에서 추상성이 높은 것은 알고리즘이나 기능 등이 될 테고, 추상성이 낮은 것은 모터의 가속도 제어나 회로 차원일 것이다. 전문가는 추상성의 정도를 오르락내리락거리고, 특히 탑다운과 바텀업의 방향이 전환되는 시점들에서 '아하 순간'이 찾아왔다.

하지만 우리는 종종 이렇게 말한다. '이번 일은 복잡하고 불확실하니까 철저하게 계획하고 단계적으로 접근하자!'. 이 말은 곧, 이번 일은 불확실하니까 초보처럼 일하자는 말과 똑같다.

조직 내에 모든 레이어를 꿰뚫는 전문가가 있으면 좋겠으나 많은 경우 그런 사치를 부릴 여유가 없다. 다루는 문제가 점점 복잡해지면서 팔방미인은 희박해지고 몸값은 치솟는다. 그러면 그 (한 사람이 그 역할을 하는) 대신에, 밖에서 그 조직을 관찰했을 때 마치 그 속에 모든 층위를 꿰뚫는 전문가가 있는 것처럼 만들 수는 없을까?

하지만 현재 통상적인 기능적 팀 구분에서는 이런 효과를 내기가 어렵다. 바통 터치가 너무 자주 일어난다. 그러면 주고 받는데서 생기는 오버헤드가 과도하게 커진다.

 * 한 사람이 다기능을 갖추도록 ([[http://agile.egloos.com/1932595|참고]])
 * 협력이 쉽게 되도록

전자는 바통 터치가 덜 필요하게 만드는 것이고, 후자는 한번 바통 터치하는데 드는 비용을 줄이는 것이다. 재미있게도 후자를 잘 하다 보면 전자가 자동으로 좋아진다. 반대로 전자를 잘해서 후자도 잘 되게 할 수도 있으나, 후자가 잘 되지 않으면서 전자가 잘 되게 하기는 어렵고 비용이 크다.


=== 빠르고 빈번한 바통 터치가 가능한 전문가 조직 ===

오버헤드를 낮추려면 협력 모델이 바통 터치 모형에 기반하지 않고 삼투압 모형에 기반해야 한다. 사실 바통 터치 비용을 극도로 줄이다 보면 삼투압 모형으로 가게 된다. (AlistairCockburn이 뛰어난 팀에 대해 관찰한 바와도 같다.)

삼투압적 의사소통은 '배어드는' 소통방식이다. 서양의 의사소통 모형은 대체로 화살 모형을 따른다. 발신, 수신인이 정해져 있고, 화살을 쏘는 것이다. 삼투압적 모형에서는 은연중에 서로 간에 정보가 스며드는 것이다.

그렇게 하려면 사람들이 물리적으로 가까운 거리에 있어야 유리하다. 예를 들어, 프로그래밍하다가 '저기 이거 뭐뭐 안되는데 아는 사람 있어요?'라고 외친다. 테이블 건너편에 있던 디자이너가 답을 해준다. 옆에 앉아 자기 일을 하던 기획자는 프로그래머 둘이 하는 대화를 우연히 듣는다. 그러다가 '아, 그런 문제가 있었나요? 저는 어쩌구...'하면서 끼어들어 새롭고 가치 있는 정보를 준다.

그리고 한번에 처리되는 일의 양(batch size)를 줄여야 한다. 배치 사이즈를 줄여서 지속적 흐름(continuous flow)를 만들고 짧은 시간 내에 탑, 바텀을 오가게 한다. 예를 들어 전에는 디자이너가 100개의 일거리를 다 처리한 후에 한꺼번에 모아 결과를 전달했다면 점차 50개로, 10개로, 1개로 낮추어야 한다.

이 아이디어를 웹개발 쪽에 적용한다면 어떻게 될까?

제시 제임스 개럿(JesseJamesGarrett)의 저서 '사용자 경험의 요소'에서는 웹개발에서 추상화의 단계를 다섯 면(plane)으로 나눈다.

 * 전략 (strategy)
 * 범위 (scope)
 * 구조 (structure)
 * 뼈대 (skelecton)
 * 표면/비주얼 (surface/visual)

우리가 전문가의 이미지를 잘못 가지고 있다면 전문가가 다음과 같이 일을 처리하리라 생각하기 쉽다.

'전략이 깔끔히 완료되고 나서야 범위(무슨 기능이 들어갈지 결정)를 정하고, 다음에 구조(기능들을 어떻게 연결할지, 흐름은 어떻게 될지, 사이트 구조 등)를 정하고, 거기에서 뼈대(화면에 어떤 요소들이 대략 들어가야 하는지, 배치는 어떤지)가 나오고, 마지막에 이르러서 비주얼 디자인에 도달할 수 있다'

하지만 사실은 이와 다르다. 더 높은 품질을 얻기 위해서는 이 사다리를 오르락내리락 반복하는 것이 필요하다. 어느 한 단계를 한 번에 완료하는 것은 더 낮은 품질로 가는 지름길이다. 특히나 문제와 해결책에 불확실성이 높을 경우.

흔히 말하는 개발의 5단계도 비슷하다. 분석, 설계, 구현, 테스트, 전개를 1년이라는 프로젝트 기간에 얼마씩 배치할까로 고머니하지 말고, 어떻게 해야 첫 달부터, 아니 첫 주부터 분석, 설계, 구현, 테스트, 전개를 모두 왔다갔다 할 수 있을까를 고민해야 할 것이다.

그리고 이렇게 일하기 위해 우리 조직은 어떤 종류의 협력을 해야 할지를 생각해 봐야 할 것이다.


== 전문가팀이 실패하는 이유 ==

사업을 하는 사람들이 흔히 버스에 사람 태우기라는 메타포를 이야기하곤 한다 (JimCollins가 GoodToGreat에서 한 말인데, 위대한 기업에서는 버스에 적절한 사람 태우는 것이 우선이고 어디로 갈지 정하는 건 그 다음이라고 말한다). 그리고 이 메타포를 사용하는 사람의 상당수는 '뛰어난 사람'을 뽑는 것이 얼마나 중요한가를 말하기 위해 이 비유를 든다. 그들에게 있어 뛰어난 사람은 해당 전문 분야의 뛰어난 사람을 의미한다.

그러나 뛰어난 사람을 뽑아두면 어떻게든 잘 할거라는 사고가 지나치게 낙관적인 기대일 수 있다.

스포츠맨들은 '올스타팀'이라는걸 잘 알고 있을 것이다. 그런데 올스타팀의 성적이 그다지 인상적이지 못하다는 점은 대개 동의할 것이다.

그로이스버그 등의 연구에 따르면, '이런 스타들이 한 명씩 팀에 추가될 때마다 팀의 추가적 성과 향상은 한계효용을 보이며 어느 수준을 지나면 음의 방향으로 작용한다'고 한다. 게다가, 올스타틈을 만드는데 드는 비용까지 고려하면 더 심각한 결과가 나올 것이다. 이렇게 전문가가 추가되는게 도움이 안되거나 오히려 성과를 깎아먹는 경향은 특히 전문가들의 전문성이 서로 유사할 때 도드라졌다. 그 원인 중 하나로 전문가들의 에고(ego)를 꼽는다.

그러면 해결책은?

울리(Woolley) 등의 연구를 보면, 아래와 같은 상황에서 실험을 했다.

 1. 전문가, 협력 개입
 2. 전문가, 협력 비개입
 3. 비전문가, 협력 개입
 4. 비전문가, 협력 비개입

협력을 고취하기 위해 10분간 개입하지 않고 자기들이 알아서 하게 놔둔 전문가팀은 ''비전문가로만 구성된 팀보다도 훨씬 못한 결과''가 나왔다. 단순히 전문가들을 모아둔다고 해서 높은 성과가 나오지 않았따. 이런 경향은 필요한 협력의 정도가 높은 일일수록 도드라진다.

왜 이런 차이가 났을까를 분석했더니 그 원인은 정보 공유의 차이에 있었다. 협력 개입이 된 경우, 팀원들은 정보를 공유해서 더 통합된 해결책을 제시했다. 반면에 협력 개입이 없으면 결과물은 서로 모순되는 등 통합되지 못했따 (소프트웨어 개발로 치자면 각 모듈이 제대로 통합되지 않고 충돌하는 것이다). 분야 전문가들이라고 해서 무조건 협력을 잘하는게 아니다.

논문에서 저자들은 이렇게 말한다.

  이 결과는 팀에 작업 관련 전문가가 포함되는 것과 ''동시에'' 각 멤버의 작업을 조율하고 통합하는 전략을 팀이 드러내놓고 탐색하는 경우에 팀의 분석 작업이 가장 높은 수준의 효과성을 보인다는 것을 시사한다.

  협력 계획하기라는 개입을 받지 못하고 전문가들이 포함된 팀은 다른 팀보다 더 못한 성과를 보였다. 이것은 멤버들이 전문가의 특별한 재능을 사용하도록 도움을 받지 않는다면 전문가 멤버들의 존재가 사실은 팀의 효과성을 떨어뜨릴 수 있다는, 기대를 거스르는 가능성을 제시한다.

이에 더해, 분더슨 등의 연구에서는 팀 내에 개인 내 다양성(intrapersonal diversity)이 높은 멤버가 없다면 전문가로 구성된 팀은 정보 공유가 잘 안되어서 성과가 떨어질 수 있다는 분석을 했다. 여기에서 개인 내 다양성이 높다는 것은 다양한 분야를 경험한 제너럴리스트 같은 사람을 뜻한다. 이 연구도 앞의 울리 연구와 같은 맥락으로 볼 수 있다.

정리하자면,

 1. 전문가들 모아서 팀 만든다고 (일을) 잘하는 것 아니고
 2. 오히려 성과가 떨어질 수 있고
 3. 정보 공유하고 협력을 잘하기 위한 명시적인 도움이 필요하며
 4. 소셜 스킬 등이 뛰어난 제너럴리스트가 있으면 도움이 된다.


== 구글이 밝힌 탁월한 팀의 비밀 ==

구글은 데이터 기반으로 뛰어난 관리자의 특징을 찾는 [[https://rework.withgoogle.com/subjects/managers/|옥시전 프로젝트]] 이후에도 뛰어난 팀의 특징을 찾기 위해 2년간 노력했다. 이름하여 아리스토텔레스 프로젝트(AristotleProject)이다.

중요한 부분은 세 군데이다.

 1. 팀에 누가 있는지(전문가, 내향/외향, 지능 등)보다, ''팀원들이 서로 어떻게 상호작용하고 자신의 일을 어떻게 바라보는지가 훨씬 중요''했다.
 2. 5가지 성공적 팀의 특징을 찾았는데, 그중 압도적으로 높은 예측력을 보인 변수는 팀의 ''[[심리적 안전감]](PsychologicalSafety)''이었다.
 3. 팀 토론 등 특별히 고안된 활동([[gTeamsExercise]])을 통해 심리적 안전감을 개선할 수 있었다.

1번에 대해서는 직전 쳅터의 '전문가팀이 실패하는 이유'에서 이야기했다.

2번은 실수 관리와도 관련이 있는데, 이는 에이미 에드먼드슨 교수의 책 [[책/티밍]]에서 잘 설명하고 있다. 실수율이 낮은 병원이 좋은 병원이 아니었다고 한다. 발견된 실수율은 해당 조직의 보고 문화와 관련이 깊었는데, 실수율이 낮은 조직은 실수를 적게 하는게 아니라 실수를 공개하는 것이 공격을 받을 수 있는, 그래서 실수를 감추는 조직이었다.

여기서 말하는 [[심리적 안전감]]이란, ''내 생각이나 의견, 질문, 걱정, 혹은 실수가 드러났을 때 처벌받거나 놀림받지 않을 거라는 믿음''을 말한다. 통상 많이 쓰는 에드몬드슨 교수의 측정 도구에는 다음과 같은 질문들이 포함되어 있다.

 * 내가 이 일에서 실수를 하면 그걸로 비난을 받는 경우가 많다.
 * 이 조직에서 남들에게 도움을 구하기가 어렵다.
 * 내 관리자는 내가 전에 한 번도 해보지 않은 걸 해내는 방법을 배우거나 혹은 새로운 일을 맡도록 격려하는 경우가 많다.
 * 내가 만약 다른 곳에서 더 나은 일을 구하려고 이 회사를 떠날 생각이 있다면 나는 그에 대해 내 관리자랑 이야기를 나눌 것이다.
 * 내가 나의 관리자에게 문제를 제기하면 그는 내가 해결책을 찾도록 도와주는 일에 그다지 관심을 보이지 않는 경우가 많다.

직위에 따라 느끼는 심리적 안전감에 통계적으로 유의미한 찾이가 있었다. 직위가 낮아짐에 따라 심리적 안전감이 낮았다. 더 중요한 부분은, 병실에 따라 이 양상이 달랐는데, 어떤 병실은 거의 수평인 곳(직위가 낮아져도 심리적 안전감이 그다지 떨어지지 않는), 어떤 병실은 가파른 경사를 보이는 곳이 있었따.

심리적 안전감이 높은 병실에서는 더 높은 수준의 팀 학습이 이뤄지고 있었다. 또한, 이 병실의 환자들은 18%나 낮은 사망률을 보였다. ([[https://youtu.be/d72rm5iUKqc|에드몬드슨 교수의 발표]])

심리적 안전감을 높이려면 어떻게 해야 할까?
앞에서 언급한 '팀 토론 등 특별히 고안된 활동'을 통해 토론 주제를 안전한 환경에서 이야기하게 해주는 것 자체가 심리적 안전감을 높인다. 단순히 우리팀의 현 상황에 대해 열린 대화를 시작하는 것만으로 변화가 시작될 수 있다.

하지만 이 모든 것 이전에 우선적으로 중요한게 있다. 어떤 새로운 프로그램을 도입하기 전에 리더와 관리자가 매일매일 팀원들과 갖는 마이크로 인터랙션에서 다른 행동 양태를 보여줘야 한다. 일상적으로 벌어지는 인터랙션에는 변화가 없으면서 무슨 토론회 같은 것만 챙기면 오히려 신뢰가 깎일 것이다. 하지만 일상에서의 변화가 생기고, 이런 것으로 신뢰가 조금씩 쌓이기 시작한다면, 위에서 '특별히 고안된 활동'을 시도할 수 있다.

''팀원이 불편한 문제를 제기하거나, 어리석어 보이는 질문을 하거나, 부족한 의견을 얘기하거나, 어처구니없는 실수를 저지를 때 여러분은 어떤 마이크로 인터랙션을 보여주고 계신가요?''


== 쾌속 학습팀 ==

=== 패러다음 전환, 죽느냐 사느냐 ===

=== 최소 침습 심장 수술 ===

=== 학습 속도와 상관없는 것 ===

=== 리더가 팀 학습 속도에 미치는 영향 ===

=== 학습 환경의 차이 ===

=== 기술 전환에 성공한 개발팀 ===

=== 현실에서 실천하기 ===


== 프로젝트 확률론 ==

=== 어디에 돈을 걸 것인가 ===

=== 직관의 허점 ===

=== 이번 프로젝트는 제때에 끝날 수 있을 것 같았는데 ===

=== 애자일 확률론 ===