Scrum
Scrum은 고정된 역할, 이벤트, 산출물을 통해 팀이 복잡한 작업을 짧고 반복적인 주기로 다룰 수 있게 돕는 애자일 프레임워크다.
Scrum은 복잡한 제품을 개발하고 관리하기 위한 애자일 프레임워크로, 원래는 소프트웨어 개발에서 형태를 갖췄고 지금은 여러 산업에서 쓰인다. 경험적 프로세스 통제라는 발상에 기반한다. 과제를 처음부터 끝까지 미리 계획하는 대신, 팀은 흔히 1주에서 4주 사이로 지속되는 스프린트라는 짧고 고정된 타임박스 안에서 작업한다. 각 스프린트는 사용 가능한 작업 결과물로 끝나며, 이는 피드백을 위한 여지를 만들고 팀이 다음 단계를 조정할 수 있게 해준다. 투명성, 점검, 적응이 결합된 이 방식은 요구사항이 불확실하거나 바뀔 가능성이 있는 작업에 잘 맞는다.
Scrum은 세 가지 고정된 역할을 규정한다. 제품 책임자(Product Owner)는 제품의 가치를 책임지고, 해야 할 모든 일을 우선순위대로 정리한 목록인 제품 백로그를 관리한다. 스크럼 마스터는 팀이 프레임워크 안에서 작업하도록 지키고, 장애물을 제거하며, 업무를 직접 배정하지 않으면서 협업을 촉진한다. 개발 팀은 스스로 작업을 계획하고 수행한다. 네 가지 반복 이벤트가 각 스프린트의 구조를 만든다. 시작 시점의 스프린트 계획, 빠른 정렬을 위한 데일리 스크럼, 만든 것을 보여주는 스프린트 리뷰, 그리고 협업 방식을 개선하는 스프린트 회고다.
Scrum은 처음부터 범위나 해결책이 완전히 명확하지 않은 과제, 예를 들어 제품 개발이나 이해관계자가 많은 복잡한 프로젝트에서 가장 잘 작동한다. 고정된 타임박스와 정해진 역할이라는 점에서 Kanban과 다른데, Kanban은 정해진 반복 주기 없이 지속적인 흐름에 더 의존한다. 전통적인 워터폴 계획과 비교했을 때 그 강점은 정기적인 점검이다. 오판이 프로젝트 마지막이 아니라 초기에 드러난다. 실무에서 Scrum이 실패하는 원인은 프레임워크 자체보다는 어설픈 실행인 경우가 많다. 예를 들어 회고를 건너뛰거나 백로그를 관리하지 않는 경우다.
실용 예시
중견 기계 제작업체가 생산 설비를 모니터링하는 새로운 소프트웨어를 개발하고 있다. 5인 팀은 2주 단위 스프린트로 작업한다. 각 스프린트가 시작될 때 약 40개의 열린 백로그 항목 중 가장 중요한 10개를 고르고, 15분짜리 데일리 스크럼으로 매일 맞춰본다. 10번의 스프린트, 즉 5개월이 지나자 원래 계획했던 중간 결과물 없는 9개월짜리 개발 대신 처음으로 사용 가능한 버전이 준비된다. 회고를 통해 첫 세 스프린트 동안 불명확한 요구사항이 팀 역량의 약 20퍼센트를 갉아먹었다는 사실이 드러나, 그 뒤로 제품 책임자는 더 명확한 백로그 설명을 작성하기 시작한다.
Leanshift의 도움 방식
스프린트 회고는 본질적으로 반복되는 Kaizen 사이클이다. 팀이 잠시 멈춰 방금 끝난 작업을 정직하게 되돌아보고, 다음으로 넘어가기 전에 작업 방식을 의도적으로 개선하는 것이다. 이는 개선이 일회성 프로젝트가 아니라 일상 업무에 녹아든 정기적인 습관이라는 Leanshift의 관점과 맞닿아 있다. 이런 방식으로 일하는 팀은 제품만 개선하는 것이 아니라 스스로 개선할 줄 아는 사람을 더 많이 길러낸다.
자주 묻는 질문
Scrum은 소프트웨어 개발에만 유용한가?
아니다. Scrum은 소프트웨어에서 시작했지만 지금은 마케팅, 제품 개발, 교육 등 업무가 복잡하고 요구사항이 진행 중에 바뀔 수 있는 모든 분야에서 쓰인다.
Scrum은 Kanban과 어떻게 다른가?
Scrum은 정해진 역할과 이벤트를 갖춘 스프린트라는 고정된 타임박스 안에서 돌아가는 반면, Kanban은 정해진 반복 주기 없이 지속적인 작업 흐름을 시각화하고 한 번에 진행 중인 작업량을 제한하는 데 초점을 둔다.
소규모 팀에도 전담 스크럼 마스터가 정말 필요한가?
반드시 전임 역할일 필요는 없다. 소규모 팀에서는 흔히 누군가가 자신의 본업과 함께 이 역할을 맡는다. 중요한 것은 진행 촉진과 프레임워크 자체가 실제로 지켜지는 것이다.