• 팀에서 동료들과 함께 읽었던 부분을 정리했습니다. 우리 회사도 스크럼 개발 방식을 사용하는데 스크럼의 기저에 깔려있는 철학을 이해하면 스크럼에서 무엇을 얻어야 할지 더 잘 알 수 있다고 생각합니다.
• 아래 내용들은 책의 원문을 최대한 그대로 적었습니다.

1. 사회적 상호작용인 스크럼

스크럼 회의에서 하는 일이 전날 무엇을 했는지, 새로운 문제들은 어떤 것이 있는지를 보고하고, 다음날에는 무엇을 할 것인지 확언(확인이 아니라, 확언입니다.)하는 것이 전부라면, 웹에서 돌아가는 데이터베이스 프로그램을 하나 만들어서 이런 정보들을 저장하면 안 되나요?

다른 사람들에게도 이 얘기는 그럴싸하게 들렸던 것 같다. 그러나, 사람 사이의 상호 소통 같은 것들은 자동화될 수 없다고 생각하기 때문에 다음과 같이 답변했다.

“팀은 스크럼 회의를 통해 단순한 정보 공유 이상의 것을 얻을 수 있습니다. 사람들은 이 회의에서 단순히 어제 무엇을 했는지에 대해서만 얘기하는 것이 아닙니다. 모든 사람 앞에서 말 함으로써 다른 사람이 무엇을 하고 있는지를 모두 알게 되고 나주에 도움을 줄 수도 있습니다. 또한 현재 문제가 무엇인지를 얘기하는 데 그치지 않고 문제를 관리자와 얼굴을 마주보며 얘기할 수 있습니다. 사람들이 정직할 수 있게 용기를 줍니다. 또한 지금 겪고 있는 문제를 관리자가 해결하도록 압박할 수 있습니다. 그리고 무엇보다도, 이 회의는 서로가 서로에게 다음에 무엇을 할 것인지 약속하게 합니다. 이는 사람들의 신용과 믿음을 모두 시험 받도록 합니다. 스크럼은 팀원들 간에 신뢰를 구축하게 해 주는 높은 수준의 사회적 상호작용입니다.

2. 스크럼에 대한 유용한 멘탈 모델

2.1 소프트웨어 개발은 단순한 제조 과정이 아닌 신제품 개발이다.

처음 SW 개발을 하던 시절에는 SW 개발을 제조업으로 생각하고 그쪽에서 비슷한 프로세스를 가져왔는데, 그게 큰 실수였다. 제조 공업에서는 조립라인으로부터 똑같은 모델을 만들기 위한 ‘반복 가능하게 정의된'프로세스가 의미가 있다. 하지만 SW 개발은 뭔가 새로운 걸 만들어 내는 과정인데, 비록 SW의 일부분이 재사용 된다곤 하지만, 매번 형태나 설계가 달라진다. 또한 SW는 매번 배치될 때마다 다른 모양을 가지므로 다른 프로세스가 필요하다.

이런 이유로 SW 개발은 신제품 개발 모델과 더 잘 어울린다. 새로운 것을 만들기 위해서는 연구와 창조, 학습 과정이 필요하다. 이런 활동은 제품 제조공정과는 완전 다른 가정에 기반하고, 제조 공정에서 사용하던 추정, 계획, 추적 방법과는 완전히 다른 방법을 써야 한다. SW 요구사항은 정확하지도 심지어 쉽게 끝나지도 않기 때문에 항상 연구 과정을 수반하게 된다.

노나카와 다케우치는 하버드 비즈니스 리뷰에서 혁신적인 회사가 어떻게 신제품을 만들어내는지를 기술하였다. 그들은 가장 경쟁력 있고 혁신적인 10개의 회사를 분석해서 다음과 같은 공통점을 발견했다.

• 내재된 불안정성(Built-in instability):
  • 팀원들에게 새로운 것을 연구하고 만들어 낼 수 있는 자유로운 분위기를 제공하지만 동시에 높은 수준의 제품 개발을 요구한다.
• 자기 조직적인(self-organizing) 프로젝트 팀:
  • 프로젝트 팀은 기존 지식이 통하지 않는 새로운 분야를 개척하게 됨에 따라 자기 조직적인 특징을 띄게 된다. 이 시기에는 모호함과 변동이 넘쳐난다. 그대로 놔두면 프로세스는 알아서 자신만의 동적인 질서를 만들기 시작하고 팀은 스스로 리스크를 감수하며 새로운 개념을 도출해내고 자신만의 아젠다를 만들어내기 시작한다.
• 중첩(overlapping) 개발 단계:
  • 요구사항들이 명확하지 않아 당장에 주어진 정보만 가지고 개발해야 한다. 그리고 개발 과정 도중에서야 비로서 요구사항들이 분명해지는, 그런 개발 환경 속에서 일관성 있게 새로운 제품 개발을 완료하기 위해서는 연구, 개발, 테스트 단계를 꼭 중첩시켜서 돌려야 한다. 신제품 개발에서 대부분의 문제는 프로젝트의 개발 단계가 분리되었을 때 나타난다. 경험상, 이렇게 개발 단계를 중첩시키면 공동의 책임감과 협동심, 헌신과 몰입을 불러일으킨다. 문제를 푸는데 온 집중을 다 하게 하고, 솔선수범하게 하고 다양한 기술을 익히게 하며, 시장 상황에 대한 감각을 유지할 수 있게 해 준다.
• 다중 학습(Multti-learning):
  • 반드시 팀을 외부의 정보 공급원과 가까이 둬서 환경의 변화에 재빨리 반응할 수 있게 해야 한다. 이런 학습은 1) 다양한 크기(개인, 그룹, 조직) 2) 다양한 기능, 이 두 가지 차원을 따라 진행된다.
• 눈에 띄지 않는 제어(subtle control):
  • 팀이 창조적이고 효과적이기 위해서 대부분의 경우에는 간섭을 받지 않는다. 그러나 관리자는 팀이 모호함이나 긴장 때문에 걷잡을 수 없는 혼돈에 빠지지 않도록 일정하게 제어해야 한다.
    • 팀원을 뽑고 지속적으로 팀의 균형을 잡아주고,
    • 열린 작업 공간을 만들어 주고,
    • 고객과의 잦은 대화를 유도하고,
    • 팀 단위의 효율을 기준으로 평가 보상 체계를 설립하고,
    • 전체 개발 단계에서 나타나는 흐름의 차이를 조율하고,
    • 실수를 관대하게 받아들이고 미리 예상하며,
    • 관련 팀들도 자기 조직적이 되도록 유도하는 등의 관리가 필요하다.
• 학습의 전파(Transfer of learning)
  • 기존의 팀원을 새 팀에 심어라.

2.2 지식을 생성하는 스크럼

SW 개발은 신제품 개발의 결과고, 이 과정에서 필연적으로 연구, 창조 과정이 필요하다. 그리고 이런 연구와 창조 사이의 공통점은 지식 생성에 있다.

고객은 자신의 요구사항에 대해 구체적이지 못하여 묵시적인 형태로 요구하게 되는데, 이런 이유로 개발자의 요구사항 수집은 곤경에 처하게 된다. 이런 상황에서도 우리는 디자인 결정을 거듭해 나가며 지식을 늘려나가고 결과적으로 실행 가능한 코드를 생산한다. 이런 면에서 SW는 암묵지가 아니라 코드화 된 형식지라고 할 수 있다.

지식 생성의 고나점에서 스크럼은 지식의 사회화, 외부화, 종합화, 내재화라는 순환을 통해 지식 생성을 촉진하는 효과가 있다.

• 암묵지에서 암묵지로: 사회화는 경험 공유를 통해 암묵지를 전달한다.
• 암묵지에서 형식지로: 외부화(책은 구체화라고 함)는 암묵지를 명확한 생각으로 전환하고, 이를 말이나 형태로 표현하는 과정이다.
• 형식지에서 형식지로: 종합화(책은 연결화라고 함)는 개념을 지식으로 시스템화 하는 과정이다.
• 형식지에서 암묵지로: 내재화는 타인의 형식지를 받아들여 써먹을 수 있는 지식으로 만드는 과정이다.

데일리 스크럼 회의는 이런 순환을 보여주는 좋은 예다. 팀원의 암묵지는 스크럼 회의를 통해서 사회화 된다. 이런 지식의 구체화(외부화)를 통해 스프린트 백로그에 들어 있는 아이템이 해결되기도 하지만 그것과 상관없이, 다른 팀원들에게 유용한 지식을 제공할 수 있다. 다른 팀원들은 이 지식을 다른 구체화(외부화)된 지식이나 자신의 암묵지와 결합하면서 내재화해서 그날의 작업에 활용한다. 조직 내에서 이런 스크럼 실천방법을 통해 앞의 지식 순환을 계속 적용하게 되면 ‘지식 나선’이 만들어지게 되고 이를 통해 지식을 조직 내에 전파할 수 있게 된다.

스크럼 팀은 아래의 메커니즘을 통해 지식을 창출한다. 비록 과정을 순서대로 써 놓긴 했지만 개발자는 상황에 맞게 순서를 바꿀 수 있다.

• 암묵적 공유: 개발자는 둘, 셋 이상이 동시에 작업하거나 스크럼 회의에서 요구사항이나 디자인에 관련된 아이디어를 서로 공유한다.
• 개념 형성: 패키지, 클래스, 관계, 상호작용 같은 디자인 모델 생성 등이 예이다.
• 개념 검증: 개발자는 요구사항과 디자인이 잘 맞는지 확인한다.
• 원형(archertype) 구축: 시제품 개발 등이 예이다.
• 지식의 이동(Cross leveling of knowledge): 기본적으로 이 과정은 전체 순환을 처음부터 다시 시작하게 한다.

2.3 복잡계 과학 측면에서의 스크럼

앞에서 SW 개발을 연구, 창조가 필요한 신제품 개발과정이라고 가정했기 때문에, 이들 조직 역시 자기 조직적인 프로젝트 팀이 되어야 하고 중첩적인 개발 단계를 가져야 한다고 제안했다. 즉 이 말은, 스크럼 조직이나 스크럼 프로세스는 통계적으로 규정될 수 없고 반복 가능하지 않다는 것을 의미한다. 스크럼 실천방법 적용 사례를 반복할 수 있을지 모른다는 기대를 하는 건 자유지만 적용 결과는 조직적으로나 프로세스 구성에 있어서나 매번 다를 것이다. 자기 조직화된 조직의 역동성(dynamics)을 이해하기 위해서는 복잡계 과학을 잘 아는게 도움이 되고 이 중에서 자기 조직화되는 팀에 대해서 잘 아는게 좋다.

자기 조직화가 잘 된 팀의 특징은 다음과 같다.

• 열린 시스템(open system)이다.
  • 스크럼 팀에서는 고객이나 테스트, 제품 개발 지원 팀 같은 다른 팀원들과 정보를 교환한다.
• 역동적(dynamics)이다.
  • 자기 조직화 체계는 끊임없이 변화한다. 스크럼 팀은 다양한 시간규모에 맞춰 끊임없이 재조직화된다. 이런 재조직화는 하루 중 매분마다, 일일 스크럼 회의를 하는 매일마다, 스프린트 계획 회의를 하는 매달마다 일어난다.
• 몰입(flow)한다.
  • 스크럼 팀에서는 1) 매일 개발자 사이에서
  • 2) 스크럼 회의 동안 개발자와 스크럼 마스터 사이에서
  • 3) 계획 회의(또는 날마다) 동안 고객과 스크럼 개발 팀 사이에서 이 몰입감의 흐름은 끊임없이 일어난다.
• 밀도 있는 국소 상호작용(dense Local Interaction)에 의지하기
  • 행위자는 다른 행위자와 몇 가지 규칙에 따라 상호작용하고, 지속적인 몰입 상태로 정보를 교환한다. 스크럼 팀에서는 일일 혹은 정기적인 스크럼 회의와 스프린트 데모, 스프린트 계획 회의를 통해 정보와 지식을 공유한다.
• 창발성(emergence)
  • 창발성이란 ‘전체는 부분의 합 그 이상이다.’와 같은 의미이다. 터뮤니없어 보이는 단순한 규칙들이 모여 응집된 창발적 현상을 만들어낸다.
  • 스프린트 기간 동안 할당된 제품 백로그는 절대 변경하지 않는다는 규칙은 큰 반향을 불러 일으킨다. 고객이 계속 기능을 추가할 수 있다 하더라도 스크럼 팀은 스프린트 동안의 목표를 보장 받았기 때문에 방해 받지 않는다. 해당 목표를 달성하게 되면 스크럼 팀은 신용을 유지하고 고객의 신뢰를 얻는다.
  • 이 규칙 하나가 고객과 팀 간의 더욱 단단한 신뢰 관계를 창발적으로 만들어낸다.
• 구성 단위(building blocks)와 집합성(aggregation)
  • 다중 스케일 효과(multi scale effects)라고 불리기도 한다.
  • 구성 단위란 레고 세트의 일부처럼 계속 반복해서 사용할 수 있는 구조를 의미한다.
  • 집합성은 이들 구성 단위를 결합하는 능력을 뜻한다.
  • 각 단계별로 여러 구성 단위가 서로 결합해 다음 단계의 구성 단위가 만들어진다.
• 꼬리표 달기(tagging)
  • 꼬리표는 행위자나 사물에 임시로 붙여놓는 이름 같은 것인데, 이를 통해 행위자나 사물 간의 그룹 짓기를 촉진한다.
• 다양성과 전문성(diversity and specialization)
  • 다양성은 자기 조직적 체계 안에 다양한 종류의 행위자가 있다는 것을 의미하며, 전문성은 이 다양성의 근원이 된다. (직군과 직무 개념)
• 내부의 공유 모델들(internal and shared models)
  • 각 시스템 안에서 행위자는 각각 그들만의 내부 모델을 가지며 동시에 다른 행위자와 공유하는 공유 모델도 가지고 있다. 이런 내부 모델은 행위자 간의 상호작용 중에 발생하는 흐름에 영향을 받는다.
  • 스크럼 팀에서는 스프린트 목표와 진행 중인 백로그, 요구사항, 아키텍쳐는 공유 모델이 되고 개발자는 각자의 내부 모델을 맡는다.
• 비선형 역학(nonlinear dynamics)
  • 비선형 역학은 행위자 집단에서 발생하는 피드백이 비선형적인 법칙을 따르는 것을 의미한다. 이런 현상은 피드백 루프가 보여주는 긍정적이면서도 부정적인 특징이다.
  • 개발자들은 서로의 지식을 공유하고 믿고 의지하며 고객과 자주 대화하고 사용 중인 기술에 대한 학습을 꾸준히 한다 하더라도, 이런 부분들이 모인 효과는 생산성에 있어서 비선형적으로 나타나게 된다. 어떤 팀은 같이 일한 지 첫 3개월만에 생산성을 두 배로 늘렸고, 4개월째에 다시 두 배로 늘릴 수 있었다. 어떤 최상의 팀은 가장 높이 생산성을 올렸는데, 단 몇 개월만에 10배로 늘렸다.

정리하며..(Chang 생각)

• 스크럼은 단순히 매일 아침 모여서 스탠드업 미팅을 하는 행위 이상입니다. 특히 저는 스크럼 팀의 가치가 “다양한 팀원들이 각자의 정보를 공유하고 서로를 믿으며 협력하고, 시스템 완성을 위해 최선을 다하는 것에 있다.”라는 저자의 말이 가장 인상적이었습니다.
• 특히 팀원들의 신뢰, 상호작용, 그리고 그 상호작용을 통한 지식의 생성, 정리, 유통이 없다면 그것이 정말로 제대로 된 스크럼팀이라고 할 수 없다는 생각도 들었습니다. 그래서 데일리 스크럼을 통해서 모든 스쿼드 & 팀들이 이런 것들이 잘 되었는지를 체크해보면 스쿼드&팀의 메타인지를 높일 수 있다고 생각합니다.
  • 내가 내 일을 잘 정리하는 것
    • 오늘 스크럼을 통해서 나는 지난 체크인 이후에 무슨 일을 해냈는지를 정리해서 잘 얘기했다.
    • 나는 지난 체크인 이후로 겪었거나, 앞으로 겪을 문제가 무엇인지를 잘 얘기했다.
    • 내가 이번 체크인 이후에 할 것이 무엇인지 잘 정리해서 얘기했다.
  • 동료와의 상호 작용
    • 나는 동료가 어떤 문제를 겪고 있는지를 잘 알게 되었다.
    • 나는 동료가 어떤 문제를 겪는지는 잘 모르겠지만, 동료가 어려움을 겪고 있다는 느낌을 받아서 이것을 스크럼이 끝난 후 동료와 얘기했다.
    • 나는 동료가 겪고 있는 문제를 해결할 수도 있을 것 같은 방법이 뭔지 알고 스크럼 미팅 이후에 이 방법을 동료와 얘기했다.
    • 스크럼에서 동료가 해결한 과업을 보니, 내 문제에도 도움이 될 것 같다는 생각이 들어서 동료와 짧게 얘기를 나눴다.
  • 팀으로서의 스크럼
    • 우리는 오늘도 스쿼드에서 진행하고자 하는 스프린트 목표를 조금 더 달성할 수 있을 것이다.
    • 스프린트 목표를 달성하기 위해서 팀이 극복해야 하는 문제가 무엇인지를 알게 되었다.
    • 팀이 극복해야 할 문제는 정의하지 못 했지만, 어려움이 있다는 것은 알게 되었다.
    • 스쿼드가 겪는 문제를 스크럼 마스터(PO)가 알게 되었다.
      • 그 문제를 스쿼드 마스터가 해결하지 못하고 있다는 것을 알았다.
• 그리고 단순히 스크럼팀의 일을 스쿼드 내부의 일이라고 보기보다 “고객이 참여하는"이라는 가치를 실현하는 것이 정말 중요하다는 생각이 들었고, 고객이나 고객의 대변자를 스크럼팀에 포함시키는 세련된 방법을 강구해야 한다는 생각이 강하게 들었습니다.