번역_스크럼, 머리 다섯 달린 회의 괴물인가?

이 글은 scrum.org|blog 블로그에 게재된 Scrum: A Five-Headed Meeting Monster를 번역한 것입니다. 저의 의견과 100% 일치하지 않을 수 있으며, 저작권에 문제가 될 경우 언제든지 삭제될 수 있습니다(저작권 문의 중).

(옮긴이의 말) 최근 스크럼 마스터와 비슷한 업무를 하고 있습니다. 개발팀의 업무 형태는 스크럼에 준하여 진행하고 있지만, 개발팀을 제외한 전사 조직의 업무 형태는 그렇지 않아 미팅에 대한 많은 고민을 하고 있는 중에 좋은 아티클을 발견하여 번역해서 올려봅니다.

스크럼이 기업에 도임되는 경우 대부분 개발팀들은 의욕적으로 스크럼을 수용합니다. 스크럼은 자기 조직적이고, 자율적이며, 다양한 원칙을 가진 팀들을 준중하며 이 팀들은 개별적인 품질을 지향하고 팀 전체고서의 강점을 중요하게 행각한다. 누가 스크럼 팀의 일부가 되지 않으리라고 생각할까요? 하지만 많은 경우 스크럼 허니문이 끝나고 나면 다음과 같은 말들을 심심찮게 들어볼 수 있습니다:

• “스크럼이 도입된 이후로 제가 한 것이라곤 회의뿐이예요. 저는 하루 종일 회의나 하려고 개발자가 된게 아니었어요.”
• “저는 스크럼을 도입하면 더 좋은 팀 문화를 만들 수 있을 거라고 생각했습니다. 하지만 실제로 느껴지는 건 팀 문화라기 보다는 회의 문화에 가까운 것 같아요.”
• “저는 스크럼 미팅은 시간이 정해져 있다고 생각했어요. 하지만 우리 팀의 일일 스크럼 미팅은 매번 30분 이상 소요되고 그 이후에도 팀으로서 뚜렷한 계획이 세워지지 않는 경우가 많습니다.”

스크럼 가이드는 이미 규정된 스크럼 이벤트(명시적으로 이 이벤트들은 회의라는 명칭으로 불리지 않는다)들이 정규적인 업무를 만들고, 스크럼에 정의되어 있지 않은 회의를 줄이기 위해 사용한다고 명시하고 있습니다. 모든 스크럼 이벤트는 최대 수행 제한 시간이 정해져 있습니다. 1개월짜리 스프린트를 기준으로, 제한 시간을 가진 규정된 스크럼 이벤트는 다음과 같습니다:

• 데일리 스크럼: 15분
• 스프린트 플래닝: 최대 8시간
• 스프린트 리뷰: 최대 4시간
• 스프린트 회고: 최대 3시간
• 프로덕트 백로그 정제: 개발팀 전체 공수의 10% 가량

제한 시간을 가지고 있는 이 이벤트들을 생각해보면 스크럼이 회의 문화를 야기할 수 밖에 없는 프레임워크로 보이지는 않습니다. 그런데 왜 이런 생각들을 자주하는 상황이 일어날까요?

개인적으로 생각해 본 이유들입니다:

• 규정되어 있는 시간 제한을 지키지 않고 스크럼 이벤트를 수행하고 있습니다. 스크럼 가이드에 규정된 제한 시간 이상을 이벤트에 사용할 필요는 없습니다. 하지만 저는 데일리 스크럼이 45분이나 지속되는 현상을 종종 보아왔습니다…
• 명확한 구조를 갖추지 못한 스크럼 이벤트들을 수행하고 있습니다. 명확한 구조와 논의 주제가 결여되어 있다면, 주어진 규정된 제한 시간을 준수하는 것 뿐만 아니라 올바른 결과를 달성하기도 어렵습니다.
• 팀이 올바르게 준비되지 못한 상태입니다. 모든 스크럼 이벤트는 팀이 충분히 준비된 상태에서 진행되어야 합니다. 제가 보기에 준비는 단지 한 전문가–스크럼 마스터 등–에게 뿐만 아니라, 각 팀 멤버들에게도 필요합니다.
• 스크럼에 규정되지 않은 다른 회의들을 여전히 수행하고 있습니다. 아마도, 개발팀은 정기적인 스크럼 이벤트 이외에도 다른 회의에 참석하지 않으면 안되는 상황일 것입니다. 예를 들면, 전사 프레젠테이션, 지식 공유 세션, 고객 미팅등이 포함될 수 있습니다. 이러한 미팅들은 때로는 반드시 해야 하는 것들이지만, 가능한 줄여 나가야만 합니다.
• 미팅이 개발자의 스케줄에 맞춰져 있지 않습니다. 대부분의 매니저들에게는 하루 종일 진행되는 회의에 참석하는 것이 본연의 일일 수 있습니다. 하나의 미팅이 끝나고 나면 바로 다음 미팅으로 이동하는 것은 자연스럽지요. 하지만 개발자는 다릅니다. 프로그래밍은 고도의 집중력을 요구합니다. 일과 중 많은 미팅에 참여해야하는 것은–그 미팅의 길고 짧음은 중요하지 않습니다–프로그래머의 생산성을 정말로 저하시킵니다. 태스크의 전환은 생산성 저하의 가장 큰 원인입니다.

스크럼이 단지 회의 문화를 양성하는 것으로 단정지어지지 않기 위해서는 어떻게 해야할까요?

가능한 해결책들은 다음과 같습니다:

1. 스크럼 이벤트는 회의가 아니라 대화를 하기 위한 기회입니다. 토비아스 메이어_{Tobias Mayer}는 “The Peoples Scrum”이라는 그의 저서에서 분명하게 이렇게 밝히고 있습니다.¹ “스크럼은 사람에 집중합니다. 그리고 사람들은 대화를 합니다. 대화를 통해 계획하고 정렬하고 반영합니다. 우리는 이러한 대화를 적절한 시기에, 서로의 업무를 공유하기 위해 적절한 시간 동안 수행합니다. 이러한 대화가 없다면 우리가 하고 있는 것(계획), 우리의 현지 위치(정렬)에 대해 서로 알지 못하게 될 것이며, 동일한 실수(반영)을 계속하고 말 것입니다.”

2. 규정된 시간 제한을 엄격하게 준수하십시오. 데일리 스크럼을 예로 들어보겠습니다; 개인적으로 데일리 스크럼이 규정된 시간 제한을 가장 빈번하게 어기는 이벤트라고 생각합니다. 특히 데일리 스크런이 여러분이 현재 일을 잘 해나가고 있는지에 대해 유일하게 배울 수 있는 이벤트이기히는 하지만, 팀으로서 업무 내용을 동기화하고 그날 해야할 일에 대한 계획을 세우기 위해 15분 이상의 시간을 사용할 필요는 없습니다. 규정된 시간 제한을 준수함으로 인해 회의의 목적이 달성되지 않게 된다면, 다음 미팅을 위해 적절한 해결책을 찾아야 합니다. 시간 제한을 준수하지 않게 되면 그러한 개선의 필요성 역시 느끼지 못하게 됩니다.

3. 이후 진행될 스크럼 이벤트 스케줄을 준비하고, 이벤트의 목적을 명확하게 하십시오. 이벤트에서의 agenda를 미리 공유합니다; 모든 팀 구성원들은 해당 agenda에 대해 스스로 준비할 수 있는 기회를 갖게 됩니다. 또한 이벤트를 진행함에 있어서 팀이 어떤 것들을 준비해야하는 지 명확하게–세션의 골을 공유–하십시오. 누군가가 스프린트 리뷰 동안 새롭게 개발한 기능의 데모를 해야만 한다면, 그 사람과 최대한 일찍 대화하고 스프린트 중 필요한 시간을 미리 확보하십시오. 스크럼 이벤트의 목적과 예상되는 결과물에 대한 팀의 이해를 돕기 위해 Agile Meeting Cube와 같은 멋진 도구를 사용할 수도 있습니다.

4. 백로그 정제 이벤트는 회의가 아닙니다. 스크럼 가이드는 백로그 정제를 프로덕트 백로그 아이템을 구체화하고 추정하며 순서를 정하는 과정으로 기술하고 있습니다. 백로그 정제는 스크럼 프레임워크의 공식적인 요소는 아니지만, 프로덕트 백로그를 개선하기 위한 지속적인 프로세스입니다. 백로그 정제는 미팅이 아니라, 오히려 팀으로서 프로덕트 백로그를 리뷰하고 개선하기 위한 협업 활동의 하나로 간주되어야 합니다. 개발팀의 공수를 기준으로 10% 가량의 공수를 백로그 정제에 투입할 것을 권고하고 있지만, 백로그 정제 활동의 완료에 대한 명확한 기준은 팀에 따라 다릅니다.

5. “방해하지 마!” 집중 시간을 활용하십시오. 집중 시간동안에는 개발팀은 어떤 미팅에도 참석하지 않으며, 정말 중요한 일이 아닌 경우(예를 들어 개발팀 외부의 누군가의 중요한 요구 등)에는 방해를 받지 않아야 합니다. 물론 집중 시간은 협업의 의도와 팀이 달성하고자 하는 투명한 커뮤니케이션을 방해해서는 안됩니다. 하지만 팀의 협업과 개인이 필요한 정도의 집중시간을 확보할 수 있는 균형점을 이루는 것 역시 중요합니다.

6. 스크럼은 재미있어야 합니다. 스크럼 이벤트(물론 스크럼 미팅이 아닌 경우라도)는 지루하거나 단조롭거나 에너지를 고갈시켜서는 안됩니다. 저는 모든 세션에서 늘 재미와 에너지, 상호작용과 협업을 향상시키고자 합니다. 파워포인트 슬라이드를 가급적 많이 사용하지 않거나, 의자를 둥글게 늘어놓고 앉거나 노트북을 사용하지 않는 방법등으로 이러한 목적을 일부 달성합니다. 한번 더 당부드리지만, 모든 미팅을 온갖 맛있는 음식 냄새가 가득찬 세레모니로 생각하지 마십시오. 미팅은 협업과 학습과 재미를 얻을 수 있는 기회의 하나일 뿐입니다.

7. 스프린트 캘린터를 만드십시오. 모든 스크럼 이벤트 및 기타 회의 일정을 포함한 스프린트 캘린더를 만들어서 팀에게 모든 정보를 분명하게 공유하는 것은 매우 효과적일 수 있습니다. 팀은 그들이 스프린트 동안 무엇을 하고, 스프린트 데일리 스크럼을 어떻게 진행해야 할지에 대한 인사이트를 얻을 데 도움을 얻을 것입니다. 때로 팀은 회의가 너무 많다고 생각할 수 있으며, 스프린트 캘린더를 통해 그 느낌을 사실인지 판단할 수 있을 것입니다. 이 사실에 기반해서 팀은 그 느낌이 올바른 것인지 혹은 무엇인가 개선되어야 하는지 정확하게 판단할 수 있습니다.

8. 고객과의 미팅을 수용하십시오. 애자일 마인드셋을 다시 한번 생각해 보십시오. 고객과의 협업은 성공적인 제품 개발을 위한 필수 조건입니다. 냉랭한 고객-공급의 관계를 맺지 마십시오. 오히려 고객을 스크럼 팀의 일부–정말 멋진 제품을 만들고 싶어하는 동일한 욕구를 가진–로 생각해야 합니다. 그렇게 되면 고객과의 미팅은 제품의 ‘목적why’과 ‘기능what’을 더 잘 이해하고, 올바른 제품을 만들기 위한 가능성을 높이는 기회가 될 것입니다.

저에게 있어 스크럼과 미팅 문화는 완전히 다릅니다. 물론 사람들이 이 문제에 관해 종종 논쟁을 하는 것을 이해할 수는 있지만 말입니다. 이 블로그 포스트에서 저는 미팅 문화를 방지하기 위한–달리 말하면 스크럼이 회의를 늘린다는 느낌을 방지하기 위한–몇가지 해결책을 제시했습니다.

여러분이 다른 팁이나 트릭, 경험들을 가지고 있다면 언제든지 공유해주시길 바랍니다 :)


—-