책 "스크럼" 요약: 3장 - 스크럼의 실천법

서론

이 글은 스크럼 - 팀의 생산성을 극대화시키는 애자일 방법론 책의 3장 "스크럼의 실천법" 의 내용을 요약한 책이다.

말이 요약이지 읽으면서 밑줄 친 내용을 그대로 옮겨놓은 것에 불과하다. 스스로 리마인드하기 위해 기록해둔 내용이기 때문에, 본문을 읽지 않고 아래 내용만 읽어서는 내용이 매끄럽게 이해되지 않을 수 있다.

원문을 읽어보기를 강력하게 권한다.

1. 스크럼 마스터

• 스크럼 마스터는 사람들이 스크럼의 가치, 실천법과 규칙들을 받아들이고 실천하게 할 책임이 있다.
• 스크럼 마스터는 경영진에게는 팀의 입장을, 팀에게는 경영진의 입장을 대변한다.
• 스프린트 목표와 이전 일일 스크럼 회의에서의 예측을 바탕으로 예상 진도와 실제 진도를 비교한다.
• 스크럼 마스터는 팀의 속도를 측정하려고 노력한다.
• 제품 책임자 및 스크럼 팀과 함께 스프린트를 위한 제품 백로그를 만들고 스크럼 팀과는 스프린트를 계획, 진행한다.
• 모든 일일 스크럼 회의를 주관하고 장애 요소를 즉시 제거하여 결정이 신속하게 내려지도록 해야 한다.
• 관리자와 함께 진척도를 측정하고, 중요도가 낮은 백로그를 제거할 책임이 있다.
• 스크럼 마스터는 어떻게 팀이 가능한 최고 수준의 생산성을 유지하게 할 수 있을까? 스크럼 마스터는 주로 결정을 내리고 장애 요소를 제거하는 방식으로 그와 같이 할 수 있다.
• 일일 스크럼에서 어떤 결정을 내려야 할 필요가 있다면, 스크럼 마스터는 (심지어는 정보가 불충분한 상황이라도) 즉시 결정을 내릴 책임이 있다.
• 아무 결정도 내리지 않는 것보다 어떤 결정이든 내리는 것이 더 유익하다는 사실을 알게 되었다.
• 스크럼 마스터는 스크럼 팀에 필요한 것이 무엇인지 집중하며, 그것을 위해서라면 단호하게 행동해야 한다. 더구나 장애물 제거에는 결단력과 불굴의 의지가 필요하다.

2. 제품 백로그

• 제품 백로그는 제품이나 프로세스에 관심이 있는 사람이 필요하다고 생각하거나 혹은 제품에 있으면 좋을 것 같다고 생각하는 모든 것을 말한다.
• 제품 백로그는 우선순위에 따라 나열된다. 최우선 제품 백로그가 당면한 개발 활동을 결정한다. 백로그의 우선순위가 높을수록 더 시급히 처리해야 하고 더 많이 숙고해야 하며, 그 가치에 대해서 더 많은 합의를 이끌어 내야 한다.

제품 책임자 한 사람만이 제품 백로그를 관리한다.

• 오직 한 사람만이 제품 백로그를 관리하고 통제할 권한을 가지며, 그 사람을 제품 책임자라고 한다.
• 제품 책임자는 위원회가 아니라 단 한 사람이다. 제품 책임자에게 조언을 하거나 영향을 끼칠 위원회가 존재할 수도 있지만, 어떤 사람이나 집단이 백로그 항목의 우선순위를 바꾸고자 한다면 그럴 권한을 가진 제품 책임자를 설득해야만 한다.
• 제품 책임자가 제 역할을 다하려면 조직의 모든 사람들이 그의 결정을 존중해야만 한다. 그를 제외하고는 어느 누구도 스크럼 팀에게 다른 우선순위에 따라서 작업하라고 할 수 없으며, 스크럼 팀은 제품 책임자가 아닌 다른 사람의 말을 따라서는 안 된다.
• 제품 책임자가 내린 모든 결정은 제품 백로그의 우선순위로 반영되어 있기 때문에 매우 명백해야 한다. 프로젝트의 가시성을 확복하기 위해서는 제품 책임자가 최선을 다해야 하며, 이것이 제품 책임자의 역할에서 가장 힘든 부분임과 동시에 보람 있는 부분이다.

백로그를 개발하는 데 필요한 노력 추정하기

• 백로그가 만들어지면 제품 책임자는 다른 사람들과 함께 그것을 개발하는 데 얼마나 걸릴지 추정한다.
• 추정이 얼마나 정확한지는 제품 책임자와 팀이 얼마나 추정에 능숙하냐에 달려있다. 다시 말해서, 팀이 추정에 익숙해질 때까지 추정은 정확하지 않고 오락가락할 수 있다.
• 만약 제품 책임자가 어떤 최우선 백로그에 대해서 명확하고 신뢰할만한 추정치를 얻을 수 없다면 해당 백로그 항목을 재정의하거나 우선순위를 낮추거나 작업 사항이 아닌 문제 사항으로 변경해야 한다.
• 추정치는 '이 기능을 추정한 시간 안에 반드시 개발해내여 한다.'라는 의미가 아니다. 추정치는 출발점이며 현시점에서 정담에 가까운 추측일 뿐이다.

3. 스크럼 팀

• 스크럼 팀은 선별된 제품 백로그를 작동하는 제품으로 만들기 위해 헌신하며, 매 스프린트마다 이를 반복한다. 팀은 이를 위해 필요한 것이라면 무엇이든지 할 수 있는 권한을 갖는다. 오직 회사의 표준과 관행만이 이 권한을 제약할 수 있다.

역동적인 팀

• 팀은 목표에 헌신적이기 때문에 자신들의 헌신과 기대를 꺾는 일이 발생하면 종종 좌절하곤 한다. 그러나 스크럼은 경험주의적이므로 팀은 해당 스프린트에 개발할 기능을 줄여서 목표를 달성할 수 있고, 관리자는 해당 스프린트 끝에 인도된ㄷ 제품 증분을 바탕으로 조정할 수 있다.
• 스크럼 마스터로서 나는 가끔 팀 내부의 문제 해결에 도움을 주고 싶다는 유혹에 시달리곤 한다. 그러나 그래서는 안 된다는 것을 경험을 통해 배웠다. 팀원들은 목표를 향해 최선을 다해 주었다. 내가 팀원들 사이의 문제를 중재한다면 이는 팀원들이 할 일을 빼앗는 꼴이 될 것이다. 팀원들이 지금까지 최선을 다해왔다면 어떻게 목표를 달성할 수 있을지는 능력껏 스스로 알아낼 것이다.

팀의 크기

• 만약 8명 이상의 인력을 쓸 수 있다면 나는 그 팀을 여러 개의 작은 팀들로 쪼개기를 강력히 권한다.

팀의 구성

• 스크럼은 분석가, 설계자, 품질 관리자, 코딩 엔지니어로 구성된 수직적인 형태의 티이 되는 것을 피해야 한다.
• 팀은 제품 백로그의 분량을 결정하고, 스프린트 목표를 수립하다.
• 스크럼에서는 어떤 제 3자도 팀원이나 팀에게 이래라 저래라 할 수 없다.
• 스프린트 동안 팀은 자신이 개발한 것을 테스트해야만 한다.
• 팀의 구성과 상관없이 분석에서부터 설계, 코딩, 테스트 및 사용자 문서 작성에 이르기까지 필요한 일을 팀 스스로 해내야 한다.
• 스크럼 팀에는 직위가 없다.
• 팀의 모든 사람은 스프린트 목표 달성에 필요한 것이라면 무엇이든지 가리지 않고 하고, 어떻게 처리해야 하는지 모를 경우에는 그 방법을 배우는 데 다 함께 참여해서 최선을 다 한다.

팀의 책임과 권한

• 스크럼을 시행하는 동안에는 오직 팀만이 자신의 업무를 규정할 권한을 갖게 해야 한다.
• 어떤 팀들은 자신들의 권한을 깨닫기까지 약간의 시간이 걸린다. 그런 팀들에게는 이런 사실이 너무 충격적이고 의심스러운 나머지, 어느 누구도 자신들에게 무엇을 하라고 시키지 않는다는 사실에 당혹스러워 한다.
• 만약 팀이 목표 달성을 위해 필요한 권한을 충분히 갖고 있지 못하다고 느낀다면, 팀은 비정상적인 스프린트의 중단을 요청할 수 있다.

작업 환경

• 개방된 업무 환경을 활용하라. 개방된 환경은 사람들 간의 의사소통을 더 원활하게 만들고 쉽게 어울리도록 하며 자기 조직화를 촉진한다.
• 침묵은 불길한 징조다.
• 칸막이가 쳐진 사무실에 들어가면 종종 너무나도 조용한데, 이것은 상호작용의 부재를 가리킨다.
• 나는 회의실이 충분하지 않은 회사의 경우에는 여러 개의 사무실을 하나의 팀룸으로 둔갑시켰다. 팀이 이 새로운 방으로 이사하자마자 생산성이 극적으로 증가하였다.
• 약간의 제약이 필요하긴 하지만 스크럼 팀은 업무 시간을 스스로 규정할 수 있다. (...) 물론 팀원들은 다른 팀원들이 함께 있는 시간에 일을 해야 한다.

4. 일일 스크럼 회의

• 15분짜리 현황 파악 회의
• 지난 회의 이후로 무엇이 달성되었고, 다음 회의까지는 무엇을 할 예정이며, 무엇이 진행을 방해하고 있는지 서로 알게 한다.
• 내가 계속해서 듣는 장애 요소는 팀원들이 다른 현황 회의에도 참석해야 한다는 것이다. 나는 팀에게 다른 현황 회의에 참석하지 말라고 한다. 프로젝트가 어떻게 진행되고 있는지 알고 싶은 사람은 일일 스크럼 회의에 참석해서 들을 수 있기 때문이다.
• 스크럼 마스터는 일일 스크럼 회의를 성공적으로 주관할 책임이 있다.

회의실 만들기

• 스크럼 마스터는 일일 스크럼의 시간과 장소를 마련해야 한다.
• 이 방에는 (회의 중에 닫아 놓을) 문, (원격으로 참석할 팀원들을 위한) 스피커폰, 탁자와 팀원들이 둘러앉을 만큼 충분한 의자 및 (이슈들과 장애 요소들을 기록하고, 일일 스크럼 후의 일반적인 브레인스토밍을 위한) 화이트보드가 갖추어져 있어야 한다.

닭과 돼지

닭과 돼지가 함께 모여 있을 때, 닭이 "식당을 시작하자!"고 제안했다. 돼지가 잠깐 생각을 하더니 물었다. "그러면 식당 이름은 뭐로 하지?" 이에 닭이 대답하길, "햄과 달걀은 어때?" 그러자 돼지가 말했다. "그건 안 되겠는데. 너는 그저 (달걀이나 제공하는 것으로) 참여할 뿐이지만, 나는 (내 살을 베어내는) 희생을 해야 한단 말이지!"

• 팀원 = 돼지, 그외나머지사람들 = 닭
• 닭들은 일일 스크럼에 참석할 수 있지만 주변에 머물러 있어야만 한다. 어떤 식으로도 회의를 방해해서는 안 된다. 여기에는 어떤 말을 하거나 어떤 몸짓을 하거나 어떤 소음을 내는 것도 모두 포함된다. 닭들은 손님으로 온 것이기 때문에 스크럼의 규칙을 따라야 한다.
• 일일 스크럼 회의 참관자들은 최소로 유지하라.

회의 시작하기

• 스크럼 마스터는 회의 중간에 주의가 산만해지는 것을 최소화해서 사람들이 회의에 집중하고 회의가 늘어지지 않도록 한다.
• 회의를 서서 하면 회의가 좀더 빨리 끝난다는 것을 아는 팀은 서서 하기도 한다.
• 희의는 누가 있든지 없든지 간에 예정된 시간에 시작한다.

일일 스크럼의 형식

• 한 번에 한 사람씩 돌아가면서 발표한다. 한 사람이 자신의 현황을 보고하는 동안 나머지 사람은 그의 이야기에 귀 기울여야 한다.
• 잡담은 허용되지 않는다.
• 팀원들은 이 세가지 질문에 요점만을 간추려서 간결하게 말해야 한다.
  • "지난 일일 스크럼 이후로 무엇을 했는가?"
    • 팀원들은 오직 자신의 팀과 이번 스프린트에 관련하여 자신이 한 것들에 대해서만 언급한다.
    • 만약 팀원이 이번 스프린트에서 자신들이 하기로 계획한 일이 아닌 다른 일을 하고 있다면, 그 다른 일을 장애 요소로 취급해야 한다. 팀의 업무와 관련이 없는 것은 무엇이나 장애 요소가 된다.
  • "지금부터 다음 일일 스크럼까지 무엇으 하려고 하는가?"
    • 팀원이 하려고 하는 일은 반드시 팀이 하기로 계획한 것에 부합해야 한다. 만약 팀원이 다른 일을 하려고 한다면 반드시 그 이유를 확인해야 한다.
    • 이 질문에 대한 대답을 보면서 팀과 관리자는 일이 계획에 맞게 제대로 진행되고 있는지 아니면 변경이 필요한지를 판단할 수 있다.
  • "업무를 하는데 무엇이 방해되는가?"
    • 개별 팀원들의 발목을 붙잡아서 팀 전체의 속도를 저하시키는 것은 무엇인가?
• 도움이 필요하다는 것을 강조하려는 경우를 제외하고 해당 업무가 어떻게 완료되었거나 될 것인지에 대해서 미사여구를 동원하거나 장황하게 설명해서는 안 된다.
• 일일 스크럼 회의는 설계 회의가 아니며 작업 회의처럼 돌변해서도 안 된다. 설계에 대해서 논하거나 그 자리에서 문제를 해결하려 들지 말라.

장애 요소 식별하기

• 스크럼 마스터는 그 장애 요소들을 기록하고 제거할 책임이 있다.
• 만약 스크럼 마스터가 그 장애요소를 제대로 이해하지 못했다면, 스크럼 회의가 끝난 후에 해당 장애 요소를 보고한 사람을 만나서 좀더 자세히 듣도록 한다.
• 만약 팀원이 스크럼 마스터에게 이것만 해결되면 자신의 생산성이 올라갈 것 같다고 말한다면, 스크럼 마스터는 그것을 해야만 한다.
• 장애 요소가 제거되지 않았는데도 팀원들이 장애 요소에 대해서 보고하지 않는 것은 좋지 않은 조짐이다.
• 어떠한 이유로든 장애 요소를 제거하지 못했다면 스크럼 마스터는 다음 일일 스크럼에서 이 사실을 보고 해야만 한다.
• 만약 화이트 보드에 적힌 미해결 장애 요소가 계속 늘어나기만 한다면 회사에서 팀을 충분히 지원하지 않고 있다는 것을 의미한다. 이 경우, 스크럼 마스터는 스프린트를 취소할 수도 있다.
  • (회사의 상태가 중요한 것이 아니라) 스크럼 마스터는 많은 장애 요소들을 목격했고, 관계자가 그 장애 요소들을 제거하길 원치 않거나 제거할 능력이 없다는 사실이 중요하다.

의사결정

• 팀은 최선의 결정을 내리고 최선의 결과를 내기 위해 필요한 것이라면 예산이 허락하는 한도 내에서 무엇이든지 할 수 있다.
• 어떤 팀원은 미결정사항을 장애물로 여길 수 있다. (예를 들면 "저는 이걸 할지, 저걸 할지 모르겠어요.") 그럴 경우, 스크럼 마스터는 (가능하다면 즉시 그 자리에서) 결정을 내릴 책임이 있다.
• 스크럼을 처음 시행하는 팀의 경우 스크럼 마스터가 팀을 위해서 너무 많은 결정을 내리지 않도록 조심해야 한다. 대부분의 조직에서는 의사결정을 위임하는 것이 낯설기 때문에 스크럼 마스터는 팀이 목표를 완수하기 위해 스스로 결정을 내릴 수 있도록 도와야 한다.
• 팀이 외부인에 의존해서 결정하면 할수록 자신들의 목표에 대한 통제권이 약해질 것이다.
• 대부분의 경우, 재빠른 결정이 다른 누군가가 결정해주기를 기다리면서 일을 뭉개고 있는 것보다 낫다. (결정으로 인해 나온 결과가) 최악의 경우라도 아무 것도 하지 않는 것보다는 낫다.
• 때때로 잘못한 의사결정에 따라서 엉뚱한 기능이 만들어지거나, 기술을 부적절하게 적용하는 경우도 발생한다. (...) 만약, 검토회의에서 잘못된 의사결정 사항이 보이지 않는다면 그건 중요하지 않은 것일 것이다.
• 만약 일일 스크럼 회의에서 결정을 내릴 수 없다면, 스크럼 마스터는 일일 스크럼이 끝나고 한 시간 이내에 결정을 내려서 팀에게 전파해야 한다.

후속 회의 개최하기

• 작업에 관련된 회의는 (...) 모두 가치 있을 뿐만 아니라 꼭 필요하다. 단지 일일 스크럼이 끝난 다음에 벌어져야 할 뿐이다. 일일 스크럼과 실제 작업에 관련된 모든 회의는 명확히 구분하도록 해야 한다.

5. 스프린트 계획 회의

스프린트 계획 회의의 개요

• 스프린트 계획 회의는 사실상 두 개의 연속된 회의로 구성된다.
• 첫 번째 회의에서 팀은 제품 책임자, 관리자 그리고 사용자를 만나 어떤 기능을 개발할 것인가를 결정한다.
• 두 번째 회의에서는 다음 스프린트 동안 그 기능을 어떻게 제품 증분으로 만들 것인가를 팀 스스로 결정한다.

다음 스프린트 목표 선정과 제품 백로그 확정

• 제품 책임자가 최우선 제품 백로그를 발표하는 것으로 회의를 시작한다.
• 팀은 제품 책임자, 관리자, 고객과 함께 제품 백로그 중 다음 스프린트 동안 개발 가능하다고 믿는 것들을 선별한다.
• 스프린트 목표란, 선정된 제품 백로그의 구현을 통해 달성되는 어떤 목표로서 선정된 제품 백로그를 바탕으로 결정된다.

스프린트 목표(예): 선별된 고객 서비스 트렌젝션들이 뒷단의 데이터베이스에 접속할 수 있도록 표준화된 미들웨어 메커니즘을 제공한다.

• 스프린트 목표를 설정하는 이유는 해당 스프린트 동안 개발할 기능에 관해서 팀에게 융통성을 발휘할 여유를 주기 위해서다.
• 작업이 팀이 예상한 것보다 어렵다고 판명나면, 팀은 그 기능의 일부만을 구현할 수도 있다.
• 스프린트 동안에 스프린트 목표를 어떻게 달성할 것인가는 어디까지나 팀이 스스로 결정한다.

스프린트 목표에 맞게 스프린트 백로그 정의하기

• 스프린트 목표를 설정하고 나면 목표 달성을 위해서 어떤 작업들을 완수할 것인가를 결정한다. 이 사항을 결정할 때에는 모든 팀원이 참석해야 한다. (...) 이 회의에서 경영진이나 사용자는 팀의 결정을 방해할 어떤 행동이나 말을 해서는 안 된다.
• 팀은 스프린트 목표 달성을 위해 필요한 태스크들의 목록을 작성한다. (...) 각 태스크는 대략 4시간에서 16시간 안에 완료할 수 있을 만큼 충분히 자세하게 명시되어 있어야 한다.
• 때로는 스프린트 백로그의 일부밖에 작성할 수 없을 때가 있다. (...) 이와 같은 경우 팀은 사전 조사, 설계 및 아키텍처 작업을 가능한 자세히 정의하고, 그 작업들이 완료되었을 때 뒤이어 수행해야 할 업무들을 남겨두어야 한다. 그때가 되면 해당 업무들에 대한 이해가 깊어지면서 업무를 보다 상세화하기 위한 또다른 회의를 소집할 수도 있다.
• 팀은 스프린트 기간 내내 스프린트 백로그를 수정한다. (...) 새로운 업무가 필요해지면 스프린트 백로그에 추가한다. 태스크를 착수하거나 완료할 때마다 각 태스크 완료까지 남은 시간의 추정치를 계속 갱신한다. 만약 어떤 태그크들이 불필요하다고 판단되면 그것들을 제거할 수도 있다.
• 스프린트 동안에는 오직 팀만이 스프린트 백로그를 변경할 수 있다.
• 때로는 스크럼 팀은 자신들이 너무 많은 제품 백로그를 선택했다는 사실을 깨닫기도 한다. 이런 일이 벌어질 경우 스크럼 마스터는 즉시 제품 책임자와 스크럼 팀을 한 자리에 모은 다음 제거하더라도 스프린트 목표 달성에 지장이 없는 제품 백로그를 모두 함께 선정해야 한다. 제거가 어렵다면 개발 범위를 줄일 수 있는 기능은 어떤 것이 있는지 알아본다.

6. 스프린트

• "시행착오는 귀중한 학습 경험으로서 언제나 긍정적으로 받아들여지게 될 것이다."

제품 증분은 혼돈의 산물이다.

• 팀은 복잡한 요구사항과 예측 불가능한 기술을 제품 증분으로 만들기 위해 최선을 다 해야 한다. 또한 혼돈을 길들이고 보잡성을 예측 가능한 제품으로 바꾸어 놓아야 한다.

방해 금지, 난입 금지, 잡상인 금지

• 팀 외부의 어느 누구도 팀이 스프린트 동안 하고 있는 업무의 범위나 성격을 바꿀 수 없으며 새로운 기능이나 기술을 추가해서도 안 된다. 팀의 업무 방식에 대한 간섭도 금지된다.

스프린트의 동작 메커니즘

• 스프린트 기간 동안 팀은 전권을 행사한다. (업무 시간이나 회의 모두 팀 마음대로)
• 스프린트동안 팀이 반드시 지켜야 할 사항이 두 가지 있다. 일일 스크럼 회의와 스프린트 백로그다.
  • 일일 스크럼 회의에는 모든 팀원이 직접 참석하든 전화를 이용하든 반드시 참석하도록 유도해야 한다. 이메일이나 팩스와 같은 간접적인 현황 보고는 금지된다.
  • 스프린트 백로그는 반드시 최신 상태로 유지해야 하고 팀의 활동을 정확하게 반영해야 하며, 이를 통해서 진화하는 팀과 팀의 업무를 정확하게 그려내야 한다.
• 일일 빌드는 팀의 진척도를 측정하는 훌륭한 수단이다.

비정상적인 스프린트 중단

• 기존의 스프린트 목표가 쓸모없게 되면 경영진이 스프린트를 취소할 수 있다.
  • 스프린트의 길이가 (30일로) 매우 짧기 때문에 경영진이 스프린트를 취소하는 게 좋다고 생각하는 경우는 거의 없다.
• 스프린트 도중에 자신들이 이번 스프린트 목표를 달성할 수 없다는 사실을 깨닫게 될 수도 있다. 업무에 대한 팀의 생각이 바뀌지 않았다 하더라도 팀이 심각한 난관에 직면했다면 스프린트를 취소할 수 있다.
• 팀이 스프린트를 취소할 수 있는 권한을 갖는 것은 매우 중요하다. 누군가가 업무의 성격이나 범위를 변경하려고 하면 팀이 스프린트를 중단할 수 있기 때문에 업무에 집중하는 것이 가능하다.
• 스프린트 중단을 자원을 낭비하는 행위다.

7. 스프린트 검토

• 팀은 스프린트가 끝날 무렵에 팀이 어느 위치에 있게 될 것인지를 추정하고, 그에 따라 항로를 설정한다.
• 팀은 자신들이 개발한 제품 증분을 선보인다. 경영진, 고객들, 사용자들과 함께 제품 책임자는 제품 증분을 평가하고 이번 스프린트 동안 팀이 겪은 이야기에 귀를 귀울인다.
• 스크럼 마스터는 스프린트 검토 회의의 진행과 조율을 책임진다.
• 회의를 준비하면서 팀은 이번 스프린트 동안 자신들이 개발한 것을 이해시키기 위해 참석자들에게 무엇을 보여줄 것인가를 고려한다. 팀은 모든 사람이 가능한 제품 증분의 다양한 측면을 이해하길 원한다.
• 스프린트 목표와 제품 백로그를 해당 스프린트의 실제 결과와 비교해서 그 차이점을 토론한다.
• 제품 아키텍처를 간략한 다이어그램으로 보여주고 설명할 수도 있다. 가장 효과적인 아키택처 다이어그램은 기술적인 아키텍쳐와 기능적인 아키텍처 두 개를 동시에 보여주는 것이다.
• 시연을 통해서, 팀은 참석자들이 해당 제품 증분의 강점과 약점 그리고 팀이 겪었던 난관들과 성공들을 이해할 수 있도록 힘써야 한다.
• 어느 누구도 스프린트 검토 회의 준비에 많은 시간을 투자하지 않도록 해야 한다. 이를 우해 파워포인트 프레젠테이션 혹은 그 유사한 것들은 모두 금지시킨다.
• 이 회의는 비평을 하거나 어떤 행동을 취하기 위한 것이 아니라 정보 교환을 위한 것이라는 점을 명심해야 한다.