🌈 Chapter 2: 함께

사람들은 협력이 중요하다고 한다. 그래서 프로젝트를 할 때 협력적으로 하자고 한다. 그러나 실제 모습을 들여다보면 초반에 일을 세밀하게 나누고 선을 긋는다. 그리고 안녕이다. 각자 진행하고 나중에 만나서 서로 합쳐본다. 그 속을 들여다보면 협력은 거의 없다. 이러한 이유는 협력을 제대로 배워본 적이 거의 없기 때문이다.

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

조엘 테스트라는 것이 있다. 조엘 스폴스키라는 사람이 만든 개발팀 평가 테스트이다.

1. 소스 컨트롤을 사용하는가?
2. 한 번에 빌드를 만들어낼 수 있는가?
3. 일일 빌드를 만드는가?
4. 버그 데이터베이스를 가지고 있는가?
5. 새로운 코드를 작성하기 전에 버그를 고치는가?
6. 최신 업데이트된 스케줄이 있는가?
7. 스펙(제품 명세)이 있는가?
8. 프로그래머가 조용한 작업환경에서 일하는가?
9. 돈이 되는 한 최고의 툴을 사용하는가?
10. 테스터가 있는가?
11. 채용 면접 때 후보가 코드를 짜게 해보는가?
12. 복도 사용성 테스트(무작위 사용성 테스트)를 하는가?

이 12가지 항목에 "예"라고 대답하면 "완벽하다"라고 저자는 말한다. 하지만, 이 테스트는 간단하다는 것이다. 각 항목은 객관적으로 금방 예, 아니오의 답이 나올 수 있을 정도로 명료하다. 그러나 여기에 가장 큰 위험이 존재하는데, 선의의 관리자나 경영진이 각 질문의 맥락을 이해하지 못한 채 단순히 12가지 질문에 예라고 답하는 것을 목표로 노력하는 경우를 말하는 것이다. 이런 경우를 문제로 보는 데에는 크게 두 가지 이유가 있다.

🎈 모든 항목에 "예"라고 답하는 것이 무조건 더 낫다고 동의하기 어렵다

가령 8번을 보면, 조엘은 피플웨어(소프트웨어 공학 서적)를 언급하며 조용한 공간에서 일해야 몰입이 가능하기 때문에 8번이 중요하다고 주장한다. 하지만 애자일 콘퍼런스에서 피플웨어의 저자들은 그룹차원의 몰입이 가능하며, 팀원들이 상시 대면 의사소통을 할 수 있는 공간이 생산성 향상에 많은 도움이 된다고 역설한 바 있다.

서로 같은 목표로 일을 하는 팀이 만드는 소음은 그들 사이에서는 더 이상 소음이 아니라고 한다. 무엇보다도, 조용한 작업환경을 강조하다 보면 자칫 면대면 의사소통을 나쁜 것으로 생각하게 될 수 있고, 혹은 면대면 의사소통을 귀찮아하는 사람들에게 좋은 핑곗거리를 주는 것 일 수도 있다.

9번을 보면 예를 들어 빠른 컴퓨터, 듀얼 모니터, 좋은 비트맵 편집기, HDD 용량등을 언급했다. 조엘의 이야기는 그런 것에 돈 아끼지 말고 팍팍 쓰라는 것이다. 기본적으로는 빠른 컴퓨터 같은 것이 좋긴 하지만 조심할 부분들이 있다. 뛰어난 팀들은 툴을 고를 때 단순히 비싼 게 뭐냐를 기준으로 고르지 않는다. 이런 마인드는 기술을 이해하지 못하는 경영자 마인드에 가깝다.

더 큰 문제는 조엘 테스트가 위험할 수 있는 두 번째 이유에서 나온다.

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

이 12가지가 과연 얼마나 중요한 것들인가.

품질 전문가 제럴드 와인버그는 소프트웨어 개발을 잘 관리하려면 세 가지 근본적 능력이 필요하다고 했다.

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

모 대기업에서 200여 명의 인원과 함께 다음과 같은 실험을 해봤다. 각자 현재 조직에서 대단한 성공 경험이나 엄청난 실패 경험을 두세 명이 한 조로 이야기하게 한다. 그리고 거기에 영향을 미친 요소들을 포스트잇에 적는다. 이 시점에서 네 가지 분류를 공개하고 설명해 준다. 벽면에 사람들이 나와서 자신이 적은 이야기들을 적절한 분류 이름 밑에 붙인다. 가장 많이 붙인 순서는 관리, 시스템, 사람, 도구 순서였다. 이 실험뿐 아니라 통상적으로도 그러하다. 실제로 프로젝트가 아주 성공하거나 실패하거나 하는 이유는 첫 번째가 관리라는 변수 때문이었다. 하지만 각 분류 별로 실제로 개선 시도가 얼마나 있었는지 확인해 보니 가장 많은 개선 노력이 있었던 분류는 바로 도구였다.

와인버그는 배리 보엠의 연구에서 다음과 같은 수치를 도출해 냈다. 이 수치는 소프트웨어 개발 프로젝트에서 네 가지 해당 영역별로 상당한 개선, 즉 예컨대 85등 하던 회사가 10등 하는 회사로 비용을 개선을 할 경우 실제 비용이 얼마나 줄어드는가를 분석한 것이다.

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

쉽게 말해, 도구 부분에서 상당한 개선을 이뤄내면 비용 면에서 세 배 정도 개선을 얻을 수 있다. 이에 비해 관리 부분에서 상당한 개선을 이뤄내면 비용 면에서 64배 정도의 개선을 얻을 수 있다는 뜻이다.
관리자들이 선호하는 개선 노력은 정확이 역순으로 일단 도구 개선부터 시작한다. 자기 자신을 바꾸는 것은 맨 나중이다. 그러나 실제 효과로 보면 우선순위는 관리가 맨 처음에 온다.

다시 조엘 테스트로 돌아가서 조엘 테스트의 각 항목을 이 네 가지 분류로 나눠본다. 절반이 넘는 문항이 도구 분류에 들어갈 것이다. 조엘 테스트는 가장 만만하고 쉬운 것부터 시작하는 관리자의 성향과 충돌하지 않는다. 이것이 조엘 테스트가 위험할 수 있다고 생각하는 두 번째 이유다.

자신을 돌아보고 관리 방식 자체에 문제가 없는지 살펴보고 개선하는 것이 그 출발이 되지 않을까 한다.

📚 협력을 통한 추상화

🎈 커뮤니케이션과 협력

일반적으로, 실력이 뛰어난 프로그래머는 보통 정도의 실력을 가진 프로그래머에 비해 커뮤니케이션, 협력 능력이 더 뛰어나다. 게다가 실력이 뛰어난 프로그래머는 커뮤니케이션과 협력에 더 오랜 시간을 들인다. 반면 설계나 코딩, 테스팅에 들이는 시간에는 통계적으로 큰 차이가 없다.

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

많은 실험에서 집단의 퍼포먼스가 개인의 퍼포먼스보다 못 한 경우를 찾아냈다. 예를 들어 능력이 10, 20, 30, 100인 사람들이 있을 때, 같이 일하면 전체의 능력은 100보다 작다. 최소 모델과 최대 모델의 중간이 셈이다. 그래서 실력이 뛰어난 사람은 혼자 일하게 해야 한다고 주장하는 사람도 많다.

하지만, 반대의 연구 결과가 점점 늘어나고 있다. 예전 연구의 실험 조건이 상대적으로 협력에 불리하게 짜여 있는 경우가 많았으며, 그냥 협력이라고 다 좋은 것이 아니고 몇 가지 전제 조건이 필요하다는 것이다.

🎈 톱니바퀴 실험

스탠퍼드 대학교의 심리학자인 대니얼 슈와르츠는 같은 문제를 혼자 푸는 경우와 두 사람이 함께 푸는 경우의 차이에 대한 연구를 시행했다. 톱니바퀴 문제인데, 다음과 같은 방식이다.

다섯 개의 톱니바퀴가 가로로 길게 연결되어 있다. 가장 왼쪽에 있는 톱니바퀴를 반시계 방향으로 돌리면 가장 오른쪽의 톱니바퀴는 어느 쪽으로 돌까?

이런 문제를 일곱 개 낸다. 문제에서 톱니바퀴 개수는 각기 3, 4, 5, 6, 7, 8, 9로 바뀐다(개수가 점점 많아지는 것과 뒤섞인 것 두 가지로 실험). 그리고 마지막 여덟 번째 문제가 나온다. 바퀴 개수는 131개.

처음에는 다들 허공에 손을 돌리면서 문제를 풀기 시작한다. 그중 어떤 사람은 도중에 패리티 법칙을 발견하고 그때부터는 허공에 손을 내젓지 않는다. 그들은 131개 톱니바퀴 문제도 순식간에 답할 수 있다. 추상화된 규칙을 찾았기 때문이다.

일곱 번째 문제를 풀 때까지 이 추상화된 규칙을 찾아내는지 그렇지 못한지를 살펴보았더니, 혼자서 작업한 경우는 14%만이 추상화 규칙을 찾아냈다. 반면 둘이서 함께 작업한 경우 58%나 추상화 규칙을 찾아냈다. 만약 두 사람이 한 팀으로 작업하되 서로 인터랙션하지 않았고, 그들의 결과물 중 더 나은 것을 택하는 방식이라면 이 경우는 확률적으로 계산할 수 있는데, 26%가 된다.

이러한 차이가 생기는 이유는 두 사람이 서로 마주 앉았는데, 둘 다 허공에 손을 들고 톱니바퀴가 도는 흉내를 낸다. 그 흉내를 내는 방식도 처음엔 제각각이다. 그러면서 이런 혼동을 해결하기 위해 추상적 개념을 도입한다. 예컨대 바퀴에 식별 번호를 붙인다든지 하는 것이다.

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

🎈 추상화의 중요성

때로는 말로 길게 풀어쓰는 것이 가독성을 떨어뜨리기도 합니다. 뭔가 장황해 보이니까요. 우리는 산문보다 운문에서 배울 것이 많습니다. 만약 소스가 비지니스 로직이 들어가고 그 로직이 domain-rich 하다면 되도록 가독성을 추구하겠지만, 저는 때로 가독성을 손해보면서까지 중복을 줄이기도 합니다. 객체지향에서 그걸 하다 보면 흥미로운 객체들을 발견합니다. 함수형에서 그렇게 하다 보면 흥미로운 함수와 함수의 함수를 발견합니다. 이 흥미로운 무엇은 강력합니다. 내가 전에 모르던 것을 배우게 됩니다. 그리고 종종 이것은 프로그래머의 울타리를 넘어서 영향력을 끼치기도 합니다. 고객들의 대화가 바뀔 수도 있습니다.

여기서 말하는 흥미로운 무엇이 바로 추상화이다. 특히, 우리가 예상하지도 못하던 추상화로, 말하자면 창발적 추상화라고 할 수 있다. 추상화는 프로그래머들에게 매우 중요한 주제다. 추상화에 대한 소프트웨어 분야의 명언이 많이 있다.

• 전산학의 모든 문제는 또 다른 차원의 간접성(indirection)으로 해결할 수 있다. - 버틀러 램슨
• 전산학은 추상화의 과학이다 - 앞르페드 아호와 제프리 울먼
• 소프트웨어 공학의 전체 역사는 추상화 수준을 높이는 것으로 특징 지을 수 있다. - 그래디 부치
• 복잡한 현상에 대한 이해를 발전시켜 나갈 때, 인간 지성에서 가장 강력한 도구는 추상화다. 실세계의 특정한 대상체, 상황, 과정 간의 유사성을 인식하는 데에서, 그리고 이러한 유사성을 집중하고, 차이점은 일시적으로 무시하는 결정에서 추상화가 생겨난다. - 토니 호어

🎈 대화하는 프로그래밍

짝 프로그래밍은 두 사람이 한 컴퓨터를 사용해 함께 프로그래밍하는 것이다. 두 사람이라는 구성은 대화를 통해 추상화를 높이게 한다. 한 컴퓨터라는 구성은 구체화를 통해 검중하게 한다. 미루고 헤아리는 것이 빈번히 교차한다. 그리고 그 사이에서 아하가 터져 나온다.

켄트 벡과 함께 익스트림 프로그래밍의 짝 프로그래밍 개념을 형상화한 워드 커닝햄이 말했다.

익스트림 프로그래머는 작업하면서 프로그래밍 각 단계에 대해 함께 이야기한다.

그리고 워드 커닝햄은 다음과 같은 말도 했다.

주의해서 생각하지 않으면 프로그래밍은 특정 프로그래밍 언어로 명령문을 타이핑해 넣는 것에 지나지 않는다고 생각할 수 있다.

심지어 프로그래밍 전문성 연구에서조차 이제까지 커뮤니케이션과 협력의 중요성을 놓치고 있었다. 기술이 만들어낼 사회 구조의 변화와 기술이 이끌어낼 사람들 간의 대화에 있다. 그리고 그 대화는 우리가 혼자서는 생각하지 못했던 것들을 만들게 해 줄 것이다.

자신이 작성하는 코드의 추상성을 높이고 싶다면 혼자서 고민하지 말고 다른 사람들과 협동하고, 대화하세요. 같이 그림도 그려보고 함께 소스코드를 편집하세요. 인간에게는 다른 인간과 소통하고 협력할 수 있는 놀라운 능력이 있습니다. 대화는 기적입니다.

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

신뢰를 쌓는 데에 널리 사용되는 한 가지 방법은 투명성과 공유, 인터랙션이다. 자신이 한 작업물을 투명하게 서로 공유하고 그에 대해 피드백을 주고받으며 인터랙션을 하는 것이다. 조직에서의 신뢰를 연구하는 사람들은 이런 것을 소통 신뢰(Communication Trust)라고 합니다. 상대가 자신이 가진 생각을 나에게 솔직하게 말해줄 거라는 신뢰다.

그런데 정말 그렇게 공유하고 소통하면 신뢰가 쌓일까?

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

세 가지 경우가 있다. 첫 번째는 디자이너들이 하나의 디자인을 만들고 하나를 공유했다. 두 번째는 디자이너들이 같은 시간 여러 개(3개)의 디자인을 만들고 그중 자신이 가장 잘했다고 생각하는 것을 골라서 공유하게 했다. 하지만 이 두 경우 모두 공유 후에 신뢰감이 더 떨어졌다.

이 실험에서 세 번째 조건은 디자이너들이 각자 여러 개의 디자인을 만들고 그걸 모두 공유한 경우였다. 이때는 신뢰가 유의미하게 증가했다.

이 실험에서는 3가지 조건을 이렇게 이름을 붙였다. 하나 공유, 최고 공유, 복수 공유.
하나 공유나 최고 공유를 하고 나면 신뢰가 더 떨어진다. 신뢰 면에서 보면 안 하느니만 못하다.
이런 일이 생기는 이유는 하나 공유나 최고 공유의 경우 우리는 공유 자리에 기대감보다 불안감을 갖고 갈 것이다. "상대가 이걸 보고 흉을 보면 어쩌지?" 그리고 그럴 경우 어떻게 방어적으로 대응해야 할지도 대략 생각해둘것이다. 또한, 상대의 시안을 보고 솔직한 의견을 내는 것도 꺼리게 될 것이다. 그렇기 때문에 듣는 사람도 "저 사람 솔직하지 않은 것 같아" 라고 느낄 것이다.

🎈 복수 공유의 장점

반대로 복수 공유는 그런 불안감이 상대적으로 덜하다. 또 부정적 피드백을 수용하려는 마음도 더 많다. 또 여러 개이니 상대적으로 이야기를 할 수 있어 말하는 사람도 편하고, 듣는 사람도 좋다는 이야기랑 안 좋다는 이야기를 같이 들으니 마음이 좀 더 편하다. 또 흥미로운 부분은 복수 공유를 한 그룹이 자신의 디자인을 공유 후에 개선한 정도가 더 컸다는 점이다.

복수 공유를 통해 나온 디자인은 다른 두 가지 조건에 비해 전문가 평가나 노출당 클릭률이 더 높았다. 다시 말하자면, 복수 공유는 신뢰도 높아지고 성과도 더 좋았다는 말이다.

📚 객관성의 주관성

🎈 품질은 상대적이다

품질이란 누군가에게 가치가 되는 것이다.

사람에 대한 설득도 마찬가지다. 사람들은 설득을 하기 위해 객관성이 필요하다고 생각한다. 그런데 이 객관성의 개념 자체가 매우 주관적이다. 다음은 저자가 격은 일화이다.

모 공공 프로젝트에서 평가 부분이 너무 주관적으로 느껴지기에 좀 더 객관적인 통계적 기법을 제안했더니 단박에 거절당했습니다. 통계적 기법의 적용이 주관적이라고 거절당했습니다. 평가자들이 순전히 주관적으로 판단하고 그걸 전통적 방식으로 취합하는 기존 평가 방식이 더 객관적이라고 하더군요.

결국 결정하는 것은 사람이다. 그 사람 마음에 드냐 안 드냐, 이거다. 안 들면 어떤 이유를 들어서든 반대하게 된다. 도대체 누구의 객관이냐 이거다. 가만히 보면 우리는 그동안 우리의 객관만 신경을 쓰는 실수를 저질러 왔다. 다음은 또 다른 사례이다.

모 회사에서 객관적 자료로 설득을 해달라는 주문을 받았습니다. 그래서 논문 몇 편 갖고 발표를 했습니다. 그랬더니 끝에 묻더군요. "그거 어느 나라 사례인가요?" / "미국요" / "에이 그럴 줄 알았다니까. 우리나라는 미국이랑 달라요, 이 사람아"
이번에는 다시 우리나라 연구를 갖고 찾아갑니다. "그거 어느 업계 사례인가요?" / "X 업계요" / "에이 그럴 줄 알았다니까. 우리 업계는 거기랑 전혀 달라요, 이 사람아"
이번에는 다시 해당 업계 자료를 구해 갑니다. "그거 어느 회사 사례인가요?" / "A 회사요" / "에이 그럴 줄 알았다니까. 우리 회사는 그 회사랑 전혀 달라요, 이 사람아"
그리고 어떻게 하다가 보니 그 회사에서 코칭을 하고, 최종 발표를 합니다. "그거 어느 팀 사례인가요?" / "K 팀요" / "에이 그럴 줄 알았다니까. 우리 팀은 그 팀이랑 상황이 전혀 달라요, 이 사람아"

마음에 안 들면 어떤 객관적 자료를 갖다 줘도 설득할 수 없다. 특히나 그 자료에 당신이 생각이 틀렸다라는 암시가 강하게 있다면 더더욱 설득이 어렵다.

🎈 감정을 배제할 수 없다

이쯤 되면 이런 말을 하는 분이 있다. "그건 판단하는 사람이 잘못돼서 그런 거요. 감정적인 선호에 휘둘리지 말고 논리적 판단을 해야지 말이야. 이 사람아" 근데, 논리적이라는 것도 상대적이다. 그리고 논리랑 감정적 판단을 분리할 수가 없다.
의사결정을 하는 과정에 감정적이고 직관적인 부분이 큰 역할을 하고 있으며, 그런 감정적 부분이 배제된다면 의사결정을 제대로 할 수 없다.

남을 설득하려면 논리성과 객관성에 대한 환상을 버려야 한다. 그래야 현실적으로 설득이 가능하다. 내가 설득하고 싶은 상대를 자주 만나서 신뢰를 쌓고, 그 사람이 무엇을 중요하게 여기는지, 어떤 설명 방식을 선호하는지 이해해야 한다. 출발은 결국 내가 설득하려는 사람에게서 하는 것이다. 자료에서 출발하는 것이 아니다.

이런 이유로 상사가 애자일을 받아들이게 하기 위해, 상사와는 별로 대화도 안 하면서 사례를 찾거나 근거 자료를 수집하려고 측정에 시간을 쏟는 분들에게 다음 조언을 준다. "상대방에 대해 얼마나 이해를 하고 계신가요? 얼마나 대화를 해보셨나요?"

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

KAI(Kirton Adaption Innovation)라고 하는 사람의 인지 성향에 대한 이론의 틀을 빌어 애자일을 상대에 맞게 어떻게 설명할지 살펴본다.

• I(Innovation, 다르게 하는 것이 중요)에 가까운 사람에게는:
  • "애자일 이거 정말 새로운 겁니다. 이걸하면 당신에게 새로운 경험을 할 기회가 생깁니다. 모조리 싹 바뀔 겁니다."
• A(Adaption, 잘하는 것이 중요)에 가까운 사람에게는:
  • "애자일은 새로운 것이 아닙니다. 기존의 방법들을 더 낫게 개선한 겁니다. 지금 하고 있는 업무 방식을 조금 더 효율적으로 개선하는 겁니다. 많이 바꿀 필요가 없습니다."

MBTI 성격 유형과 관련이 있는 4가지 기질에서도 접근법을 생각해볼 수 있다. 이성적 판단을 하고 큰 그림을 그리는 NT, 사람들과의 관계에 관심이 많은 NF, 구체적이며 체계적인 SJ, 모험을 좋아하고 닥친 문제를 푸는 것을 즐기는 SP 이렇게 4가지를 말한다.

• NT(직관적 사고형)
  • "애자일을 하면 낮는 의존성과 높은 응집성의 이상적으고 우아한 설계를 실제로 실현하고, 또 지속적으로 유지할 수 있습니다. 이제 스파게티 코드는 안녕입니다."
• NF(직관적 감성형)
  • "고객과 우호적인 관계를 이어갈 수 있습니다. 팀원들 모두가 신뢰하고 협력하면서 즐겁게 일할 수 있습니다. 누군가를 비난하거나 하는 일이 없을 겁니다. 개인적인 성장도 가능합니다."
• SJ(감각적 판단형)
  • "효율적입니다. 낭비되는 작업을 하지 않습니다. 불필요한 문서화나 회의 안 합니다. 데드라인에 와서 '죄송합니다'라고 말하는 상황 절대 나오지 않고, 정확한 예측이 점점 가능해집니다."
• SP(감각적 지각형)
  • "설계한다고 몇 달씩 시간 끌지 않습니다. 당장 개발로 들어갈 수 있습니다. 순시간에 원하는 대로 코드를 바꾸고 테스트를 통과하고 하는 짜릿짜릿한 경험을 할 수 있습니다. 테스트가 실패하면 그 원인이 되는 버그를 찾아서 고치는 것이 마치 게임 같습니다."

결론은, 객관성이라고 하는 것은 상대적이며, 내가 생각하는 객관이 상대의 객관이 아닐 수 있고, 그렇기 때문에 설득에 성공하려면 우선 그 사람을 이해하는 것에서 출발해야 한다는 말이다. 그런 이유로 설득을 하기 위해 객관적 자료를 모으는 부분 이상으로 상대를 이해하는 데 많은 시간을 투자해야 한다.

📚 이것도 모르세요?

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

공감하면서 들어주려고 하고 또 중요한 것은 상대가 어떤 멘탈 모델을 갖고 있는지 파악하려고 한다.

mental model: 통상 심성 모형 등으로 번역하기도 한다. 세상이 어떤 식으로 돌아가는지에 대해 개인이 갖고 있는 믿음과 생각을 말한다.

이렇게 해야지 그 사람이 이 상황에서 왜 이런 접근을 할 수밖에 없었는지 알기 때문에 좀 더 정확하고 효과적인 제안을 해줄 수 있다. 다 설명해줄 필요도 없고, 핵심적인 부분만 짚어주면 된다.

이 방법은 누가 물어볼 때뿐만 아니라 누가 실수나 잘못을 했을 때에도 매우 효과적으로 도움을 줄 수 있다. 능력이 없는 팀장일수록 비난만 한다. 그러면 나중에 비슷한 일이 또 생기게 된다. 훌륭한 팀장이라면 먼저 그 사람의 사고 과정과 전략을 이해하려고 한다. 실제로 전문성 연구에서도, 전문가는 상황 파악을 먼저 하지만 초보자는 뭘 할지부터 정하고 한다는 차이를 발견했다.

🎈 행동을 유도하는 대화

여기에서 다음 행동을 유도하는 코칭까지 나갈 수 있으면 금상첨화다.
참고로 코칭의 흥미로운 점은 코치 자신이 해당 영역에 대한 전문지식이 없어도 코칭을 할 수 있다는 점이다. 이런 방법을 사용하면 피코치가 스스로 약속한 거을 지키는 확률이 매우 높다.

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

📚 하향식 접근의 함정

잘 정의된 문제는 연구하기가 쉽기 때문에 많은 연구가 이루어져 있다. 하지만 우리가 실생활에서 만나는 대다수의 문제는 잘 정의되지 않은 문제이다. 사실상 뭔가 만들어내야 하는 문제, 즉 디자인이 개입되는 것은 거의 다 제대로 정의될 수 없는 문제이다.

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

전문가와 비전문가에게 잘 정의되지 않은 문제를 줬다. 어떤어떤 기계를 만들어봐라 하는 문제였다. 비전문가일수록 자신이 만든 애초에 세운 계획에 집착했다. 오히려 전문가일수록 자신의 계획을 수정한 횟수가 많았다.

연구에 따르면, 프로그램을 이해할 때 고수는 상호 참조 전략을 쓰는 반면, 하수는 그렇지 않았다. 고수는 프로그램을 연구하면서, 프로그램에서 이해한 것을 도메인 어휘로 번역한다. 그러고는 도메인 어휘를 프로그램상의 어휘로 다시 바꿔서 검증한다. 이를 상호 참조 전략이라고 한다. 추상과 구상의 차원을 자주 오가는 것이다. 반면 하수는 '두 세계'를 빈번히 연결하려는 노력을 하지 않으며, 종종 둘 중 한쪽에만 집중한다.

밖에서 어떤 조직을 관찰했을 때 마치 그 속에 모든 층위를 꿰뚫는 전문가가 있는 것 같이 만들 수는 없을까? 이 문제를 해결하기 위해서 기본적으로 두 가지 접근이 가능하다.

• 한 사람이 다기능을 갖추도록
• 협력이 쉽게 되도록

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

🎈 빠르고 빈번한 바통 터치가 가능한 전문가 조지

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

한 연구결과에서 뛰어난 팀들의 공통점 중 하나가 삼투압적 의사소통이였다. 이것은 배어드는 소통방식이다. 서양의 의사소통 모형은 대체로 화살 모형을 따른다. 발신, 수신인이 정해져 있고, 화살을 쏘는 거다. 삼투압적 모형에서는 은연중에 서로 간에 정보가 스며드는 거다.

그렇게 하려면 사람들이 물리적으로 가까운 거리에 있어야 유리하다. 그리고 한번에 처리되는 일의 양을 줄여야한다. 배치 사이즈를 지속적으로 줄여서 지속적 흐름(continuous flow)을 만들고 짧은 시간 내에 탑, 바텀을 오가게 한다.

이 아이디어를 웹개발 쪽에 적용한다면 어떻게 될까? 제시 제임스 개럿의 저서 사용자 경험의 요소에서는 웹 개발에서 추상화의 단계를 다섯 면으로 나눈다.

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

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

흔히들 말하는 개발의 5단계도 비슷하다. 분석, 설계, 구현, 테스트, 전개를 1년이라는 프로젝트 기간에 얼마나 배치할까로 고민하지 말고, 어떻게 해야 첫 달부터, 아니 첫 주부터 분석, 설계, 구현 테스트, 전개를 모두 왔다갔다할 수 있을까를 고민해야 한다. 그리고 이렇게 일하기 위해 우리 조직은 어떤 종류의 협력을 해야할지를 생각해 봐야 할 것이다.

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

울리(Woolley) 연구에서는 4명으로 구성된 분석팀(대테러 정보 분석)이 여러 가지 증거(혹은 가짜 증거)들을 통합하여 테러리스트의 계획을 시간 내에 분석해 내는 실험을 했다. 이 일을 잘하기 위해서는 특정 분야 전문가들의 존재와 그들의 협력이 중요한 상황이었다. 특정 분야 전문가들이 있냐 없냐, 그리고 그 팀에 협력 개입을 했냐 안 했냐 2 x 2 실험을 했다. 총 4가지의 실험조건이 나오는 셈인데, 평균 퍼포먼스 점수는 다음과 같다.

	전문가	비전문가
협력 개입	+0.9	+0
협력 비개입	-0.6	-0

전문가팀은 해당 분야 전문가 2명과 비전문가 2명으로 구성되었고, 비전문가팀은 비전문가 4명으로만 구성되었다. 협력 개입은 총 45분의 실험 중 10분을 할애해 팀원들이 어떤 식으로 협력할지 계획을 세우도록 했고, 협력 비개입은 팀원들이 알아서 하게 놔두었다.

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

이런 차이가 난 원인은 정보 공유의 차이에 있었다. 협력 개입이 된 경우, 팀원들은 정보를 공유해서 더 통합된 해결책을 제시했다. 이에 반해 협력 개입이 없으면 결과물은 서로 모순되는 등 통합되지 못했다. 분야 전문가들이라고 해서 무조건 협력을 잘하는 게 아니라는 것이다.

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

정리하자면,

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

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

구글은 데이터 중심 회사답게 데이터 기반으로 뛰어난 관리자의 특징을 찾는 옥시전 프로젝트 이후에도 뛰어난 팀의 특징을 찾기 위해 2년간 노력했다. 이름하여 아리스토텔레스 프로젝트이다. 이 연구에서 중요한 부분은 세 군데이다.

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

여기서 말하는 심리적 안전감이란, 내 생각이나 의견, 질문, 걱정, 혹은 실수가 드러났을 때 처벌받거나 놀림받지 않을 거라는 믿음을 말한다.

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

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

📚 쾌속 학습팀

🎈 패러다임 전환, 죽느냐 사느냐

PHP를 쓰던 회사. 사장님이 올해 안에 MVC 기반의 자바로 바꾸라는 명령.
그다음 해가 되었다. 어떤 팀은 자바로 잘 옮겨탔지만 몇몇 팀은 여전히 PHP를 부둥켜안고 울고 있다. 왜 이런 차이가 생겼을까?

이런 기술적 변화의 순간은 언제든 찾아올 수 있다. 이름하여 패러다임 전환. 더군다나 IT업계는 이런 전환 주기가 특히 짧은 편이다. 고생은 개발자들이 한다. 개발자들에게 있어 학습이라는 것, 더 나아가 빠른 학습이라는 것은 늘 고민거리이다.

🎈 학습 속도와 상관없는 것

수술하는 의사로 예를 들자면, 교육 배경이나 수술 경험 등은 학습 곡선의 기울기에 영향을 주지 못했다. 참고로 의사의 실력, 예컨대 수술 성공률과 경력 연차가 통계적으로 상관성이 없다는 것은 널리 알려진 사실이다. 무조건 나이든, 혹은 젊은 의사라고 자신의 몸을 맡기는 실수를 범하지 않으시기를!

학습이 느린 병원의 리더는 저명한 심장 외과의였다. 또한 그 팀이 도입하려는 수술에 대해 이미 많은 경험이 있었다. 반면, 학습 속도가 빠른 팀장은 경험이 부족한 젊은 외과의였다.

이 외에도 우리 상식의 허를 찌르는, 학습 속도와 관련이 없는 것들이 많았다. 높은 위치의 경영진이 해당 기술을 지지, 지원하는지 여부도 기술 도입에 별 영향을 주지 못했으며, 퍼포먼스 데이터를 수집하고 분석하는 것 같은 프로젝트 심사, 결과 보고 등도 팀의 성공과 실패에 큰 영항을 주지 못했다.

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

첼시아 병원은 저명한 심장 수술의를 치프로 임명했는데, 그 사람은 다른 병원에서 여러 번 수술을 집도한 경험이 있었다. 그는 새로운 기술에 투자해야 한다고 경영진을 설득했고, 팀이 공식적 교육 훈련을 받도록 했다. 하지만 그 외과의 자신은, 팀원을 선정하는 데에 큰 신경을 쓰지 않았다. 단순히 근속 연수로 팀원을 뽑았다.

마운틴 메디컬 센터는 별 볼 것 없는 변두리 병원이었다. 당시 그곳은 새로운 수술에 관심이 있는(그러나 수술 경험은 없고 유명하지도 않은) 젊은 외과의를 고용했다. 그 의사는 해당 기술을 구현한다는 것은 전혀 다른 스타일의 작업 방식을 도입하는 것이라고 생각했다. 팀원들은 만족감과 자부심이 높았다. 이 팀은 전체 연구에서 가장 빨리 학습한 두 팀 중 하나였다.

논문에서는 팀 학습 속도에 대해 리더가 끼치는 영향을 주목한다. 단순히 기술적 탁월함만을 갖춘 사람보다는 학습 환경을 만들 수 있는 리더가 필요하다는 것이다.

🎈 학습 환경의 차이

학습이 빠른 팀은 팀원을 뽑을 때부터 달랐다. 선발 자체가 매우 협동적으로 이루어졌을 뿐 아니라, 선발 기준도 달랐다. 단순히 업무 수행 능력뿐만 아니라 다른 사람과 협력을 얼마나 잘하는지, 새롭고 애매모호한 상황을 즐길 수 있는지, 자기보다 지위가 높은 사람에게도 자신 있게 의견을 제안할 수 있는지 등을 보고 뽑았다.

또한, 속도가 빠른 팀은 새로운 수술 도입을 기술적 도전이라기보다 조직적 도전으로 받아들였다. 개개인이 새로운 기술을 획득해야 한다고 보지 않고, 함께 일하는 새로운 방법을 만들어야 한다고 생각했다.

마지막으로, 속도가 빠른 팀은 심리적으로 보호가 되고 있었다. 뭔가 새로운 것을 제안하고 시도하는 데에 열려 있었고 실패에 관대했으며 잠재적 문제를 지적하고 실수를 인정하는 데에 부담을 느끼지 않았다. 팀원들은 모두 팀 퍼포먼스를 높이기 위해 새로운 방식을 실험해 보는 걸 강조했다. 설사 새로운 방식이 효과가 없는 것으로 밝혀질지라도 말이다. 그들은 개인 단위의 실험에서 그치게 하지 않고 모두가 공유하는 실험을 했고, 무엇보다도 학습이 실행과 동시에 이루어졌다.

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

성공적으로 기술을 도입한 개발팀은 뭐가 달랐을까? 리더와 팀원들의 학습에 대한 태도에 근본적인 차이가 있었다. 속도가 빠른 팀은 도전 자체를 팀의 학습 능력에 대한 도전으로 받아들였고, 같이 학습해야 한다고 생각했다. 학습을 팀의 중대한 목표로 받아들였다. 리더는 기회가 가능성, 큰 변화의 흐름에 동참하는 중요성과 즐거움 등을 강조했다.

반면 속도가 느리거나 낙오된 팀은 학습을 개인의 과제로 치부했다. 학습보다는 단기 퍼포먼스를 중요시했다. 리더는 낙오의 위험성을 강조하고, 팀원들의 실력이 부족하다고 불평했다.

🎈 현실에서 실천하기

그렇다면 이 상황에서 내가 무엇을 할 수 있을까?

우선 자신의 학습 환경을 만드는것 부터 시작한다. 개별 기술 이상으로 일하는 방식에 대해 실험해 봐라. 실험이 실패한다고 좌절하지 말아야 한다. 학습과 일을 굳이 분리하지 말고 동체로 만들어라. 학습과 실행은 하나이다. 진정한 학습은 실행 속에서 이뤄지고, 진정한 실행은 학습을 수반한다.

작지만 유용한 프로그램들을 매일 작성할 것을 추천합니다.

이 말의 힘을 느끼려면 정반대로 생각해봐라. 크고 쓸모없는 설계를 가끔 생각해 본다면 학습 속도를 높이는 데에 얼마나 도움이 될지.
그리고 학습 공동체를 구축해라. 주변에서 나와 함께 학습 환경을 만들 수 있는 동지를 찾아봐라. 그것이 쾌속 학습으로 가는 지름길이다.

📚 프로젝트 확률론

🎈 어디에 돈을 걸 것인가

다음 두 게임 중 어느 것이든 성공하면 100만 원을 상금으로 준다.

1. 속이 안 보이는 주머니 속에 빨간 돌 5개, 흰 돌 5개가 들어 있다. 임의로 하나를 꺼냈는데 빨간 돌이면 성공이다.
2. 역시 속이 안 보이는 주머니인데, 이번에는 빨간 돌 9개, 흰 돌 1개가 들어있다. 꺼낸 돌을 다시 주머니에 넣으면서 총 7번 돌을 꺼내 색을 확인한다. 모두 빨간 돌이면 성공이다.

다음 두 게임 중 어느 것이든 성공하면 100만 원을 상금으로 준다.

1. 속이 안 보이는 주머니 속에 빨간 돌 5개, 흰 돌 5개가 들어 있다. 임의로 하나를 꺼냈는데 빨간 돌이면 성공이다.
2. 역시 속이 안 보이는 주머니인데, 이번에는 빨간 돌 1개, 흰 돌 9개가 들어있다. 꺼낸 돌을 다시 주머니에 넣으면서 총 7번 돌을 꺼내 색을 확인한다. 그중 빨간 돌이면 한 번이라도 나오면 성공이다.

🎈 직관의 허점

보통 첫 번째 질문에서 2번을 선택하고, 두 번째 질문에서 1번을 선택한다. 하지만 사실상 확률적으로 따려보면 첫 번째 질문에서 1번이 더 유리하고(0.5 대 0.48), 두 번째 질문에서는 2번이 더 유리하다.(0.5 대 0.52)

사람들은 통산 그리고(AND) 조건의 사건은 확률을 과대평가하는 경향이 있고, 논리연산의 또는(OR) 조건의 사건은 반대로 확률을 과소평가하는 경향이 있다.

따라서 앞의 두 질문에서 일반적인 직관을 따른다면 손해를 보는 선택을 했을 것이다. 이런 오류가 있는 직관을 심리학에서는 인지적 편향이라고 한다. 우리가 일이 얼마나 걸릴까, 혹은 이 일을 제시간에 끝낼 확률이 뭘까 같은 추정을 할 때 이런 편향이 상당히 작용한다고 연구가 되어 있다.

🎈 이번 프로젝트는 제때에 끝낼 수 있을 거 같았는데

이제 상황을 프로젝트로 바꾼다.

한 명의 관리자와 7명의 개발자가 있다. 관리자는 예술적인 칼놀림으로 프로젝트를 7개의 독립적인 일 덩어리로 잘라 개발자들에게 나누어줬다. 개발자들은 다른 개발자의 일에 관심을 둘 필요가 없다. 서로 분리된 일을 하면 된다. 프로젝트 중반쯤 되어 관리자는 최악의 마지노선을 긋고 개발자들에게 물어본다. "일정 안에 가능한가요?" 모두 가능하다고 한다. 7명이 각기 90% 확률의 확신을 갖고 있다고 답했다.

이런 확률적 정의를 말로는 이해해도 본인이 확률적 답을 할 때에는 전혀 관계없이 답하는 경우가 흔하다.

관리자 입장에서는 마음이 한결 놓인다. "진행이 잘 되고 있구나. 이번 프로젝트는 뭔가 잘 풀리려나 보다" 라고 생각한다. 하지만, 이 관리자는 앞서 언급한 "빨간 돌 흰 돌" 게임의 오류를 그대로 저지르고 있다. 각 개발자가 마감일을 지킬 확률이 0.9인데, 모든 개발자가 마감일을 0.9라고 말하는 것은 아마 자신의 머릿속에서 0.9를 일곱 번 더해서 7로 나눈 결과일 것이다. 이것은 평균의 악용이다. 이런 식으로 확률을 평균내면 안 된다. 앞에서도 말했지만 우리는 대푯값을 취하는 경향이 있는데 여기에서 오류가 많이 생긴다.

이 경우 확률을 계산하려면 0.9를 일곱 번 곱해야 한다. 그러면 0.48이 나온다. 즉, 모든 개발자가 90%의 확률로 안심을 하고 있지만 전체 프로젝트 입장에서는 마감일에 맞출 확률이 동전 던지기에서 앞면이 나올 확률보다 안 나오는 것이다.

게다가 일반적으로 일의 소요 시간을 추정할 때 사람들이 낙관적으로 추정한다는 편향에 대한 연구 결과가 많다는 점까지 고려하면 상황은 더 심각해진다.

🎈 애자일 확률론

애자일 프로젝트라면 어떨까? 어떤 관리자에게 12가지 할 일이 있고 그 일을 할 사람도 12명이 있다. 관리자는 어떻게 해야 할까?

• 워드 커닝햄의 글

제가 선호하는 접근법은 관리자가 12명 모두에게 단지 3가지 일만 주고 서로 협동해서 그 일을 하도록 요청하는 것입니다. 그 일들이 완료되면 관리자는 할 일을 3개 더 만들어 냅니다. 사람들은 작업을 완료하기 위해 자기 조직화를 할 수 있는 권한이 있고, 또 매번 다르게 조직화할 수도 있을 겁니다. 이 방식이 잘 돌아가는 이유는 사람들이 관심사의 섞임을 통해 서로에 대해 엄청나게 많은 것을 매우 빨리 배울 수 있기 때문입니다. 이런 식으로 학습한 지식은 관리자나 혹은 누구든 딱 한 사람이 모델링한 것의 위험을 피할 수 있는데, 그런 한 사람에 의한 모델링 때문에 모델 주도 접근법은 불리해집니다.

애자일은 앞서의 고전적 방법과 달리 일을 공유한다. 각자 일을 얼마나 진행했는지 매일 공유할 뿐 아니라 내 일, 네 일의 구분선이 뚜렷하지 않다. 애자일에서는 되도록 사람들이 섞이도록 한다.

이 경우 확률적으로 역시 7명이 이고, 모두 90% 확률로 확신을 한다고 친다. 90% 확률이었다면 개중에는 일찍 끝내는 사람도 분명 있을 것이다. 고전적 방법에서는 내가 일을 빨리 끝내는 것이 이 프로젝트에 큰 도움이 되지 않는다. 내 일은 내일이고 다른 사람 일은 다른 사람 일이기 때문이다. 그래서 마감 시간에 맞춰 끝나도록 일부러 일을 늘리는 경향도 생긴다. 하지만 애자일에서는 내가 일이 빨리 끝나면 다른 사람의 일을 도와준다. 이렇게 먼저 일을 끝낸 사람이 나머지 사람들을 도와주게 되기 때문에 해당 시점에 나머지 사람들이 일을 제시간에 끝낼 확률이 높아질 것이다. 따라서 각기 제시간에 일을 마칠 확률이 90% 확률일 때, 모든 일을 제시간에 맞출 확률을 구한다고 0.9를 일곱 번 곱할 수 없다.

게다가 애자일에서는 지식을 공유하기 때문에 좋은 정보는 모두가 곧 알게 된다. 그리고 그 좋은 정보는 각자의 일에 모두 도움이 된다. 서로 판이한 일을 하는 것이 아니고 관련성이 있는 것들을 진행하기 때문이다. 이러한 새로운 지식, 깨달음은 프로젝트 속도를 높이는 데에 큰 도움이 되는 경우가 많은데, 애자일에서 이 확률은 또는 확률에 해당한다.

애자일은 되도록 일 진행에 단계(앞서의 분석, 설계, 구현, 테스트, 전개 같은)를 두지 않으려고 한다. 단계가 있으면 시기에 따라 하는 일에 큰 차이가 생긴다. 하지만 애자일은 마치 프랙털 구조처럼 부분 속에 전체가 들어가게 한다. 그렇게 하면 과거에서 미래를 점쳐 보기가 훨씬 쉽다. 일이 진행될수록 점점 추정 정확도가 높아진다. 대략 서너 번의 반복주기만 지나면 종료 가능 날짜가 고전적 방법에 비해 훨씬 더 정확히 예측된다. 이 방법을 통하면 사람들의 낙관적 추정 편향도 피해 갈 수 있다.

애자일은 좋은 일에 대해서는 '그리고' 확률을 '또는' 확률로 바꾸고, 나쁜 일에 대해서는 '또는' 확률을 '그리고' 확률로 바꾸는 경향이 있다. 좋은 일은 공유해서 한 사람만이라도 주요한 통찰이 있었다면 이걸 공유해서 '또는' 확률로 만들고, 버그 같이 나쁜 일에 대해서는 여러 사람이 중복 검토해서(짝 프로그래밍, 코드 공유, 퀵 디자인 세션, 코드 리뷰 등) 모두가 실수해야지만 구멍이 나게 '그리고' 확률을 바꾸는 것이다.