[함께] 빠르고 빈번한 바통 터치가 가능한 전문가 조직

제시 제임스 개럿(Jesse James Garrett)의 저서 «사용자 경험의 요소»에선 웹개발에서 추상화의 단계를 다섯 면으로 나눈다.

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

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

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

• 하지만 사실은 이와 다르다. 더 높은 품질을 얻기 위해 이 사다리를 오르락내리락 반복하는 것이 필요하다. 어느 한 단계를 한번에 완료하는 것은 더 낮은 품질로 가는 지름길이다. 특히나 문제와 해결책에 불확실성이 높은 경우….
• 흔히들 말하는 개발의 5단계도 비슷하다. 분석, 설계, 구현, 테스트, 전개를 1년이라는 프로젝트 기간에 얼마나 배치할까로 고민하지말고, 어떻게 해야 첫 달부터, 아니 첫주부터 분석, 설계, 구현,테스트, 전개를 모두 왔다갔다 할 수 있을까를 고민해야 할 것이다.
• 그리고 이렇게 일하기 위해 우리 조직은 어떤 종류의 협력을 해야 할지를 생각해봐야 할 것이다.

나의 생각

• 근래 들어 분석, 설계, 구현, 테스트를 왔다갔다 하는일이 잦게 되었고 왜 그런지에 대해 깊이 있게 생각해본 적이 있다. 왜 왔다갔다 하게 되었는지에 대해선 더 확장성 있는 구조를 가져가려 하였기 때문이었고 설계 단계의 결함이 도출된 것이라 생각하였다.
• 하지만 이러한 왔다갔다함이 더 높은 품질을 얻기 위한 과정임을 새로 깨닫게 되었고 앞으로는 개발하면서 자연스럽게 받아들일 수 있을 것 같다.
• 품질과 비슷하게 생산성도 중요한 부분이기에 더 성장하기 위해선 이러한 과정을 빠르게 반복하는 역량도 필요하지 않을까란 생각도 든다.
  • 이와 연관되어 앞서 나온 빠르게 실패 하기도 비슷한 맥락이 아닐까 싶다..!

[함께] 구글이 밝힌 탁월한 팀의 비밀

구글은 뛰어난 팀의 특징을 찾기 위해 2년간 연구를 진행했다. 그리고 2015년 그 연구 결과 일부를 공개했다.

주목할만한 점은 다음 3가지이다.

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

위 1번에 대해선 <전문가 팀이 실패하는 이유> 에 일례를 들어 그 중요성을 이야기 한바 있다.

짧게 요약하면 다음과 같다. 전문가들 모아서 팀 만든다고 잘하는 것 아니고 오히려 성과가 떨어질 수 있다. 정보 공유하고 협력을 자하기 위한 명시적인 도움이 필요하며 소셜 스킬 등이 뛰어난 제너럴리스트가 있으면 도움이 된다는 내용이다. 전문가들만 모아서 계획 없이 특정 일을 하게 되면 퍼포먼스가 더 떨어지게 된다는 내용이다.

2번은 실수 관리와도 관련 있다. 에드먼드슨 교수의 연구에 따르면 실수율이 낮은 병원이 좋은 병원이 아니라고 한다. 발견된 실수율은 해당 조직의 보고 문화와 관련이 깊었는데, 실수율이 낮은 조직은 실수를 적게하는 것이 아니라 실수를 공개하는 것이 공격을 받을 수 있어 실수를 감추는 조직이었단 내용이다.

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

그렇다면 어떻게 심리적 안전감을 높일 수 있을까?

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

여기서 또 하나의 전제 조건이 있는데 관리자나 리더의 매일매일 팀원들과 갖는 인터렉션에서 다른 행동 양태를 보여줘야 한다. 이러한 변화없이 갑자기 무슨 토론회만 챙기게 되면 오히려 신뢰가 깍이게 될 것이다.

팀원이 불편한 문제를 제기하거나, 어리석어 보이는 질문을 하거나, 부족한 의견을 얘기하거나, 어처구니 없는 실수를 저질러도 이를 꾸짖고 타이르기 보단 이러한 실수를 관리하는 측면에 더 신경을 써라.

나의 생각

• 여기서 언급하는 심리적 안전감 이란 것에 대해 많은 공감이 된다.
• 생각이나 의견, 질문, 걱정, 혹은 실수를 자유롭게 드러낼 수 있는 조직에 있을 때 팀원들이 조금 더 적극성을 갖게 될 것 같고, 더 나은 제품을 만들어가는데 더 몰입을 할 수 있지 않을까 싶다.

[함께] 쾌속 학습팀

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

• 두 병원(첼시아 병원, 마운틴 메디컬 센터)이 최소 침습 수술에 대한 학습 속도를 비교한 연구가 있었다.
  • 첼시아 병원의 리더는 저명한 심장 수술의였고, 마운틴 메디컬 센터는 새로운 수술에 관심이 있는(그러나 수술 경험은 없고 유명하진 않은) 젊은 외과의 였다.
  • 첼시아 병원 리더는 팀원을 선정하는데 큰 신경을 쓰지 않았고, 단순히 근속 연수로 팀원을 뽑았다. 그리고 본인보단 팀원을 훈련시키는 것에 집중 포커스를 두었다.
  • 마운틴 메디컬 센터의 리더는 본인이 독재자로서가 아닌 파트너가 될 수 있는 능력에 집중 포커스를 두었다.
• 결과는 어떠했을까? 당연히 마운틴 메디컬 센터의 학습 속도가 월등하게 빨랐다.
• 논문에서는 팀 학습 속도에 대해 리더가 끼치는 영향을 주목한다.
  • 단순히 기술적 탁월함만을 갖춘 사람보단 학습 환경을 만들 수 있는 리더가 필요하다는 것이다

나의 생각

• 제품 개발이 혼자가 아닌 팀 단위로 진행되다보니 당연한 것 같다.
  • 하지만 리더의 기술적 탁월함도 무시하지 못할 것 같단 생각은 든다.
  • 학습 환경이 잘 조성된 팀에 학습 방향을 잘 잡아주는 리더가 있는 조직이 더 빠르게 성장할 수 있지 않을까 하는 생각이 든다.
  • 그래도 리더의 기술적 탁월함보단 학습 환경을 잘 조성할 수 있는 리더가 더 중요하단 말은 더 공감이 되는 것 같다.

학습 환경의 차이

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

속도가 빠른 팀의 특징

• 새로운 수술 도입을 기술적 도전이라기보다 조직적 도전으로 받아들였다.
• 개개인이 새로운 기술을 획득해야 한다고 보지 않고, 함께 일하는 새로운 방법을 만들어야 한다고 생각했다.
• 자신이 조직의 일원이 된다는 사실 자체를 자랑스럽게 생각하고 있다.
• 심리적으로 보호가 되고 있다.
  • 뭔가 새로운 것을 제안하고 시도하는데 열려 있고 실패에 관대했으며 잠재적 문제를 지적하고 실수를 인정하는데 부담을 느끼지 않았다.
  • 팀원들은 모두 팀 퍼포먼스를 높이기 위해 새로운 방식을 실험해 보는 걸 강조했다.
  • 설사 새로운 방식이 효과가 없는 것으로 밝혀질지라도…
  • 개인 단위의 실험에서 그치게 하지 않고 모두가 공유하는 실험을 했고, 무엇보다 학습이 실행과 동시에 이루어졌다.

학습 속도가 느린 팀의 특징

• “도데체 뭐가 새롭다는건지 모르겟어요. 이 기술의 기본적인 요소들은 수년 전부터 존재해 왔는데 말이죠” 라는 식의 새로운 기술을 비꼬고 조한다.
  • 냉소주의는 전염성이 강하다.

기술 전환에 성공한 개발팀

• 성공적으로 새로운 기술을 도입한 개발팀(예를 들어, php -> java로의 전환)은 어떤 부분이 달랐을까?
  • 우선 해당 팀에 자바를 잘하는 사람이 있는지, 혹은 리더가 자바 실력이 잇는지는 큰 작용을 하지 못했다.
  • 대신, 리더와 팀원들의 학습에 대한 태도에 근본적인 차이가 있었다.
  • 속도가 빠른 팀은 도전 자체를 팀의 학습 능력에 대한 도전으로 받아들였고, 같이 학습해야 한다고 생각했다.
  • 학습을 팀의 중대한 목표로 받아들였다.
  • 리더는 기회와 가능성, 큰 변화의 흐름에 동참하는 중요성과 즐거움 등을 강조했다.
• 반면 속도가 느리거나 낙오된 팀은 학습을 개인의 과제로 치부했다.
  • 학습보단 단기 퍼포먼스를 중요시했다.
  • 리더는 낙오의 위험성을 강조하고, 팀원들의 실력이 부족하다고 불평했다.
• 서로 다른 회사에 존재하는 팀 간의 이야기가 아니다.
  • 심지어 옆자리에 있는 팀끼리도 이런 차이가 있었다.
  • 즉, 학습 환경은 하나의 회사에 단일한 것이 아니고 동일 회사의 이웃 팀끼리도 큰 차이가 있을 수 있다는 말이다.

현실에서 실천하기

• 팀장도 아니고, 정치적인 힘도 없다. 그렇다면 이 상황에서 내가 할 수 있는 것은 무엇일까? 팀원과 팀장에게 이 책을 권할 수 있는 분위기도 아니라면?
• 우선 자신의 학습 환경을 만들어라. 거기서부터가 출발이다. 개별 기술 이상으로 일하는 방식에 대해 실험을 해봐라. 실험이 실패한다고 좌절하지 마라.(사실 실험에 대한 실패는 없다. 학습할 수만 있다면)
• 학습과 일을 굳이 분리하지 말고 동체로 만들어라. 학습과 실행은 하나이다.
• 진정한 학습은 실행 속에서 이뤄지고, 진정한 실행은 학습을 수반한다.
  • 우선 언제 시작할지 계획부터 짠다? 지금 당장하지 않는다면 장차 할 확률은 절반 이하로 떨어진다.
• 새로운 일의 방식을 실험해보자. 일단 30분 만 업무 개선을 시도해봐라.
• 마지막으로 학습 공동체를 구축해라. 주변에서 나와 함께 학습 환경을 만들 수 있는 동지를 찾아봐라. 그것이 쾌속 학습으로 간느 지름길이다.

[함께] 프로젝트 확률론

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

• 한 명의 관리자와 7명의 개발자가 있다.
• 관리자는 예술적인 칼놀림으로 프로젝트를 7개의 독립적인 일 덩어리로 잘라 개발자들에게 나누어줬다.
  • 개발자들은 다른 개발자의 일에 관심을 둘 필요가 없다. 서로 분리된 일을 하면 된다.
• 프로젝트 중반쯤 되어 관리자는 최악의 마지노선을 긋고 개발자들에게 물어본다. “일정 안에 가능한가요?”
  • 개발자들은 모두 가능하다고 답변한다. 7명이 각기 90% 확률의 확신을 갖고 있다고 답했다고 치자.
• 사실 어떤 일을 X일ㄹ 전에 끝낼 확률이 0.9라는 것은 상당히 높은 수치이다.
• 같은 일을 10번 반복했을 때 한 번 빼고는 모두 제시간에 끝낼 수 있는 정도라는 뜻이다.
• 이런 확률적 정의를 말로는 이해해도 본인이 확률적 답을 할 때에는 전혀 관계없이 답하는 경우가 흔하다.
• 예를 들어, “자신의 집에서 가장 가까운 지하철역으로 가는데 시간이 얼마나 걸릴까?”를 묻는다고 해보자.
• 누군가는 20분이라고 했다고 하자. 이 20분은 뭘 말하는 걸까?
  • 이번에는 이사람이 집에서 지하철역까지 가는 실험을 수천 번 하고, 각기 걸린 소요 시간을 기록해서 확률 분포도를 그렸다고 해보자. 그래프는 어떻게 나왔을까? 아래 이미지는 그 예시이다.

• 먼저 주의해서 볼 것은 이 그래프가 대칭형이 아니라 비대칭이라는 점이다. ㅇ왜 그럴까? 지하철역까지 가는데 걸리는 시간은 1시간, 1일, 1년일 확률이 모두 0이라고 말할 수 는 없다. 가다가 교통사고를 당할 수도 있는 것이다.
  • 하지만 0초 미만으로 걸릴 확률은 0이라고 말할 수 있다.
• 바로 여기서 문제가 발생한다. 통상 시간을 추정할 때 우리는 대푯값으로 최빈값(가장 빈번하게 나온 값)을 선택하는 경향이 있다.
• 그런데 이와 같은 비대칭 그래프에서 최빈값을 고르면 해당 시간 이하로 골인할 확률, 즉 이 그래프에서 A지점 좌측의 면적이 전체의 50%가 되지 않는다.
• 내가 20분 안에 골인할 확률은 동전 던지기보다도 못한 것이다 (동전 던지기는 확률이 50프로는 되기에..)
• 소프트웨어 공학 쪽의 연구에 따르면 사람들이 통상적으로 추정하는 소요 식나에 적어도 2~3배를 해야 80% 정도의 확률로 마칠 수 있는 시간이 나온다고 한다.
• 일반인들(심지어 의사 같은 전무가들도 포함)의 확률에 대한 직관이 형편 없다는 것을 고려할 때, 개발자들이 90%의 확률이라고 말했따느 것을 그대로 믿기는 힘들다만, 정말 이상적인 사황을 생각해보자.
• 실제로 각자의 확률이 90%였다고 치는 것이다.
  • 다만 현실에서 사람들의 확률적 추정을 그리 믿을 수 없다는 것만 염두에 두고 넘어가자.
  • 이제 관리자는 마음이 한결 놓일 것이다. 이번 프로젝트 진행이 잘되고 있구나 하고
• 하지만 이 관리자는 앞서 언급한 ‘빨간 돌 흰돌’ 게임의 오류를 그대로 저지르고 있는 것이다. (책 p179 참고)
• 각 개발자가 마감일을 지킬 확률이 0.9인데 모든 개발자가 마감일을 지킬 확률이 0.9라고 말하는 것은 아마 자신의 머릿속에서 0.9를 7번 더해서 7로 나눈 결과일 것이다. 이것은 평균의 악용이다.
• 이런 식으로 확률을 평균내면 안된다. 앞에서 말했찌만 우리는 대푯값을 취하는 경향이 있는데 여기에서 오류가 많이 생긴다.
• 이 경우 확률을 계산하려면 0.9를 7번 곱해야 한다. 그러면 0.48이 나온다. 즉, 모든 개발자가 90%의 확률로 안심을 하고 잇찌만 전체 프로젝트 입장에선 마감일에 맞출 확률이 동전 던지기에서 앞면이 나올 확률보다 안나오는 것이다.
• 게다가 일반적으로 일의 소요 식나을 추정할 때 사람들은 낙관적으로 추정한다는 편향에 대한 연구 결과가 많다는 점까지 고려하면 상황은 더 심각해진다.
• 학생들에게 논문 프로젝트의 완료 시기를 추정하게 했다. 99%의 확률로 언제 까지 끝낼 수 있는가에 대한 대답을 얻었다.
• 정말 그 기간 안에 끝낸 학생 수가 얼마나 되었을까? 그 학생들의 예측이 정확했땀녀 99%의 학생이 기간 내에 끄낼 수 있어야 한다.
  • 하지만 실제로 45%의 학생만이 기간 내에 프로젝트를 완료할 수 있었다. 엄청난 차이이다.
• 또 다른 연구에 따르면, 사람들에게 가장 그럴싸한 추정을 부탁했을 떄와 자신이 기대하는 최선의 상황을 상상해서 추정해보라고 부탁했을 때 그 추정치는 큰 차이가 없었다.
• 설상가상으로, 프로젝트 절반 지점까지 햇던 일과 앞으로 해야 할 일의 종류가 너무 다르다. 이제 까지 분석, 설계, 밑부분 코딩을 진행해왔는데, 그것을 기준으로 미래에 있을 본격적 코딩, 테스팅, 디버깅, 배치 등을 추정하는 것은 매우 부정확하다. 추정은 과거의 일과 미래의 일이 판이하면 할수록 정확도가 떨어지는 경향이 있따.
  • 분석, 설계, 테스팅, 디버깅은 질적으로 너무도 다른 작업이다. 이렇게 작업 단계로 나눠 일을 하면 단절 지점이 필연적으로 생기게 된다.

애자일 확률론

• 애자일 프로젝트라면 어떨까? 우선 워드 커닝햄의 영감 번뜩이는 다음 글을 보자.
• 어떤 관리자에게 12가지 할 일이 있고 그 일을 할 사람도 12명이 있다. 관리자는 어떻게 해야 할까?

대다수의 관리자들은 각자에게 한가지씩 일을 할당할 것인데, 이 경우에 병렬 진행이 최대화될 수 있다고 보기 때문입니다. 하지만 이것이 최고의 코드로 가는 가장 빠른 지름길일까요? 저는 그렇지 않다고 봅니다. 제 생각에는 관리자가 사람들에게 함께 작업하지 말라고 지시했을 겁니다. 그들이 따로 떨어져서는 할 수 없는 것을, 다 같이 모여서 도대체 무슨 일을 할 수 있을런지 그 관리자는 아마 상상조차 못할 것입니다. 그럴 수 밖에 없는 것이, 사람들이 하나의 문제를 해결하기 위해 각자의 경험을 동원할 수 있도록 허락했을 때 그들이 무슨 일을 할지 한 사람으로서는 상상하기가 무척이나 어렵기 때문입니다. 제가 선호하는 접근법은 관리자가 12명 모두에게 단지 3가지 일만 주고 서로 협동해서 그 일을 하도록 요청하는 것입니다. 그 일들이 완료되면 관리자는 할 일을 3개 더 만들어 냅니다. 사람들은 작업을 완료하기 위해 자기조직화(self-organize)할 수 있는 권한이 있고, 또 매번 다르게 조직화할 수도 있을 겁니다. 이 방식이 잘 돌아가는 이유는 사람들이 “관심사의 섞임”(mingling of concerns)을 통해 서로에 대해 엄청나게 많은 것을 매우 빨리 배울 수 있기 때문입니다. 이런 식으로 학습한 지식은 관리자나 혹은 누구든 딱 한 사람이 모델링한 것의 위험을 피할 수 있는데, 그런 한 사람에 의한 모델링 때문에 모델 주도 접근법(model driven approaches)은 불리해 집니다. (워드 커닝햄, 우리는 팀인가요? 의 인용문 재인용)

Note: 여기에서 관심의 섞임이라는 표현은 전산학자 데이크스트라의 관심사의 분리(separation of concerns)를 빗대에 말한 것 같다. 관심사의 분리는 소프트웨어 설계의 중요한 원칙 중 중요한 하나로 각 모듈별로 다루는 사안들을 서로 분리하라는 의미이다. 다만 이 원칙을 사람 사이에도 적용하는 것은 협력을 저해할 수 있음을 경고하는 것이다.

• 애자일은 앞서의 고정적 방법과 달리 일을 공유한다.
  • 각자 일을 얼마나 진행했는지 매일 공유할 뿐 아니라 내 일, 네 일의 구분선이 뚜렷하지 않다.
  • 애자일에서는 되도록 사람들이 섞이도록 한다.
• 이 경우에 확률적으로 어떤 현상들이 일어날까? 역시 7명이 있고, 모두 90% 확률로 확신을 한다고 해보자. 90% 확률이었따면 개중에는 일찍 끝내는 사람도 분명 있을 것이다(7명 중에 6.3명(7 * 0.9)은 데드라인 이내에 일을 끝낼 것이다.)
• 고전적 장법에선 내가 일을 빨리 끝내는 것이 이프로젝트에 큰 도움이 되지 않는다.
  • 내 일은 내 일이고 다른 사람 일은 다른 사람 일이기 때문이다.
  • 그래서 마감 시간에 맞춰 끝ㅌ나도록 일부러 일을 늘리는 경향도 생긴다.
• 하지만 애자일에서는 내가 일이 빨리 끝나면 다른 사람의 일을 도와준다. 가장 일이 밀려 있는 사람이 누구인지가 확연히 보이기 때문에 프로젝트에서 병목이 되는 사람을 도와주기 쉽다.
• 이렇게 먼저 일을 끝낸 사람이 나머지 사람들을 도와주게 되기 때문에 해당 시점에 나머지 사람들이 일을 제시간에 끝낼 확률이 높아질 것이다.
• 따라서 각기 제시간에 일을 마칠 확류이 90% 확률일때, 모든일을 제시간에 맞출 확률을 구한다고 0.9를 7번 곱할 수 없고 그보다 높은 확률이 되는 것이다.
• 게다가 애자일에선 지식을 공유하기 때문에 좋은 정보는 모두가 곧 알게 된다. 그리고 그 좋은 정보는 각자의 일에 모두 도움이 된다.
  • 서로 판이한 일을 하는 것이 아니고 관련성이 있는 것들을 진행하기 때문이다.
• 이런 새로운 지식, 깨달음은 프로젝트 속도를 높이는데 큰 도움이 되는 경우가 많은데, 애자일에서 이 확륭른 ‘또는’ 확률에 해당한다.
  • 좀 더 자세히 설명하면 예컨대 7명 중에서 한 명이라도 중요한 발견을 하면 나머지 모든 사람이 그걸 공유해 함꼐 이득을 얻는 다는 뜻이다.
  • 이와 반대로 고전적 방법에선 이런 좋은일이 생길 확률이 ‘그리고’ 확률이다.
  • 모든 사람이 제 각기 꺠달음을 얻어야만 전체 프로젝트의 체감 성공률이 높아진다.
  • ‘그리고’ 확률에서는 확률끼리 계속 곱해나가기 떄문에 팀 레벨에서 통찰을 통해 개선이 일어날 전체 확률은 기하급수적으로 떨어질 것이다.
• 하지만 ‘또는’ 확률은 그 일이 안 일어날 확률을 모두 곱해서 그 값을 1에서 뺴면 된다.
  • 따라서 아까의 기하급수적으로 떨어지는 상황을 반대로 뒤집어서 확률이 올라가게 된다. 앞에서 이야기했듯이 사람들은 ‘또는’ 확률을 과소평가하는 경향이 있어서, 이 확률은 생각보다 훨씬 높은 것이다.

이와 관련된 저자의 경험담이 소개된다. 회사 전체가 자바로 개발을 하는데 각 팀별로, 각 개발자별로 담당 서버들이 있는데 회사에서 회사에서 자바 JDK 를 버전업하라고 기한을 몇 달을 줬다. 앞서 말한 파킨슨의 법칙처럼 사람들은 마지막 달에 버전업 작업을 시작했다. 당시 저자는 모팀의 개발자 자리에서 같이 페어 프로그래밍을 하고 있었는데 옆자리의 동료가 점심시간이라 자리를 뜨면서 화면을 흘긋 보더니 “어? 벚전업 작업하시네요? 고생 꽤나 하실 거에요” 하면서 나가는 것이었다. 그분은 알고 봤떠니 그 전주에 버전업 작업을 모두 마친것이었다. 하지만 옆에 앉아서 동료를 도와줄 생각을 아예 하지를 않았던 것이;다. 본인이 한 번 해봤으면 다른 사람을 도와줄 때 시간이 젋반도 안 걸맅넨데 말이다… 그러면 그 팀은 결과적으로 개발자 개개인이 동일한 시행착오를 겪어야 하는 ‘그리고’ 팀이라는 뜻이다.

• 그리고 여기에 더해, 애자일은 되도록 일 진해에 단계(앞서의 분석, 설계, 구현, 테스트, 전개 같은)를 두지 않으려고 한다. 단계가 있으면 시기에 따라 하는 일에 큰차이가 생긴다.
• 하지만 애자일은 마치 프랙털 구조처럼 부분 속에 전체가 들어가게 한다. 그렇게 하면 과거에서 미래를 점쳐보기가 훨씬 쉽다.
  • 일이 진행되루솕 점점 추정 정확도가 높아진다. 대략 서너 번의 반복주기(iteration, 통상 1주에서 1달 사이)만 지나면 종료 가능 날짜가 고전적 방법에 비해 훨씬 더 정확히 예측된다.
  • 이 방법을 통하면 사람들의 낙관적 추정 편향도 피해 갈 수 있다.
• 애자일은 좋은 일에 대해서는 ‘그리고’ 확률을 ‘또는’ 확률로 바꾸고, 나쁜 일에 대헛는 ‘또는’ 확률을 ‘그리고’ 확률로 바꾸는 경향이 있다.
  • 좋은 일은 공유를 해서 한 사람만이라도 중요한 통찰이 있었따면 이걸 공유해서 ‘또는’ 확률로 만들고, 버그 같이 나쁜 일에 대헛는 여러 사람이 중복 검토를 해서(페어 프로그래밍, 코드 공유, 퀵 디자인 세션, 코드 리뷰 등) 모두가 실수해야지만 구멍이 나게 ‘그리고’ 확률로 바꾸는 것이다.

[애자일] 애자일

좁은 의미의 애자일

• 애자일의 좁은 정의로는 ‘애자일 소프트웨어 개발 방법론’은 소프트웨어를 개발하는 한 가지 스타일을 일컫는다.
• 대략 1990년대에 그 모습을 드러내기 시작했는데, 당시에 쓰던 전통적인 소프트웨어 개발 방식이 1990년대의 비즈니스적 상황, 고객의 요구 등과 잘 맞지 않는다고 생각한 사람들이 있었다.
• 그들은 각자 자기들만의 개발 방식을 만들어서 실천하고 있었다. 그런데 이 방법들 간에는 크게 보아 유사성이 있었다.
• 그래서 이 방법들의 창안자 스무 명 정도가 2001년에 스노우버드 스키장에서 만나서 선언문을 작성한다. 자신들이 사용하는 방법 이면에 깔려 있는 공통된 철학, 추구하는 가치와 원칙을 추려냈다.
• 이를 애자일 선언문이라 한다. 공식적으로는 유일하게 애자일을 정의한 문서이다. 그때 영미인들에게도 생소한 형용사인 애자일(agile) 이라는 단어가 이 방법론들을 대표하는 이름이 된 것이다.

애자일은 보통 ‘기민한’ 혹은 ‘민첩한’이라는 뜻으로 번역한다. 예상치 못한 상황이 생겼을 때 대응을 잘할 수 있다는 뜻이므로 일반적인 ‘빠른’ 과는 차별성이 있다. ‘agile’을 기민한으로 번역하는 이유에 대해서는 ‘agile의 번역’ 이라는 글을 참고하자. http://agile.egloos.com/4368289

• 당시 주도적인 소프트웨어 개발 방식은 계획주도의 방식이었다.
• 계획주도 방식에서는 초반에 계획을 정교하고 꼼꼼하게 만들려고 엄청난 노력을 한다.
  • 그러면 실행단계는 간단해지고 예측 가능해진다고 생각하기 때문이다.
  • 하지만 애자일은, 불확실성이 높은 일에 대해서는 애초에 이것이 불가능하다고 본다.
  • 불확실성이 크기 때문에 미리 분석하고 설계하는데 한계가 있다는 것이다.
• 사실 애자일은 불확실성이 클 때 우리가 어떻게 해야 하는지를 고민한 결과물이다.
  • 따라서 애자일은 불확실성이 높은 프로젝트에 더 적합하다.
  • 애자일이 불확실성을 다루는 방식은 좀 더 짧은 주기로 더 일찍부터 피드백을 받고, 더 다양한 사람으로부터 더 자주 그리고 더 일찍 피드백을 받는 것으로 정리할 수 있다.
  • 이런 특징을 가진 애자일 방법론은, 마침 시대가 바뀌면서 불확실성이 낮은 프로젝트는 비즈니스적 가치가 없어ㅣ지고 불확실성이 높은 프로젝트를 하는 것이 일반적이 됨에 따라 빠른속도로 인기를 얻게 되었다.

좀 더 넓은 범주의 애자일

• 애자일을 단순히 소프트웨어 개발 방법론이라는 울타리에 가두어 보지 않고, 일하는 한 가지 스타일, 혹은 더 넘어서서 삶을 사는 방식으로까지 확장해 보는 것이다.
• 이건 넓은 의미의 애자일이 될 것이다. 이런 시각이 가능한 이유는 불확실성이 소프트웨어를 개발할 때뿐만 아니라 모든 종류의 업무, 혹은 삶에 내재하고 있기 때문이다.
• 그러면 우리의 삶에 애자일을 어떻게 적용할 수 있을까?
  • 이미 눈치챘을 수 있겠지만, 사실 우리가 이제까지 이야기했던 학습과 협력이 애자일이 불확실성을 다루는 핵심적인 구동원리이다. 다시 말해, 학습과 협력을 증진해서 우리 삶에 애자일을 적용하고, 또 이를 통해 불확실성과 친구가 될 수 있다. 그럼 학습과 협력이 어떻게 불확실성에 대한 대응전략이 될 수 있을까?

학습과 협력, 그리고 애자일

• 학습에 대해 먼저 이야기해보자.
  • 불확실하다는 것은 우리가 이동할 때 목표점의 위치가 자주 바뀌거나 우리 위치가 자주 바뀌거나 하는 상황으로 비유해 볼 수 있다.
  • 그럴 경우일수록 우리는 가다가 멈춰 서서 주의를 둘러보고 목표점과 우리 워ㅣ치를 확인하는 것 같은 피드백을 통해 방향을 재조정하는 일을 자주해야 할 것이다.
  • 초기 계획대로 가면 완전히 동떨어진 곳으로 갈 수 있을 것이다. 다시 말해 이동하면서 계속 배워나가야 한다는 뜻이다. 불확실성이 높을수록 학습을 잘해야 하는 것이다.
  • 새로운 상황에 대해서 계속 배우고 내가 맞춰 나가야 한다.
  • 따라서 우리의 학습 능력을 향상시킬 수 있따면 우리는 불확실성에 대해 더 잘 대응할 수 있을 것이다.
• 그러면 협력의 경우는 어떠할까? 여기에선 두 가지로 나누어 생각해보자. 안 좋은 일이 생기는 경우, 그리고 좋은 일이 생기는 경우.
• 불확실한 상황일수록 리스크가 높은 것이고, 고로 안 좋은일이 벌어질 확률이 높을 것이다.

주식 투자를 할 떄를 예를 들 수 있다. 보수적인 투자와 공격적인 투자를 생각해보자. 보수적인 것은 불확실성이 낮고, 공격적인 것은 불확실성이 높다. 둘 중 어느 것의 리스크가 클지 둘 중 돈을 잃는 안 좋은 일이 벌어질 확률은 어디가 높을지 생각해보자. 결과는 누구나 쉽게 생각할 수 있을 것이다.

• 일반적으로 안 좋은일이 벌어질 확률은 ‘또는’ 조건으로 연결되어 있을 떄 더 높아진다. 앞에서도 이야기했지만, ‘또는’ 조건은 하나라도 문제가 생기면 전체에 문제가 생기는 상황이다.
  • 한 사람이라도 실수하면 전체 조직에 구멍이 뚫리게 되는 것이다.
• 반대로 ‘그리고’ 조건은 모든 변수에 문제가 생겨야 전체에 문제가 되는 상황이다.
  • 이 경우 전체에 문제가 생길 확률은 기하급수적으로 낮아진다.
  • 모든 사람이 실수해야지만 구멍이 뚫리는 경우다.
  • 결과적으로 애자일ㅇ느 서로의 업무를 공유하고 상호 검토하는 협력을 통해 불핸한 일을 ‘또는’ 조건에서 ‘그리고’ 조건으로 바꾸게 한다.
• 반대로 불확실한 상황에서는 예상치 못한 좋은 일이 생길 확률도 있다. 그런 경우 이 좋은 일이 확장해야 한다
  • 애자일은 좋은 일의 상황에 대해서는 ‘그리고’ 조건을 ‘또는’ 조건으로 바꾸게 한다.
  • 모든 사람이 통찰을 얻어야 업무를 개선할 수 있는게 아니라 한 사람이라도 통찰을 얻으면 그걸 공유해서 전체가 개선되는 것이다.
• 정리해보면 다음과 같다.
  • 학습과 협력은 불확실성이 큰 상황에서 좋은 대응전략이 된다.
  • 우리의 삶도 불확실하기 떄문에 학습과 협력은 현명한 전략이 될 것이다.
  • 그런데 마침 애자일의 핵심 구동원리가 학습과 협력, 즉 함께(협력) 자라기(학습)이다.
  • 그래서 저자는 불확실한 삶을 살아나갈 떄 애자일적 태도가 도움이 될것이라 생각한다.
  • ‘함께 자라기’ 하는 삶은 애자일적인 삶이라고 할 수 있다. 이 측면에서 애자일을 좀 더 들여다보자.

[애자일] 애자일의 씨앗

• 종종 10분 같이 짧은 시간 안에 애자일에 대해 설명해 달라고 부탁하는 분들이 있다. 10분 만에 애자일을 전달하는 것은 무척 어렵다.
• 저자는 그런 상황 속에서 애자일의 핵심, 애자일의 씨앗이라 할 수 있는게 무엇일까 고민하였다.
• 글이나 말을 통해 애자일을 배우는 것은 한계가 있고 결국은 어떤 씨앗을 갖고 각자 자신의 토양에서 고유한 나무를 키워내야 한다고 믿었기 때문이다.
• 저자는 그 씨앗을 한 문장으로 압축해 다음과 같이 표현해 봤다.

고객에게 매일 가치를 전하라

이 문장의 단어들은 각기 모두 중요하다. 각 단어에 대해 다음과 같이 여러 가지 질문을 해볼 수 있다.

• 고객에게
  • 우리의 진짜 고객은 누구인가?
• 매일
  • 어떻게 점진적으로 가치를 전할 것인가?
  • 어떻게 보다 일찍, 그리고 보다 자주 가치를 전할 것인가?
• 가치를
  • 무엇이 가치인가?
  • 지금 우리가 하고 있는 일이 정말 가치를 만드는 일ㅇ니가?
  • 지금 가장 높은 가치는 무엇인가?
  • 비슷한 수준의 가치를 더 값싸게 전달하는 방법은?
• 전하라
  • 가치를 우리가 갖고 있지 않고 고객에게 정말 전달하고 있는가?
  • 고객이 정말 가치를 얻고 있는가?

‘매일’한다는 것의 반대는 ‘몰아서’ 하는 것이다. 벼락치기 하지 않고 매일 조금씩 해나간다는 것이다. 그래서 저자는 점진적이라는 표현을 하였다. 가치를 프로젝트 끝날 때 몰아서 주는게 아니라 오늘 조금, 다음날 조금 더 이런 식으로 말이다.

• 그럼 이 질문들이 앞에서 말한 학습 및 협력과 어떻게 연결되는가 풀어보도록 하자.
• 우선 학습적 면에서 보면, ‘매일’ 하는 것은 학습의 빈도를 말한다.
• 불확실성이 높을수록 빈도가 자주 있어야 한다.
• 예를 들어 눈을 감고 목적지로 가는데, 만약 목적지가 움직이는 정도가 크다면 그럴수록 잠깐씩 현재 위치와 목적지의 위치를 확인하는 빈도가 잦아야 할 것이다.
• 그리고 좋은 학습은 질 높은 피드백에서 오게 된다.
• 만약 그것이 가짜 피드백이라면 잘못된 학습이 될 수도 있을 것이다.
• 진짜 가치를 전달할 떄 우리는 진정한 피드백을 받을 수 있다.
  • “이런저런 기능이 있다면 어떻겠어요? 구입하실건가요?” 에 대한 대답은 그리 믿을 만하지 않다.
• 그리고 다시 ‘매일’로 돌아가서, 프로젝트의 말미에만 하는게 아니라 시작하는 날부터 ‘매일’이 되기 때문에 학습이 처음부터 발생하게 된다.
• 즉, ‘매일’에는 빈도와 동시에 이른 시점부터 시작한다는 의미가 있다. 이러면 학습의 복리 효과를 얻을 수 있게 된다.
• ‘협력’이라는 면에서는 ‘고객에게’ 라는 부분이 그 중요성을 말하고 있다.
  • 소프트웨어 개발이건 뭐건 간에 홀로 결과물이 나오는 경우는 드물다. 협력을 통해 결과물이 나온다.
• 여기에서 고객은 넓은 의미로 이해관계자(프로젝트의 결과에 영향을 주거나 받는 사람)라고 생각하자.
  • 우리에게 돈을 주고 일을 맡긴 사람뿐만 아니라 우리의 이해관계자는 모두 고객으로 여겨야 한다.
  • 이렇게 되면 의외로 협력의 대상이 넓어지게 될 것이다. 이것이 정상이다.
• 하지만 종종 애자일을 한다 해놓고는 실상 고객을 완전히 잊어버리고 자신들끼리 북치고 장군치고 하는 모습을 보곤 하는데, 이건 애자일의 핵심을 놓치고 있는 것이다.
• 그리고 협력을 할 때 ‘가치를 전하면’ 협력이 쉽다.
  • 왜 그럴까? 우선 신뢰가 쌓이게 된다.
  • 신뢰 자산이라는 말이 있을 만큼 신뢰가 있을 경우 협력의 비용이 낮아지고 원활해진다는 연구가 많다.
  • 그리고 이는 앞의 학습과도 연결되는데 가치를 전달하게 되면 의사소통이 명확하고 구체적이 된다.
• 이렇게 앞의 ‘애자일의 씨앗’에는 애자일의 핵심 구동 원리인 함께 자라기가 내포되어 있다.
  • 그래서 이 질문들을 하루에도 여러 번, 모든 사람들이 한다면 분명 여러분의 자리에서 애자일이, ‘함께 자라기’가 꽃필 것이다.

[애자일] 애자일 도입 성공 요인 분석

• 2010년 여의도에서 애자일 실천법 세미나가 있었는데, 저자가 ‘애자일 도입 성공 요인 분석’ 이라는 발표를 진행했다.
• 다음은 그 발표에서 일부분을 발췌하고 추가 및 수정한 글이다.
• 이 발표는 애자일을 도입한 회사들에게 있어 무엇이 성공과 실패를 가르는 핵심적 요인이었는지를 분석, 정리한 것이다.

애자일 도입 설문

• 일전에 애자일 도입 실태 설문을 진행했고, 약 70여 개의 회사에서 응답을 해줬다.
  • 응답자의 직급은 사원부터 임원가지 다양했는데 43%의 분들이 과장 차장 직급이었다.
• 다음은 애자일을 도입해서 프로젝트 성공에 도움이 되었냐는 질문에 대한 응답이다.
  • 53%가 그렇다고 답했고, 25%는 매우 그렇다고 답했다. 전체에서 78%는 애자일이 프로젝트 성공에 긍정적인 영향을 미쳤다고 본셈이다.
• 애자일 성숙도와 성공도의 상관성이 중간 정도(상관계수 0.43)였고 따라서 대체적으로 애자일 성숙도가 높은 조직은 애자일이 프로젝트 성공에 도움이 많이 된다고 느끼는 것으로 나왔다.
• 흥미로운 점은 성숙도를 낮게 평가한 조직이 성공도도 무조건 낮은 것은 아니라는 사실이다.
  • 성숙도를 낮게 평가한 조직들은 성공도가 낮은 조직부터 높은 조직까지 골고루 분포해 있었다.
  • 하지만 성숙도가 높은데 성공도가 낮은 조직은 없었다.
  • 여기서 우리는, 조직이 애자일을 성숙하게 실천하고 있지 못하다 해도 프로젝트 성공에 도움이 되게 할 수 있다는 희망적인 메시지를 찾을 수 있다.
• 상관성을 보면, 성공적으로 도입한 실천법 숫자가 많을수록 프로젝트 성공도가 높았고, 둘 간의 상관성이 강한것(0.57)으로 나타났다. 실천법 숫자와 성숙도 간의 상관성도 강한 것(0.58)으로 나타났다.

애자일 도입에 대한 무서운 사실

• 프로젝트 성공에 애자일이 도움이 될 수 있는 네 가지 조건은 아래와 같다.
  • 1)고객 참여(여기에서 고객은 프로젝트 발주자를 의미하는 건 아니고, 고객을 대표하는 사람도 포함)
  • 2)리팩터링
  • 3)코딩 후 자동화 테스트 붙이기,
  • 4)코드 공유
• 많은 조직들이 고객 참여와 코드 공유를 뒤로 미룬다.
  • 왜냐? 우리 상황에선 할 수 없다 어렵다 라고 생각하기 때문이다.
  • 두 가지 모두 ‘사람’을 중심이 되기 때문인데 고객 참여는 고객을 설득해야하고, 코드 공유는 개발자를 설득해야 하기 때문이다.
  • 하지만 이런 것들을 제대로 하지 않으면 프로젝트를 성공하기 더 힘들어진다.
• 애자일 초보팀들과 애자일 전문가 팀의 차이는 다음과 같다.
  • 초보팀은 어렵고 두려운일을 하려 하지 않는다.
  • 전문가팀은 무섭고 두렵더라도 중요한 일이라면 그 일을 안하는 리스크를 인식하고 꾸준히 시도한다.
  • 즉, 두려워도 중요하다면 시도해보고자 하는 마인드셋이 중요하다는 것이다.

성숙도가 낮다면 고객 참여는 필수

• 성숙도가 낮아도 고객 참여를 잘하면 프로젝트 성공도 올라간다.(기여도 0.94)
• 성숙도가 높은 조직에선 고객 참여보단 짧은 반복 개발 주기가 성공에 더 도움이 될 수 있다.
  • 그만큼 짧은 반복 개발 주기를 통해 고객 참여가 잘 안될 때를 어느 정도 보완할 수 있따는 뜻일 수 도 있다.
• 애자일에 대해 어느 정도 이해는 하고, 실험도 좀 해봤다 싶은 조직에서 성공 기여도를 높이려면 짧은 반복 개발 주기, 고객 참여, 코드 공유에 관심을 기울여야 한다.
• 고객 참여와 짧은 개발 주기가 프로젝트 성공의 가장 핵심이라 볼 수 있다.
• 고객 참여란 고객 혹은 고객을 대표하는 사람의 참여이다.
  • 프로젝트의 성패를 좌우하는 사람과 최대한 가까운 사람을 참여시키려고 우리가 계속 노력하는 것이 진정 중요하다.

성공하는 조직들에는 항상 뛰어난 애자일 코치가 있다.

• 뛰어난 애자일 코치의 특징은 다음과 같다.
  • 1)의사소통 스타일(팀원, 상사, 팀장과)
  • 2)EQ 및 스트레스하에서의 행동
  • 3)리더십 및 코칭 스타일(동기부여 등)
  • 4)회고를 통한 개인적 학습 능력
  • 5)개인적 성장 의지, 성장 사고관, 자기 효능감
  • 6)관찰 및 상황 파악(sensemaking) 능력
  • 7)일치적 행동(믿는 것을 행동에 옮기는 능력)
  • 8)기술적 능력?
• 애자일 코치는 조직적, 정치적 위치와는 관계가 없다. 오로지 자신의 선택이다.
  • 내가 애자일 코치가 되어야지 하는 결심이 중요하다.
• 기술적 능력 옆에 물음표를 붙였는데 중요하긴 하지만 필수는 아니기 때문이다. 물론 최소한도의 능력 이상은 있어야 하지만 어느 정도 수준을 넘으면 다른 변수들이 훨씬 중요해지는 것 같다.

성과 높은 사람으로서의 전문 SW 엔지니어의 특징

• 성과 높은 사람으로서의 전문 SW 엔지니어(단순히 경력이 긴 사람이 아닌)에 대한 연구로부터 밝혀진 것은 사회적 능력(social/interpersonal skill)의 중요성이다.
• 지적 능력(general mental ability)이 뛰어난 프로그래머들의 성과를 구분하는 것은 사회적 능력임이 밝혀졌다.
• 높은 성과를 내는 엔지니어는 ‘다른 사람과의 협력’을 훨씬 더 자주 언급한다.
• 실제로 뛰어난 SW 엔지니어들은 높인 대인 능력을 갖고 있는 것이 연구로 인해 관찰되었다.
  • 설계, 코딩, 테스팅 등의 SW 개발 활동에 대한 시간 투자는 전문가나 비전문가나 큰 차이가 없는 반면, 리뷰 회의나 다른 사람과 상담하는 등의 의사소통과 협력 활동에선 저눔ㄴ가가 훨씬 많은 시간을 사용한다는 것이 밝혀졌다.
• 탁월한 SW 엔지니어와 그렇지 않은 엔지니어의 차이에선 주어진 업무 외에도 관심을 갖는가 하는 점이었다.
  • 탁월한 엔지니어들은 프로젝트 전반에 대한 큰 그림을 가지려 하고, 경영진에게 더 적극적인 태도로 다가가고, 다른 엔지니어들을 도와준다.
• 결과적으로 보면 뛰어난 애자일 코치는 함께 자라기를 하는 사람이다.

요약

• 1)애자일을 도입해서 성공하는 조직들이 국내에 있다.
• 2)애자일 실천법을 잘 실행하면 성공률도 높아질 수 있다.(애자일을 한 지 얼마 되지 않더라도)
• 3)실천법 중에서 비교적 성공과 직결되는 것들이 존재한다. 그것은 고객 참여, 리팩터링, 코딩 후 자동화 단위 테스트 붙이기, 코드 공유 등이다.
• 4)애자일 성숙도가 낮은 조직일 수록 고객 참여를 하지 않으면 프로젝트 성공이 어렵다.
• 5)무섭고 두렵지만 중요한 일이라면 계속 미루지 말라.
• 6)뛰어난 애자일 코치가 있는 것이 애자일 도입 성공에 핵심적이다.
• 7)뛰어난 애자일 코치는 함께 자란다.

[애자일] 당신의 조직에 새 방법론이 먹히지 않는 이유

• 심리치료 연구에선 기념비적인 연구가 하나있다.
  • 아이였을 때 뉴욕주에서 심리치료를 받은 어른들을 조사했는데 정상적인 생활을 하고 있는 건강한 사람과 그렇지 못한 사람에 대한 차이를 연구했다.
• 심리치료를 한 사람이 누구였느냐가 중요한 요인으로 작용했다.
  • 당시 아이들 사이에선 유능한 치료사를 일컫는 별명이 슈퍼슈링크(뛰어남을 뜻하는 super와 정신과의사를 일컫는 shrink를 합성한 신조어)였다.
• 치료자 효과란, 치료자가 누구냐에 따라 상담효과가 좌우되는 것을 말한다.
  • 연구에 따르면 우울증 치료에 있어 상위 삼분의 일에 해당하는 정신과 의사가 설탕약을 준경우가, 하위 삼분의 일에 해당하는 정신과 의사가 항우울제를 준 경우보다 치료화가가 더 높았다.
  • 설탕물을 받아먹더라도 뛰어난 의사한테 가는 경우에 치료효과가 더 높다라는 놀라운 결과가 나온 것이다.
• 어떤 기법이나 방법론이 말고 있는 것은 극히 부분적이며 오로지 그것으로만 지도를 삼기에는 위험이 클 수 있다.
• 자신이 관심 있는 분야에 “만약 ~하면 ~하라” 라는 널리 인정되는 규칙이 있는가, 그런 규칙들을 잘 따른다면 얼마나 성과를 낼 수 있을까 생각해봐라.
  • 만약 그런 규칙이 커버하는 부분이 넓다면 해당 분야는 ‘단순한 도메인’에 해당한다.
  • 소위 베스트 프랙티스가 먹히는 분야이고, 결과 예측이 가능한 분야이다.
  • 하지만 반대로 맥락을 가르는 보편적 규칙들이 별로 없다고 생각이 든다면, 결과를 예측하기 어렵고 불확실성이 높다면, 해당 분야는 '복잡한 도메인' 이 된다.
  • 통상 사람 요소가 차지하는 비율이 많을수록 복잡한 도메인에 속한다.
  • 상담이 그렇다. 이런 복잡한 분야일수록 어떤 특정 기법의 효과보다도 치료자 효과가 더 큰 영향을 미칠 것이다.
  • 그렇다면 어떻게 해야할까? 슈퍼슈링크들을 찾고 그들을 연구하고 육성해야 한다.(주변의 슈퍼슈링크들은 누구이고 평소 행동은 어떻게 다른가 주목해보라.)
    • 그러면서 이런 연구를 토대로 우리가 사용하는 기법과 방법론들을 더 발전시켜 나가야 될 것이다.
• 새 프로젝트를 진행 할 때에 우리가 어떤 방법론을 쓰느냐는 문제보다도 누가 참여하는가가 훨씬 더 압도적으로 중요한 문제일 것이다. 저자는 아래와 같이 생각한다.

예를 들어 애자일 방법론 도입을 원하는 팀장이라면 "나는 어떤 팀장인가"를 먼저 자문해봐야 하지 않을까 싶다. 내가 어떤 팀장인지가 전혀 바뀌지 않으면서 새 방법론만 도입한다고 무슨 효과가 있을까. 반대로, 항우울제보다도 강력한 설탕물을 쓸 수 있는 의사처럼, 별 볼 일 없어 보이는 방법론일지라도 그걸 처방하는 팀장에 따라 전혀 다른 효과가 있을 것이다.

[애자일] 애자일을 애자일스럽게 도입하기

• 많은 기업들이 애자일을 포함 정말 다양한 방법론을 도입하려 노력해왔찌만, 그노 력에 비해 성공률은 그렇게 높은 것 같지 않다. 왜 그럴까?
  • 마지막 부분에서 이 질문에 한 가지 답변을 하게 될 것이다.
• 도요타가 자동차 개발, 설계에 대해 업계에 혁신을 가져왔다는 점에 대해선 반론을 하기 힘들다.
  • 그래서 여러 기업들이 앞다 투어 도요타 방식을 도입하려 했지만 전부 실패했다.
• 도요타가 도요타 일 수 있었떤 것은 칸반 같은 개별 ‘베스트 프랙티스’가 아니라 그런 실천법들이 생겨날 수 있는 문화적 풍토와 생성적 과정 때문이었다.
  • 우리가 배워야 할 것은 칸반 이면의, 칸반이 나올 수 있었던 구조와 문화이다.
• 모 매체와의 인터뷰에서 기자한테 저자는 아래와 같은 질문을 받았다.
  • “애자일을 진행하는 가운데 가장 빈번히 빚어지는 폐단은 무엇인가??”
• 저자의 답변은 아래와 같았다.
  • “애자일을 반애자일적으로 진행하는 것이다. 예컨대 애자일은 불확실한 상황에 대한 접근법인데, 애자일을 도입할 떄 확실성 위에서 진행하려고 한다면 문제가 된다.”
• 애자일 방법론을 도입할 때 뭘해야 할지 명확하게 알려달라고 한다.
  • 근데 그모습은 전혀 애자일적이지 않다.
  • 찾아가는 모습이 애자일이다.
  • 어차피 방법론 도입이라는 것이 매우 불확실한 것이기 때문에 정답이 있을 수 없다. 이전 경험이 이번에도 정확히 들어 맞는다고 말할 수 도 없다.
  • 이것은 모든 종류의 방법론 도입에 적용된다.
  • 왜냐하면 방법론 도입은 태생적으로 불확실성이 높기 때문이다.
  • 그럴 때 현명한 전략은 정해진 수순을 따르는 것이 아니라 곁에 있는 사람들과 함께 주변을 탐색하고 조금 나아가고 확인하고를 반복하면서 우리의 현 맥락에 맞는 좋은 전략들을 스스로 만들어 가는 것이 아닐까 한다.
  • 그리고 이 과정에서 함께 자라기가 귀중한 나침반이 되어줄 것이다.