제품, 엔지니어링, 소프트웨어 개발 팀에서 일하거나 관련 팀과 협업한다면 스크럼이라는 용어를 들어본 적이 있을 것입니다. 스크럼은 빠르게 개발하고 반복하는 팀을 위해 설계된 프레임워크로, 스크럼 프로세스를 실행하면 복잡한 문제를 함께 해결하는 데 도움이 될 수 있습니다. 제품, 엔지니어링, 소프트웨어 개발 팀에 속하지 않더라도 스크럼을 유용하게 사용할 수 있습니다. 이 기사에서는 스크럼의 정의와 장점 등 스크럼에 관해 알아야 할 모든 내용을 소개합니다.
스크럼(Scrum)은 팀이 협업하고 영향력이 큰 업무를 수행하는 데 도움이 되는 애자일 프레임워크입니다. 스크럼 프레임워크는 팀이 반복과 지속적인 개선에 집중할 수 있도록 가치, 역할, 지침의 청사진을 제공합니다.
전통적으로 스크럼은 스프린트라고 하는 보통 2주간의 업무 세션으로 구성되며, 마지막에 특정 결과물이 산출됩니다. 스크럼에는 2가지 추가 이벤트가 있습니다. 일일 스탠드업 미팅은 이름에서 알 수 있듯이 하루에 한 번 수행합니다. 일일 스탠드업 미팅은 스크럼 팀이 15분 동안 논의하며 일상 활동을 조율할 기회입니다. 두 번째 이벤트인 스프린트 회고는 스프린트가 끝나면 수행합니다. 스크럼 마스터가 진행하는 스프린트 회고에서 팀은 자신의 스프린트를 되돌아보고 향후 스프린트를 위해 조정할 수 있습니다.
Asana로 애자일 팀을 관리하세요칸반이나 애자일 등의 다른 방법론에서 스크럼에 관해 들어본 적이 있을 것입니다. 이러한 각 프레임워크는 팀이 협업하고 지속적으로 개선하는 데 고유한 역할을 하지만, 린(lean) 방법론 프레임워크 내에서 밀접하게 연결되어 있습니다. 다음은 이를 비교한 것입니다.
애자일은 팀이 지속적으로 개선하는 데 도움이 되는 프로젝트 관리 철학입니다. 애자일 팀은 팀이 변화에 대응하고 불확실성을 해결하는 데 도움이 되는 반복적이고 점진적인 발전을 믿습니다. 스크럼과 칸반은 모두 애자일 방법론의 일부입니다. 애자일을 포괄적인 용어라고 생각하세요.
Asana로 애자일 팀을 관리하세요스크럼은 가장 인기 있는 애자일 방법론 중 하나입니다. 스크럼을 사용한다면 애자일 팀이라 말할 수 있습니다. 그러나 스크럼 프레임워크에는 팀이 민첩할 수 있도록 지원하는 추가적인 역할과 시스템이 있습니다. 애자일과 마찬가지로 스크럼에서도 팀은 지속적인 개선을 목표로 합니다. 하지만 철학이나 프레임워크에 가까운 애자일과 달리, 스크럼은 스프린트, 스탠드업, 회고와 같은 수단을 통해 팀이 지속적으로 개선할 수 있는 구체적인 방법을 정합니다.
칸반 프레임워크는 애자일의 하위 집합이기도 합니다. 칸반은 연속된 프로세스와 업무를 관리하는 시각적 방법입니다. 팀이 칸반 툴을 사용하면 업무가 완료될 때까지 단계를 거치는 과정을 시각화할 수 있습니다. 스크럼을 사용하는 팀이 칸반 보드에서 수행할 때가 많지만, 그렇게 하는 것이 스크럼 프레임워크의 요건은 아닙니다.
참고: 칸반과 스크럼의 차이점오늘날 존재하는 ‘스크럼’은 Hirotaka Takeuchi와 Ikujiro Nonaka가 기고한 1986년 Harvard Business 리뷰 기사 The New Product Development Game(새로운 신제품 개발 게임)에서 처음 소개되었습니다. Takeuchi와 Nonaka는 럭비에서 ‘스크럼’이라는 이름을 따왔으며, “럭비에서와같이 팀에서 공을 패스하고 이를 단위로 필드 위를 이동하는 것”이라고 설명했습니다.
스크럼은 1995년 Ken Schwaber와 Jeff Sutherland가 Agile Manifesto(애자일 선언문) 및 SCRUM Development Process(스크럼 개발 프로세스)를 출간하며 더욱 발전되고 체계적으로 정리되었습니다.
Schwaber와 Sutherland의 스크럼은 소프트웨어 개발의 워터폴 모델을 부분적으로 거부하는 것이라고도 말할 수 있습니다. 워터폴 모델에서 프로젝트는 순차적 단계로 세분화되어 각 단계의 결과물이 완성되면 그다음 단계로 진행됩니다. Schwaber와 Sutherland는 소프트웨어 개발자가 고객을 위한 최고의 제품을 구축하기 위해 환경에 지속적으로 대응하고 적응할 수 있는 더 유연하고 반복적인 접근 방식이 효과적이라고 생각했습니다.
Schwaber와 Sutherland는 최초 발간 이후, 정기적으로 업데이트되는 살아있는 문서인 Scrum Guide(스크럼 가이드)를 발행했습니다. 스크럼 가이드에 따르면, 스크럼은 “팀이 자신의 업무 스킬이 얼마나 효과적인지를 확인하고 팀이 지속적으로 발전하고 개선하도록 한다”라고 합니다.
스크럼 프로세스를 실행하려는 경우 알아야 할 가장 중요한 점은 스크럼 프레임워크가 지속적인 개선 시스템에 의존한다는 것입니다. 스크럼에서는 스프린트를 시작할 때 아무것도 알지 못할 수도 있으며, 스프린트 프로세스 중에 얻은 정보를 토대로 필요에 따라 프로세스와 요구 사항을 조정할 수 있습니다.
그렇다면 스크럼이 정확히 무엇일까요? 스크럼을 사용하면 팀이 무엇을 하게 될까요? 스크럼 프로세스는 다음과 같이 진행됩니다.
1. 백로그를 정리합니다. 스크럼 스프린트를 시작하려면 먼저 팀 리더(스크럼 마스터라고도 함)가 제품 백로그에서 가져올 업무 즉, 해야 할 일을 파악합니다. 최상의 스크럼 스프린트를 진행하려면 제품 백로그를 한 곳에 명확하게 문서화해야 합니다. 이 모든 정보를 수집하려면 프로젝트 관리 툴을 사용하는 것이 좋습니다.
2. 스프린트 플래닝 세션을 갖습니다. 스크럼 스프린트를 시작하기 전에 어디에 중점을 두어야 할지 알아야 합니다. 스프린트 플래닝 세션에서는 팀이 특정 스크럼 스프린트 동안 백로그의 어떤 업무에 주력할 것인지 평가합니다. 시작하려면 Asana의 무료 스프린트 플래닝 템플릿을 사용해 보세요.
3. 스크럼 스프린트를 시작합니다. 일반적으로 스프린트는 2주 동안 진행되지만, 팀에 맞게 더 짧거나 더 길게 할 수도 있습니다. 스프린트 기간 동안 팀은 스프린트 플래닝 세션에서 정리한 백로그의 항목을 수행합니다.
4. 일일 스크럼 스탠드업 미팅을 수행합니다. 매일 15분 동안 스크럼 팀과 논의할 계획을 세우세요. 일일 스탠드업 미팅은 현재 진행 중인 업무에 관해 보고하고, 예상치 못한 문제에 부딪히면 우선순위를 지정할 기회입니다. 일일 스탠드업 미팅을 가장 효과적으로 수행하려면 Asana의 무료 일일 스탠드업 미팅 템플릿을 사용해 보세요.
5. 스프린트 리뷰 때 업무 내용을 보고합니다. 스크럼 스프린트가 끝나면 팀이 모여 스프린트 리뷰를 진행해야 합니다. 스프린트 리뷰에서 스크럼 팀은 이해관계자의 승인이나 확인을 위해 ‘완료’된 업무를 보고합니다.
6. 스프린트 회고에서 공유하고 반영합니다. 스프린트가 끝난 후 시간을 내어 어떻게 진행되었는지와 앞으로 개선할 수 있는 점을 논의합니다. 스크럼은 지속적인 개선 프로세스에 중점을 둔다는 점을 기억하세요. 따라서 다음 스프린트를 진행할 때 새로운 프로세스를 시도하거나 덜 효과적이라고 생각되는 전략을 수정하는 것을 주저하지 마세요. 다음 미팅을 안내하는 Asana의 무료 스프린트 회고 템플릿을 사용해 보세요.
스크럼을 시작하기 전에 팀이 ‘완료’의 의미를 정확히 알고 있는지 확인하세요. 스크럼은 지속적인 개선 프로세스에 따라 실행되므로 완료가 생각만큼 명확하지 않을 수 있습니다. 스크럼에서는 팀이 유연하고 반복적으로 개선하기 때문에 완벽한 것은 없습니다. 따라서 ‘완료’는 ‘이보다 더 좋을 수 없음’을 의미하는 것이 아니라, 스크럼 팀이 당분간 해당 업무를 중단한다는 것을 의미합니다.
예를 들어, 다음은 서로 다른 스크럼 팀에 적용되는 ‘완료’의 몇 가지 정의입니다.
제품이 출시될 준비가 되었습니다.
제품이 테스트를 거친 후 베타 환경에서 출시될 준비가 되었습니다.
제품이 수락 테스트를 거친 후 모든 사용자에게 출시될 수 있습니다.
팀에서 ‘완료’를 어떻게 정의하든, 모든 구성원이 이를 동일하게 이해해야 합니다. 완료를 정의했다면, 한곳에 집중된 단일 정보 소스에 보관하고 자주 참조하는 것이 도움이 됩니다. 특히, 스프린트 리뷰 중에 유용합니다.
스크럼에서 산출물은 문제를 해결하기 위한 툴과 같이 사용자가 만드는 것입니다. 스크럼에는 세 가지 산출물인 제품 백로그, 스프린트 백로그, 제품 증가분이 있습니다.
제품 백로그는 수행해야 하는 업무의 마스터 목록입니다. 프로젝트 매니저나 제품 소유자가 이 목록에서 우선순위를 지정합니다. 제품 백로그에 무언가가 있다고 해서 팀이 수행한다는 의미는 아닙니다. 오히려 제품 백로그에 있는 항목은 스크럼 스프린트 중에 팀이 수행할 수 있는 옵션입니다. 프로젝트 소유자는 고객, 시장 또는 프로젝트 팀의 새로운 정보를 토대로 제품 백로그를 수시로 재정렬하고 업데이트해야 합니다.
스프린트 백로그는 스크럼 스프린트 중에 팀이 수행한 업무나 제품의 모음입니다. 스프린트 백로그 항목은 스프린트 플래닝 세션 때 제품 백로그에서 선택되며, 팀의 스프린트 플래닝 프로젝트가 있다면 해당 프로젝트로 이동합니다.
팀이 스프린트를 할 때마다 백로그에 있는 모든 항목을 제공할 수는 없겠지만, 스프린트 중간에 스프린트 백로그에 무언가를 추가할 가능성은 거의 없습니다. 만약 그러한 일이 자주 생긴다면 스프린트 플래닝 단계에 더 많은 시간을 할애하여 스프린트 동안 무엇을 수행할지 구체적으로 생각할 수 있습니다.
제품 증가분은 스프린트가 끝날 때 전달하는 것입니다. 제품 증가분은 신제품이나 새로운 기능, 개선 사항이나 버그 수정 등 팀에 따라 다양합니다. 스프린트 리뷰 때 증가분을 제시하세요. 이때, 스크럼 이해관계자가 증가분에 관해 어떻게 생각하는지와 ‘완료’되었는지에 따라 전달 여부가 결정됩니다.
스크럼에는 3가지 주요 역할이 있습니다.
제품 소유자: 제품 백로그를 담당하는 사람입니다. 제품 소유자는 사용자 니즈를 파악하고 팀과 기타 경영진 이해관계자에게 사용자의 경험을 전달하는 데 중점을 둡니다. 훌륭한 제품 소유자는 다음에 전달할 가장 중요한 것이 무엇인지를 명확하게 합니다. 궁극적으로 출시할 준비가 되었는지를 판단합니다(자주 출시하는 경향이 있음).
스크럼 마스터: 스크럼 마스터는 다양한 스크럼 이벤트를 실행하는 사람입니다. 스크럼 마스터를 스크럼 프로젝트 매니저 또는 진행자로 생각하세요. 스크럼 마스터는 일일 스탠드업 미팅을 주도하고 스프린트 플래닝, 리뷰, 회고 미팅를 주최합니다.
스크럼 팀: 스크럼 팀은 스프린트를 수행하는 모든 사람입니다. 팀원들은 지속적인 개선이라는 스크럼 목표를 달성하기 위해 자기 주도적이고 협력적이어야 합니다.
스크럼 프레임워크를 적용하고 스크럼을 활용하는 데 도움이 되는 스크럼 원칙 6가지는 다음과 같습니다.
경험적 프로세스 관리: 스크럼 팀은 투명성, 점검, 적응을 중시합니다.
자기 주도적: 스크럼 팀에는 역할과 규칙이 있지만, 모든 스크럼 멤버가 자신의 작업과 업무를 소유합니다. 스크럼에서는 책임을 공유하는 것이 팀을 더 창의적이고 역동적으로 만들어준다고 믿습니다.
협업: 스크럼 스프린트를 수행할 때와 그 이후에 팀이 협력하면 최상의 결과를 얻을 수 있습니다.
가치 기반 우선순위 지정: 스크럼 스프린트의 목표는 최고의 비즈니스 가치를 제공하는 것입니다. 이를 위해 스크럼 프로세스를 시작할 때부터 업무 우선순위를 지정해야 합니다.
타임박싱(Timeboxing): 스크럼 프로세스에는 스프린트 자체, 일일 스탠드업, 회고와 같은 다양한 시간 기반 활동이 있습니다. 스크럼은 지속적인 개선이라는 신념을 토대로 하므로 다음 작업으로 나아가고 향후 업무를 개선하기 위해 업무 시간을 정하는 것이 중요합니다.
반복적 개발: 스크럼에서 첫 번째 제품은 완벽하지 않습니다. 그러나 반복해서 개발함으로써 팀은 고객 니즈에 가장 부합하고, 가치 기반 우선순위에 따라 제품과 결과물을 수정할 수 있습니다.
팀이 스크럼을 성공적으로 활용하려면 스크럼 가이드에 정의된 5가지 주요 스크럼 가치를 준수해야 합니다.
약속: 스크럼 팀은 하나이며, 팀 멤버들은 서로를 신뢰해야 합니다. 스크럼 팀 멤버들은 이 기간 동안 스프린트에 전념할 것을 약속하고, 최상의 솔루션을 찾기 위해 지속적으로 개선하는 데 전념합니다.
용기: 스크럼 중에 팀은 정확한 해답이 없는 어려운 문제에 직면할 수 있습니다. 스크럼 팀은 최선의 솔루션에 도달하기 위해 열린 마음을 가지고 어려운 질문을 던지고 솔직하게 답하는 용기를 가져야 합니다.
집중: 스크럼 팀은 스크럼 스프린트를 수행할 때 제품 백로그에서 업무를 수행합니다. 스크럼 팀은 스프린트가 끝날 때까지 결과물을 완료하기 위해 백로그에서 선택한 업무에 집중합니다.
열린 마음: 스크럼 중 모든 것이 완벽하게 진행되지는 않을 것입니다. 스크럼 팀 멤버들은 개인적으로 배울 수 있고 제품이나 프로세스를 개선하는 데 도움이 되는 새로운 아이디어와 기회에 열린 마음을 가져야 합니다.
존중: 협업은 스크럼의 핵심입니다. 팀의 협업을 지원하기 위해 팀 멤버들은 다른 멤버, 스크럼 마스터, 스크럼 프로세스를 존중해야 합니다.
스크럼이 모든 팀에게 적합하지는 않지만, 제품, 소프트웨어 개발, 엔지니어링 팀에만 국한되지도 않습니다. 어떠한 팀도 스크럼 프레임워크를 도입하고 지속적인 개선을 통해 업무를 효과적으로 수행할 수 있습니다. 스크럼 사용의 장단점은 다음과 같습니다.
스크럼은 코드나 새로운 기능과 같은 전형적인 ‘제품’이든, 마케팅 캠페인이나 크리에이티브 자산과 같은 좀 더 색다른 스크럼 ‘제품’이든 상관없이 무언가를 자주 개발하고 출시해야 하는 팀에 가장 효과적입니다.
스크럼 프레임워크를 따르는 팀은 민첩성과 유연성을 갖출 수 있습니다. 스크럼 프로세스는 팀워크를 강화하고 목표를 보다 효과적으로 달성하는 데 도움이 됩니다. 또한, 스크럼 팀은 제품 백로그에서 작업을 가져오기 때문에 항상 자신이 무엇을 수행하는지 정확히 알 수 있으며, 모든 구성원이 ‘완료’의 의미를 알기 때문에 목표가 무엇인지 명확하게 파악할 수 있습니다.
스크럼 프로세스에서는 변화를 수용하고 권장하기 때문에 스크럼 프로젝트는 종종 범위 변동으로 인한 어려움을 겪을 수 있습니다. 변경 사항이 너무 많거나 제각기 다른 고객 피드백이 너무 많으면 계속 반복해도 실질적인 성과를 달성하지 못할 수 있습니다.
솔루션: 각 스프린트의 목표와 증가분을 명확하게 정의해야 합니다. 또한 스크럼 팀 전체가 ‘완료’가 의미하는 바를 명확히 이해하여 ‘완료’ 이후에 업무를 수행하지 않도록 해야 합니다. 필요에 따라 이러한 문제를 방지하기 위해 변경 관리 프로세스를 구축합니다.
스크럼 팀은 주기적으로 예정된 스프린트 플래닝과 스프린트 리뷰 외에도 많은 미팅이 있습니다. 스크럼 팀은 스탠드업 미팅을 위해 매일 만나기도 합니다.
솔루션: 일일 스크럼 미팅이 도움이 되지 않는다면 다른 방법을 찾아보세요. 프로젝트에서 스탠드업을 추적하면 가장 도움이 되는 것에만 집중할 수 있습니다.
스크럼은 제품, 엔지니어링 또는 소프트웨어 개발 팀이 아니라면 불가능하지는 않지만 도입하기 어려울 수 있습니다.
솔루션: 팀이 스크럼을 사용하기로 했다면 스크럼 프로세스를 어떻게 활용할 것인지 명확히 해야 합니다. 가능하다면 현재 문제점을 파악하고 도움이 될 수 있는 스크럼 이벤트를 찾으세요. 또한, 팀의 성공을 돕기 위해 처음 몇 번의 스크림 스프린트 중에 여러 교육 세션을 계획하세요.
최고의 스크럼 팀은 협력적이고 반복적인 그룹으로, 모든 스프린트에서 무엇을 수행하는지 명확하게 파악할 수 있습니다. 이를 수행하려면 Asana와 같이 한곳에 집중된 단일 정보 소스가 필요합니다. 애자일 팀이 Asana로 스크럼을 실행하는 방법을 알아보세요.