문서상의 프로젝트 계획은 훌륭해 보일 수 있지만, 현실에 부딪히면 모든 것은 달라질 수 있습니다. 예상치 못한 문제가 발생하고, 우선순위가 바뀌며, 고객의 요구 사항은 팀이 대응할 수 있는 속도보다 빠르게 변화합니다. 기존의 프로젝트 관리 방식은 이러한 혼란을 실패로 간주하여 팀이 시대에 뒤떨어진 오래된 계획을 고수하거나 막판에 급하게 수습하도록 강요하는 경우가 많습니다. 그 결과는 어떨까요? 마감일을 준수하지 못하고, 이해 관계자의 불만이 쌓이며, 최종 제품은 더 이상 비즈니스 목표에 부합하지 않게 됩니다. 이에 맞서기 위해 조직은 불확실성을 헤쳐나가면서도 품질이나 생산성을 저하시키지 않는 방법을 찾아야 합니다.
성공하는 팀은 단순히 변화에 대처하는 것을 넘어 변화를 유리하게 활용합니다. 경직된 워크플로우에 매달리는 대신 짧고 집중적인 주기로 운영하며, 실제 피드백에 기반해 접근 방식을 지속적으로 조정합니다. 이들은 모든 노력이 의미 있는 진전을 이끌어 낼 수 있도록 공동 작업, 투명성 및 효율성을 강조합니다. 이러한 마음가짐은 우연이 아니라 팀이 예측 불가능한 환경에서도 성장하는 데 도움이 되는 구조화된 프레임워크에 내장되어 있습니다. 이 프레임워크를 스크럼이라고 합니다.
스크럼은 1990년대 중반, 프로젝트 관리 방법론의 비효율성에 대응하여 탄생했습니다. 이 용어는 럭비에서 유래했는데, 럭비에서 '스크럼'은 선수들이 정해진 대형으로 서로 어깨를 맞대고 뭉치는 포메이션을 의미합니다. 이 비유는 팀이 프로젝트 복잡성에 직면한 상태에서도 꾸준히 개선할 수 있게 하는 협업적이고 반복적인 접근 방식인 스크럼의 본질을 담고 있습니다.
스크럼의 기본 개념은 1995년 Ken Schwaber와 Jeff Sutherland가 OOPLA(Object-Oriented Programming, Systems, Languages & Applications) 컨퍼런스에서 공식적으로 소개했습니다. 이들은 특히 제품 개발 분야에서 높은 성과를 내는 팀은 순차적인 릴레이 방식이 아니라 럭비팀처럼 하나의 유닛으로 전진하며 일한다는 점을 강조한 Harvard Business Review의 기사에서 아이디어를 얻었습니다.
기본 원칙이 없다면 스크럼은 단순한 규칙의 집합 이상이 될 수 없습니다. 이것이 바로 팀의 상호작용, 의사 결정, 업무 접근 방식을 규정하는 핵심 가치에 기반하여 스크럼이 구축된 이유입니다. 이러한 가치들은 모든 팀원이 공통된 사고 방식을 갖도록 공동 작업과 책임감의 문화를 조성합니다.
헌신
스크럼은 팀원들이 스프린트 목표를 달성하고 고품질의 결과물을 제공하는 데 전념할 것을 요구합니다. 이러한 헌신은 책임감과 주인 의식을 촉진합니다.
용기
팀원들은 기존의 가정에 의문을 제기하고 변화를 수용하며 장애물에 정면으로 맞설 용기를 가져야 합니다. 또한 우려 사항을 제기하고 개선사항을 제안해도 안전하게 느낄 수 있어야 합니다.
- 집중
스크럼은 효율성을 극대화하고 스프린트마다 프로젝트를 진전시킬 수 있도록 우선순위가 높은 소수의 작업에 집중할 것을 강조합니다.
- 개방성
스크럼에서는 투명성이 매우 중요합니다. 팀원들은 지속적인 개선을 위해 진행 상황, 도전 과제, 인사이트를 공개적으로 공유해야 합니다.
- 존중
공동 작업은 상호 존중이 있어야 성공을 거둡니다. 스크럼 팀은 각 구성원의 전문 지식과 기여도를 인정하여 협력적인 업무 환경을 조성합니다.
경직된 계획과 예측 제어에 의존하는 기존의 프로젝트 관리 방법론과는 달리, 스크럼은 팀에서 실시간 인사이트를 활용해 정보에 근거한 의사 결정을 내릴 수 있도록 동적인 환경을 조성하기 위한 3가지 핵심 원칙에 기반해 구축된 애자일 프로젝트 관리 접근 방식입니다. 원칙은 다음과 같습니다.
투명성은 모든 관계자가 진행 중인 작업을 명확하게 이해할 수 있게 합니다. 투명성의 핵심 요소는 다음과 같습니다.
우선 순위를 대략적으로 설명하는 잘 관리된 제품 백로그.
데일리 스크럼('일일 스탠드업'이라고도 함)과 스프린트 검토 회의에서 이루어지는 개방적이고 솔직한 커뮤니케이션.
완료된 작업이 요구되는 기준을 충족하도록 보장하는 'DoD(완료 조건)'
검사가 빈번하게 이루어지면 팀에서는 진행 상황을 평가하고 잠재적인 장애물을 식별할 수 있습니다. 스크럼에서는 다음을 통해 정기적인 점검이 이루어집니다.
스프린트 리뷰: 팀에서 완료된 작업을 살펴보며 피드백을 주고받습니다.
스프린트 후속 미팅: 팀에서 잘된 부분과 개선할 수 있는 부분을 분석하고 되짚어봅니다.
데일리 스크럼 미팅: 진행 상황을 추적하고 계획을 조정할 수 있는 기회가 제공됩니다.
스크럼은 팀에서 피드백과 새로운 인사이트를 기반으로 접근 방식을 조정할 것을 권장합니다. 적응은 다음 경우에 발생합니다.
비즈니스 요구 또는 고객 피드백 변경으로 인해 우선 순위가 바뀝니다.
팀에서 향후 성과를 개선하기 위해 회고를 통해 프로세스를 다듬습니다.
비즈니스 목표에 부합하도록 스프린트 진행 중에 조정 사항을 적용합니다.
기존의 계층적 구조와 달리, 스크럼은 자체 조직과 집단적 책임을 강조합니다. 따라서, 스크럼 방법론 내에서는 역할마다 이해 관계자에게 가치를 제공하는 과정의 역할을 담당합니다. 다음은 스크럼 내의 주요 기능 및 각 기능과 관련된 책임입니다.
제품 소유자는 비즈니스 이익을 대변하고 가장 가치 있는 작업에 우선순위를 부여합니다. 이들은 다음과 같은 책임을 맡습니다.
제품 백로그 관리및 우선 순위 지정.
이해 관계자와 의사소통하여 비즈니스 목표에 맞춰 업무 조율.
스프린트마다 사용자에게 최대의 가치를 제공할 수 있도록 보장.
스크럼 마스터는 스크럼 프로세스를 촉진하고 장애물을 제거하는 역할을 담당하는 하급 리더입니다. 이들은 다음과 같은 책임을 맡습니다.
팀원들을 대상으로 스크럼 원칙과 베스트 프랙티스에 대해 코칭.
진행을 방해하는 장애물 제거.
스크럼 이벤트와 생산적인 토론 진행.
개발 팀은 작업물의 쓸 만한 증분을 제공할 책임이 있는 전문가(개발자, 테스터, 디자이너 등)로 구성됩니다. 이들은 주로 다음을 담당합니다.
스프린트 작업의 수행 방식을 자체적으로 정리하고 결정.
제품 소유자 및 이해 관계자와 긴밀하게 협업.
애자일 워크플로우의 지속적인 개선 및 발전
제품 소유자는 제품 백로그에 작업 및 기능 목록을 유지관리하고 우선 순위를 지정합니다. 제품 백로그는 팀이 집중할 작업에 관한 포괄적이고 체계적인 목록을 확보할 수 있도록 수행해야 하는 모든 작업을 저장해 두는 중앙 저장소 역할을 합니다. 프로젝트가 진행되면 백로그도 발전하며, 변화하는 우선 순위에 따라 새로운 항목이 추가되거나 개선되거나 제거됩니다. 백로그가 적절하게 관리되지 않으면 팀은 다음에 무엇을 해야 할지 명확한 방향을 가질 수 없습니다.
스프린트 계획 수립은 각 스프린트의 시작을 알리고 해당 스프린트 기간 동안 팀의 작업 방향을 설정합니다. 팀은 다음 스프린트에서 완료할 백로그 항목을 선택하고 해당 스프린트의 목표를 정의합니다. 스프린트 계획 수립에는 스크럼 팀 전체가 참여하여 지정된 시간 내에 달성 가능하고, 달성해야 할 사항을 공동으로 결정합니다.
스프린트
스프린트는 팀이 선택한 작업을 수행하는 기간(일반적으로 2~4주)입니다. 스프린트는 스크럼의 핵심 작업 단위로, 점진적인 가치 제공에 집중할 수 있는 체계적인 기간을 제공합니다. 각 스프린트는 예측 가능한 주기를 따르므로 팀에서는 효과적으로 계획을 수립하는 동시에 필요에 따라 유연하게 조정할 수 있습니다. 잘 실행된 스프린트의 결과는 출시 가능한 제품 증분입니다.
데일리 스크럼은 매일 짧게 진행하는 회의로, 이 자리에서는 팀원들이 당일의 진행 상황, 문제점, 계획을 논의합니다. 이 회의에는 15분의 시간 제한이 있으며, 일반적으로 팀원들이 세 가지 핵심 질문에 답하는 구조화된 형식을 따릅니다.
- 어제는 무엇을 했는가?
- 오늘 할 일은 무엇인가?
- 진행 중에 장애물이 있는가?
정기적인 스탠드업 미팅은 매일 진행하는 점검 회의로, 팀이 문제를 파악하고 사소한 문제가 큰 장애물로 확대되는 것을 방지하기 위해 협력할 수 있는 자리입니다.
스프린트 리뷰는 완료된 작업에 대한 프레젠테이션으로, 건설적인 피드백을 생성하는 데 목적이 있습니다. 이 이벤트는 스크럼 팀이 제품을 선보이고 다양한 이해 관계자로부터 소중한 의견을 수집할 수 있는 기회를 마련해 줍니다. 스프린트 리뷰를 진행하는 동안 팀에서는 주요 기능, 변경 사항 또는 개선 사항에 초점을 맞춰 완료된 작업을 살펴봅니다. 고객과 비즈니스 리더를 포함한 이해 관계자들은 질문을 던지고, 인사이트를 제공하며, 요구 사항에 따라 개선점을 제안할 수 있습니다. 이 이벤트 중에 수집된 피드백은 다음 반복 작업을 형성하는 데 사용됩니다.
스프린트 후속 미팅
제품에 초점을 맞추는 스프린트 리뷰와 달리, 스프린트 후속 미팅은 팀의 프로세스, 공동 작업 및 전반적인 효율성을 평가하는 데 중점을 둡니다. 목표는 무엇이 잘 되었는지, 개선할 점은 무엇인지, 그리고 향후 스프린트를 개선하기 위해 구체적으로 어떤 조치를 취할 수 있는지를 확인하는 것입니다.
백로그는 제품 소유자가 유지관리하는 기능, 작업 및 요구 사항에 우선 순위를 지정한 동적인 목록입니다. 이 백로그는 모든 스크럼 작업의 기반이 되며, 팀의 우선 순위에 대한 단일 데이터 소스 역할을 합니다. 백로그의 항목은 PBI(제품 백로그 항목)이라고도 하며, 새로운 기능부터 버그 수정, 기술 개선, 연구 작업에 이르기까지 다양한 내용을 포함할 수 있습니다. 제품 소유자는 항목이 명확하게 정의되고 가치에 따라 정렬되도록 하여 백로그를 지속적으로 개선하는 일을 담당합니다.
스프린트 백로그는 스프린트 내에서 완료하도록 선택된 제품 백로그의 하위 집합으로, 팀이 제공하기로 약속한 작업을 나타냅니다. 여기에는 스프린트 목표를 달성하는 데 필요한 구체적인 작업이 포함됩니다. 장기적인 항목이 포함될 수 있는 광범위한 제품 백로그와 달리, 스프린트 백로그는 매우 집중적이며 시간 제약이 있습니다. 스프린트 기간 동안 새로운 정보가 나타나면 백로그는 진화할 수 있지만, 궁극적인 목표는 변경되지 않습니다.
마지막으로, 증분은 스프린트에서 산출된 사용 가능한 제품 결과물입니다. 증분은 완료된 작업들의 모음이지만, DoD를 충족하는 실행 가능하고 잠재적으로 출시 가능한 제품 상태를 의미하기도 합니다. 각 증분은 이전 반복을 기반으로 구축되어 제품을 점진적으로 향상시키고 작업을 계속 진전시킵니다.
이러한 방법론은 저마다 고유한 필요와 산업에 의해 형성된 독특한 역사와 발전 과정을 가지고 있습니다.
스크럼은 1990년대 럭비의 팀워크에서 영감을 받아 탄생했으며, Ken Schwaber와 Jeff Sutherland가 소개했습니다.
애자일은 2001년, Agile Manifesto를 통해 소개되었으며, 프레임워크가 아니라 일종의 철학입니다. 스크럼, 칸반, Extreme Programming(XP) 등 다양한 방법론을 포괄합니다.
칸반은 1940년대Toyota Production System에서 개발되었으며, 초기에는 린 제조 도구로 사용되다가 소프트웨어 개발에 적용되었습니다.
세 가지 모두 효율성과 적응성을 강조하지만, 기본 원칙은 서로 다릅니다.
스크럼은 엄격한 역할 정의와 지속적인 검토 및 조정을 통해 짧은 시간 내에 시간 제한이 있는 반복에 초점을 맞춰 작업을 수행하는 데 집중합니다.
애자일은 유연성, 공동 작업, 반복적인 제공을 강조하지만 특정 구조를 규정하지는 않습니다. 스크럼과 같은 애자일 프레임워크는 다양한 방식으로 원칙을 구현합니다.
칸반은 지속적 제공과 워크플로우 최적화를 강조하며, 고정된 주기 대신 WIP(진행 중인 작업)를 제한하여 병목 현상을 줄입니다.
접근 방식마다 작업의 관리 및 완료 방식을 정의하는 고유한 작업 방법이 있습니다.
스크럼은 시간이 제한된 스프린트, 사전 정의된 역할, 구조화된 이벤트를 사용합니다.
애자일은 엄격한 규칙 없이 융통성 있는 접근 방식이므로, 팀에서는 프로젝트 요구 사항에 따라 방법을 조정할 수 있습니다.
칸반은 시각적 보드로 진행 중인 작업을 추적하고, WIP 한도를 통해 플로우를 관리하며, 고정된 반복 없이 작업이 유동적으로 진행되도록 합니다.
스크럼은 세 가지 프레임워크 중 유일하게 구체적인 역할을 정의하는 반면, 애자일과 칸반은 역할을 보다 유동적으로 유지합니다.
- 스크럼의 경우 우선 순위, 프로세스, 실행을 관리하려면 제품 소유자, 스크럼 마스터, 개발 팀의 세 가지 핵심 역할이 필요합니다.
- 애자일은 특정 역할을 위임하는 것이 아니라 프로젝트의 요구에 맞는 공동 작업 및 자체 구성 팀을 장려합니다.
- 칸반에는 공식적인 역할이 없으며, 팀이 스스로 조직하되 진행 상황을 감독하기 위해 서비스 제공 관리자 또는 플로우 관리자를 지정할 수 있습니다.
각 방법론은 별개의 성과 지표를 사용하여 진행 상황을 다르게 측정합니다.
- 스크럼은 속도(스프린트당 완료된 작업), 소멸 차트(시간 경과에 따른 잔여 작업), 스프린트 목표를 지표로 사용하여 진행 상황을 추적합니다.
- 애자일은 고정된 메트릭보다는 고객 만족도, 적응성 및 주기 시간에 중점을 두고 필요에 따라 조치를 조정합니다.
- 칸반은 리드 시간(요청에서 완료까지 소요 시간), 사이클 시간(작업에 소요된 시간) 및 WIP 제한을 기반으로 워크플로우를 최적화합니다.
앞서 설명한 대로 스크럼은 유연성과 반복적인 진보를 우선시합니다. 이를 통해 팀을 목표에 집중시키고, 변화하는 요구 사항에 맞춰 빠르고 쉽게 조정할 수 있는 체계적인 접근 방식이 만들어집니다. 이러한 균형은 프로젝트 관리를 최적화하여 다음과 같은 이점을 제공합니다.
스크럼이 여러 가지 이점을 제공하기는 하지만 항상 순조롭게 진행되는 것은 아닙니다. 스크럼을 효과적으로 구현하려면 마음가짐을 바꿔야 하며, 이를 뒷받침 하는 것이 강력한 팀 공동 작업과 헌신입니다. 스크럼에 처음 입문한 팀은 자체 조직의 빠른 속도와 기대에 적응하는 데 어려움을 겪을 수 있습니다. 스크럼 기반 접근 방식을 완전히 적용하기 전에 다음과 같은 잠재적 장애물을 고려하세요.
스크럼은 집중적이고 협력적인 작업을 장려합니다. 하지만 현실적으로는 많은 팀원이 한 번에 여러 프로젝트에 배정되는 경우가 많습니다. 이처럼 주의력이 분산되면 효율성이 떨어지고 스크럼 프로세스에 온전히 참여하기 어려워집니다. 개인이 여러 가지 일을 동시에 처리해야 할 경우, 데일리 스크럼에 참석하거나 스프린트에 충분히 기여하거나 우선순위를 명확히 유지하는 데 어려움을 겪을 수 있습니다. 이러한 문제를 해결하기 위해 조직은 컨텍스트 전환을 최소화하고 팀원을 가능한 한 하나의 스크럼 팀에 할당해야 합니다. 멀티태스킹이 불가피한 경우, 개별 구성원에게 과도한 부담을 주지 않으면서 생산성을 유지하기 위해서는 명확한 작업 부하 관리 및 우선 순위 지정 전략이 필수적입니다.
스크럼 스프린트 구조는 정해진 기간 내에 작업을 완료해야 함을 의미합니다. 팀은 스프린트 내에 완료할 수 있는 작업량을 정확하게 예측하는 데 어려움을 겪을 수 있으며, 이로 인해 완료하지 못한 작업이 발생하거나 스프린트 막바지에 촉박하게 마무리될 수 있습니다. 이러한 문제가 발생할 경우, 과거 데이터와 속도 추적 지표를 활용하여 팀의 예측 역량과 스프린트 계획 수립 과정을 개선하도록 지원해야 합니다.
스크럼의 반복적 특성은 가장 큰 장점 중 하나입니다. 반복적인 수행은 모든 문제가 신속하게 파악되고 해결된다는 것을 전제로 합니다. 팀이 그러한 능력을 갖추지 못하면 장애물이 쌓여서 진행이 지연되거나 방해받을 수 있습니다. 유능한 스크럼 마스터는 문제 해결을 촉진하는 중심적인 역할을 하지만, 팀원들도 적극적으로 우려 사항을 제기하고 해결책을 찾기 위해 협력해야 합니다. 지속적인 학습과 지식 공유의 문화를 장려하면 팀이 문제 해결 노력에 더욱 민첩하게 대응할 수 있습니다.
스크럼은 작업에 대한 집단적 소유권을 장려하도록 설계되었지만, 많은 조직에서 성과 평가는 여전히 개인의 업적을 기반으로 이루어집니다. 이러한 단절은 팀 내에 긴장을 조성할 수 있는데, 이는 팀원들이 팀의 결과보다는 개인적인 성공에 초점을 맞추기 때문입니다. 스크럼을 사용하는 조직은 팀의 기여, 책임감 공유 및 공동 작업의 성공을 강조하는 쪽으로 평가 방식을 전환해야 합니다.
위에 나열된 과제가 어려운 것처럼 보일 수 있지만, 성공적인 스크럼 구현을 막는 장애물이 될 필요는 없습니다. 다음의 베스트 프랙티스는 가장 소극적인 팀조차도 성공을 거두는 데 도움이 될 수 있습니다.
스크럼은 팀워크를 기반으로 하지만, 진정한 공동 작업은 단순히 함께 일하는 것 이상을 의미합니다. 동료 간 공동 작업을 장려하는 것은 팀원끼리 지식을 적극적으로 공유하고 서로 지원하며 문제를 종합적으로 해결하는 환경을 조성한다는 의미입니다. 이는 페어 프로그래밍과 다양한 부서 간 교육을 통해 달성할 수 있으며, 데일리 스크럼과 스프린트 후속 미팅에서 이루어지는 열린 토론을 통해 더욱 강화될 수 있습니다.
스크럼은 정해진 기간의 스프린트를 사용하여 일정하고 예측 가능한 작업 속도를 유지합니다. 물론 이러한 시간 제한은 지나치게 경직된 느낌을 줄 수 있으며, 여유 시간을 확보하기 위해 스프린트 마감일을 연장하고 싶은 유혹에 빠지기 쉽습니다. 그러나 스크럼의 주요 장점 중 하나가 유연성임에도 불구하고, 스프린트 기간을 끊임없이 조정하면 일관성이 떨어지고 진행 상황을 추적하기가 어려워질 수 있습니다. 팀에서는 대응력과 지속 가능한 개발 간의 균형을 맞추기 위해 권장 시간 프레임(일반적으로 2주)을 준수해야 합니다. 스프린트 기간이 너무 짧으면 의미 있는 작업을 완료할 시간이 부족할 수 있고, 반대로 너무 길면 긴박감이 떨어지고 피드백이 지연될 수 있습니다.
체계적인 스크럼 보드가 있으면 팀의 워크플로우를 파악할 수 있으며, 이를 통해 구성원들은 진행 상황을 추적하고 장애물을 식별하며 목표를 수립할 수 있습니다. 스크럼 보드는 물리적 형태든 디지털 형태든 관계없이 제품 백로그와 스프린트 백로그, 그리고 현재 작업 상태를 명확하게 표시해야 합니다. 가상 스크럼 보드는 원격 공동 작업 및 자동 추적을 지원하므로 유연성을 높여줍니다.
스크럼 이벤트에는 모두가 한자리에 모여 프로젝트에 대해 논의할 수 있는 여러 기회가 포함되지만, 회의 자체가 목적이 되어서는 안 됩니다. 각 회의는 스프린트의 성공에 직접적으로 기여하는 명확한 목적을 수행해야 합니다. 팀에서는 토론을 간결하고 실행 가능하며 목표와 일치하는 방향으로 유지하는 데 초점을 맞춰야 합니다. 회의가 스프린트 목표 달성에 의미 있는 진전을 가져오지 못한다면, 회의 방식을 재구성해야 할 수도 있습니다.
ServiceNow는 ServiceNow AI Platform을 통해 종합적인 애플리케이션 및 솔루션 제품군을 제공하며, 팀에서 스크럼을 효과적으로 구현하여 워크플로우를 계획, 추적 및 자동화할 수 있도록 지원합니다. ServiceNow의 SPM(전략적 포트폴리오 관리)은 애자일 이니셔티브를 비즈니스 목표와 연계하는 데 필요한 모든 것을 제공합니다. SPM은 실시간 데이터, 자동화 및 고급 AI 기반 인사이트를 활용하여 작업의 우선 순위를 지정하고 종속성을 관리하며 지속적으로 가치를 제공하는 데 도움이 됩니다.
ServiceNow Scrum Programs for Agile Development를 사용하면 여러 팀이 공유하는 목표를 위해 더 쉽게 공동 작업할 수 있습니다. 스크럼 프로그램 계획 보드는 조직에서 업무를 할당하고, 진행 상황을 추적하고, 부서 간의 종속성을 관리할 수 있는 중앙 집중식 인터페이스를 제공하므로 복잡한 애자일 환경에서도 원활한 조정이 가능합니다. 팀은 스프린트 빈도를 맞추거나 다양화하는 방식으로 운영하면서 백로그 우선 순위와 업무량 분배를 완벽하게 파악할 수 있습니다.
ServiceNow의 전략적 포트폴리오 관리를 통해 목표 설정에 대한 접근 방식을 개선하는 방법을 알아보려면 지금 바로 데모를 예약하세요.