토글 ( )을 클릭하여, 교육자료의 목차를 확인하고 빠른 이동을 할 수 있습니다.
(전체 토글을 열고닫는 단축키 - Windows : Ctrl + alt + t / Mac : ⌘ + ⌥ + t )
)을 클릭하여, 교육자료의 목차를 확인하고 빠른 이동을 할 수 있습니다.
(전체 토글을 열고닫는 단축키 - Windows : Ctrl + alt + t / Mac : ⌘ + ⌥ + t )목차 확인하기
1. 실전에서 가장 많이 활용되는 애자일 실천 방안
스크럼은 전세계적으로 소프트웨어 프로덕트 조직에서 개발팀이 가장 많이 활용하는 팀 단위의 애자일 실천 방안 입니다. ‘스크럼’ 이라는 단어는 스포츠 럭비에서 경기가 중단되었다가 다시 시작할 때마다 갖추는 팀의 기본 대형인 스크럼 Scrum 에서 유래한 것입니다. 같은 목표를 달성하기 위해 팀이 함께 모인 그 모습이 프로덕트를 개발하는 사람들이 한 팀으로 공동의 목표를 달성하기 위해 협업하는 것과 닮은 것입니다.
스크럼은 일의 콘텐츠를 구체적으로 다루는 것이 아닌, 일을 하는 기본적인 틀만 제시하고 있으면서, 스크럼의 규칙이라 할 수 있는 이벤트들을 담는 그릇과 같은 역할을 합니다. 그래서 일 하는 방식에 대한 프레임워크, 즉 스크럼 프레임워크 입니다. 스크럼은 작은 팀이 실천할 수 있기 때문에 조직의 규모가 작아도 실행할 수 있고, 조직의 규모가 큰 경우에는 그만큼 많은 수의 스크럼 팀을 구성하여 규모를 키울 수 있어서, 어떠한 조직 형태에도 맞춰서 활용할 수 있습니다.
2. 스크럼의 이론적 기반
스크럼은 경험주의에 기반하고 있습니다. 과학 실험과 같이 가설을 가지고 계획한 것을 실행하고, 실행 결과를 분석하여 다음 가설과 계획을 다시 수립하는 과정을 반복하는 것입니다. 실제 경험한 것을 기반으로 학습을 하면서 변화하는 상황에 적응해 나가는 것입니다. 이 때, 팀은 투명하게 상황을 드러내는 것, 발견한 사항들과 실행 결과를 점검하는 것, 학습한 것에 적응하는 것을 핵심으로 운영됩니다.
스크럼 프레임워크는 소프트웨어 개발팀에 국한하지 않고 어떠한 형태의 프로덕트를 만드는 팀에도 적용할 수 있도록 일반화 한 개념입니다. 여기에서는 소프트웨어 프로덕트, 디지털 프로덕트를 개발하는 팀으로 한정하여 이야기 합니다.
3. 스크럼 3가지 역할
스크럼 프레임워크를 활용하여 일을 하는 프로덕트 팀에는 3가지 역할이 있습니다. 프로덕트 오너, 스크럼 마스터, 개발자들 입니다. 프로덕트 오너와 스크럼 마스터는 각 한 사람씩만 존재합니다. 개발자들은 여러명 입니다. 이 세가지 역할이 모여서 한 팀을 이루는 스크럼 팀 하나의 인원은 최소 3명에서 최대 9명 정도의 규모 입니다. 스크럼 팀은 하나의 미션을 갖거나, 팀이 담당하는 프로덕트 하나, 또는 큰 프로덕트의 특정 도메인이나 분할한 영역을 담당하게 됩니다.
프로덕트 오너 (여기에서는 프로덕트 매니저와 같은 역할로 이해합시다.)
프로덕트 오너는 스크럼 팀이 담당하는 프로덕트의 모든 권한을 소유하는 역할입니다. 프로덕트 오너의 역할을 설명하기 위해 ‘미니 CEO’, ‘가치를 극대화하는 사람’ Value Maximizer, ‘다리’ Bridge (스크럼 팀과 이해관계자 간의 소통) 라고 별명을 붙일 수 있습니다. 미니 CEO 라는 의미는 기업 내에서 프로덕트 오너가 담당하는 부분 만큼은 직접 최종 결정을 하고 책임을 가지고 결과를 만드는 과정을 수행하는 온전한 프로덕트 소유권과 권한을 위임 받는다는 의미 입니다.
프로덕트 오너는 프로덕트의 가치를 극대화하기 위해 할 일을 생성하고 각 할 일의 가치를 지속적으로 업데이트 하여 일의 우선순위를 조정합니다. 개발자들은 우선순위가 높은 일부터 진행합니다. 프로덕트 오너는 개발자들과의 소통을 통해서 할 일을 완료하는데에 필요한 노력의 정도와 그 일이 완료되었을 때 얻을 수 있는 가치를 고려하여 우선순위의 최종 결정을 내립니다. 이러한 결정을 올바르게 판단하기 위해 유저, 주요 이해관계자, 개발자들과 끊임없이 소통하고 공감하면서 특히 왜 이런 일을 해야하는지에 대해 팀에 알려줄 수 있어야 합니다.
스크럼 프레임워크에서는 ‘프로덕트 오너’ Product Owner 라는 명칭을 사용합니다. 이것은 일반적인 프로덕트 조직의 프로덕트 매니저와 같은 역할로 이해할 수 있습니다. 실제 프로덕트 조직에서는 성격에 따라서 프로덕트 오너, 또는 프로덕트 매니저 라는 하나의 역할 명칭을 사용하기도 합니다. 또한 프로덕트 매니저가 높은 레벨에서의 미션과 로드맵을 관리하고, 하위에 프로덕트 오너들이 구체적으로 할 일 단위를 계획하고 우선순위를 조정하는 역할로 나뉘어 운영하기도 합니다.
스크럼 마스터
스크럼 마스터는 스크럼 팀의 팀원들이 스크럼 프레임워크를 올바르게 이해하고 수행할 수 있도록 가이드하고 환경을 조성합니다. 스크럼 팀의 팀원들은 모두가 동등한 수평 레벨의 소통과 의견을 제시할 수 있는데, 스크럼 마스터는 스크럼을 수행하는 측면에서는 리더쉽을 발휘하여 팀을 이끌고 일의 진척이 막힘없이 진행되도록 지원합니다. 특히 팀이 가지고 있는 장애물 Impediment 를 식별하고, 해결 또는 해소하는 일을 직접 하거나 장려하는 것이 중요합니다. 스크럼 마스터는 스크럼 팀의 정신적인 리더이자 도움을 제공하는 ‘서번트 리더’ Servant Leader 라고 할 수 있습니다.
스크럼 마스터가 스크럼 팀에서 담당하는 역할은 중요합니다. 하지만 실제 업무 현장에서 스크럼 마스터 역할을 따로 채용하는 경우는 국내에서는 극히 드문 일 입니다. 스크럼 마스터 역할을 스크럼 팀 개발자들 중의 리드 역할자가 하거나 스크럼 팀 내 역할과 별도로 팀 매니저가 있는 경우 이 역할을 담당하는 경우가 많습니다.
프로덕트 오너 (프로덕트 매니저)가 이 역할을 겸하기도 하지만, 스크럼을 고안한 사람들의 입장에서 이 경우를 지양해야 한다고 합니다. 프로덕트 오너는 1인으로서 본연의 역할을 잘 하는 것이 중요하고, 목표와 할 일 우선순위를 결정하는데 중요한 의사결정자인 프로덕트 오너가 팀을 가이드하고 리드하는 역할까지 맡는 경우, 개개인 간 수평적이고 자율적인 자기 경영을 지향하는 스크럼 팀의 균형이 무너질 수 있기 때문입니다.
개발자들
개발자들은 다수의 구성원으로 스크럼 팀이 가지고 있는 목표를 달성하는데 필요한 모든 프로덕트 개발 역량을 가지고 있는 전문가들 입니다. 여러 역할을 가지고 있는 (예를 들어, 디자이너, 아키텍처, 프론트엔드 개발자, 백엔드 개발자, QA 등) 사람들의 모임으로 교차 기능 Cross functional 팀이 되는데, 이들 간에도 서로의 역량과 가지고 있지 않은 새로운 역량을 학습하는 T자형 인재로 역할을 할 수 있어야 합니다.
4. 스크럼 3가지 산출물
스크럼 팀이 스크럼 프레임워크를 기반으로 프로덕트를 개발하면 그 과정에서 3가지 산출물을 갖습니다.
프로덕트 백로그 Product Backlog
프로덕트 백로그는 스크럼 팀이 가지고 있는 모든 할 일 목록 입니다. 프로덕트 백로그에 있는 할 일의 단위를 프로덕트 백로그 아이템 Product Backlog Item 이라고 부르고, 프로덕트 매니저는 이 PBI 를 가치를 극대화 하기 위한 전략에 따라 우선순위를 정렬해 두고 개발자들과 협의합니다.
스프린트 백로그 Sprint Backlog
스프린트 백로그는 스크럼 팀이 한 스프린트 (스크럼 팀이 반복적으로 수행하는 개발 주기 단위) 동안에 완료할 것을 목표로 선정한 할 일의 목록 입니다. 프로덕트 백로그의 PBI 중에 우선순위와 개발 순서를 고려하여 스프린트 기간 내에 완료할 수 있을 만큼에 완료해야 하는 만큼을 가져가서 스프린트 백로그 아이템으로 결정합니다.
프로덕트 개발 증가분 Increment
개발 증가분은 스크럼 팀이 스프린트 동안에 완료한 할 일로 인해 발생한 프로덕트에 추가된 영역의 모음 입니다. 프로덕트에 새로운 기능이나 변경된 부분을 의미합니다. 스크럼 팀은 스프린트마다 꾸준히 개발 증가분을 만들어 내는 것이 필요합니다. 개발 증가분을 통해서 가설을 검증하고 새로운 발견을 할 수 있기 때문입니다. 개발 증가분을 축적하고 있다가 프로덕트의 전략에 따라 릴리스 목표일에 최종 사용자에게 전달 Delivery 하는 릴리스 Release 를 실행합니다.
5. 스크럼 5가지 이벤트
스크럼 프레임워크가 스크럼 이벤트를 담는 그릇 역할을 한다고 했으니, 이벤트는 어떤 것들이 있는지 살펴보겠습니다. 스크럼 이벤트는 총 5가지 입니다. 스프린트, 스크린트 계획, 데일리 스크럼, 스프린트 리뷰, 스프린트 회고 입니다. 스크럼에서는 실질적인 프로덕트 개발 진척을 위해서 스크럼 이벤트를 일정한 시간 제한 Timebox 내에 실행할 것을 가이드 합니다.
스프린트 Sprint
스프린트는 스크럼 팀이 반복적으로 수행하는 일정한 길이의 고정된 프로덕트 개발 주기 입니다. 스크럼은 전체 할 일을 작은 기간 단위로 나누어 개발을 진행하면서 지속적으로 학습하고 적응하는 방식을 하고 있기 때문에, 스프린트는 최소한의 길이를 갖는 것이 민첩할 수 있는 전략이지만, 스프린트 기간에 충분히 개발 증가분을 만들 수 있는가도 고려하여 적절한 길이를 선택합니다. 일반적으로 1주~4주 정도의 길이 내에서 주 단위로 결정합니다. 가장 많은 사례는 2주 길이의 스프린트 입니다. 스크럼 팀은 일정한 실험과 역량 향상을 점검하기 위해 스프린트 길이를 고정하는 것이 좋습니다. 스프린트를 하는 동안 스크럼 팀은 다음의 4가지 다른 이벤트 들을 스프린트 기간 내에 하게 됩니다.
스프린트 계획 Sprint Planning
스프린트 계획은 스크럼 팀이 하나의 스프린트의 시작할 때 1일차에 실행하는 이벤트 입니다. 이번 스프린트 동안 어떤 목표를 달성할 것이고, 그 목표를 달성하기 위해 필요한 PBI 가 무엇인지를 파악하여, 스프린트 백로그로 가져오는 결정을 합니다. 프로덕트 오너는 스프린트 백로그를 구성하기 위해 프로덕트 백로그 아이템의 내용을 팀 전체가 이해하고 있는지 확인하고, 목표와 우선순위 결정에 대해서도 설명해 줍니다. 스프린트 백로그를 결정한 다음 개발자들은 이번 스프린트 동안 어떻게 스프린트 백로그 아이템들을 모두 완료할 수 있을지 작전을 논의합니다.
스프린트 계획은 스크럼 팀의 모든 역할자가 함께 하는 이벤트 입니다. 스프린트 계획은 스프린트 길이에 따라 보통 4시간에서 최대 8시간 내에 완료합니다. 스프린트 계획을 잘 하기 위해서는 스크럼 팀이 특히 프로덕트 오너와 스크럼 마스터가 이전 스프린트 기간 중에 백로그 정제 Backlog Refinement 작업을 하는 것이 도움이 됩니다. 백로그 정제는 PBI 의 내용을 명확히 하고, 프로덕트 오너의 전략에 맞추어 우선순위가 정렬되어 있는지 점검하는 것입니다. 백로그 정제를 할 때 각 백로그 내용을 함께 이해하고 구체적인 내용을 작성하기 위해 개발자들과 작업을 할 수 있습니다.
데일리 스크럼 Daily Scrum
데일리 스크럼은 스프린트의 2일차 부터 스프린트 완료일까지 매일 한 번 스크럼 팀의 개발자들이 모여서 스프린트 목표를 달성하는 과정에서 24시간의 진척과 다음 24시간의 진척 계획을 서로 확인하는 이벤트 입니다. 필요한 경우, 백로그 아이템의 우선순위나 스프린트 백로그 아이템을 프로덕트 백로그 아이템과 교환하기 위한 논의를 프로덕트 오너와 할 수 있지만 드문 일 입니다. 할 일의 진척을 어렵게 하는 방해 요소나 다른 사람의 도움이 필요한 일을 언급하는 것 또한 중요한 정보이며, 이것을 잘 해결할 수 있도록 개발자들 또는 필요하면 스크럼 마스터와 협력합니다. 데일리 스크럼은 개발자들의 이벤트 이지만, 개발자들에게 가이드를 하거나 진행에 도움을 주기 위해 스크럼 마스터가 참여할 수 있으며, 프로덕트 오너도 정보를 얻기위해 참여해서 내용을 들어볼 수 있습니다. 데일리 스크럼은 15분 동안 진행합니다.
스프린트 리뷰 Sprint Review
스프린트 기간 동안 설정한 스프린트 목표를 달성하기 위해 필요한 일을 백로그 아이템 단위로 완료하면서, 프로덕트 개발 증가분이 누적됩니다. 스크럼 팀은 주로 스프린트 마지막 날에 스프린트 리뷰 이벤트를 열어서, 개발 증가분을 확인하면서 피드백과 프로덕트 백로그의 우선순위에 영향이 있는 정보를 수집합니다. 보다 의미있고 정확한 정보를 얻기 위해, 프로덕트의 실제 유저와 스크림 팀의 주요 이해관계자를 스프린트 리뷰에 초대해야 합니다. 이들에게 프로덕트 개발 증가분을 체험할 수 있게 제공하거나 시연을 하고 의견을 듣습니다. 프로덕트 오너는 스프린트 리뷰 동안 얻은 의견을 정리하여 백로그 정제 또는 다음 할 일을 구체화 할 때 반영합니다. 스프린트 리뷰는 최대 4시간 동안 진행합니다.
실제 업무 현장에서 스프린트 리뷰 마다 실제 유저 또는 주요 이해관계자 (기업의 임원, 스크럼 팀의 상위 책임자, 사업 부서 협력자)를 매 번 참여시키는 것은 쉽지 않습니다. 스프린트 리뷰 이벤트를 초대하는 사람들이 참여하기 좋은 때에 진행하거나, 적어도 몇 번의 스프린트의 개발 증가분이 축적된 마일스톤이 완료되는 경우에는 반드시 참여하도록 안내하는 것이 좋습니다.
스프린트 회고 Sprint Retrospective
스크럼 팀의 학습과 적응이 일어나게 하는 중요한 이벤트 입니다. 스프린트 기간 동안에 스크럼 팀의 일이 어떻게 진행되었는지, 팀이 각자 일 하는 방식과 협업하는 방식은 어떤지, 팀이 사용하는 도구는 어떤 것을 어떻게 활용하는 것이 좋을지 등 팀이 일 하는 방식과 문화에 대해서 효과적인 팀이 되기 위한 논의를 합니다. 이 과정을 거쳐서 팀원들은 경험을 기반으로 새로운 것을 학습하고 다음 스프린트에는 배운 것을 적용하면서 변화에 적응해 갑니다. 스프린트 회고에는 스크럼 팀 모두가 참여하고, 최대 3시간 동안 진행합니다.
스프린트 회고는 주로 팀원 개인 또는 팀이 가지고 있는 문제점을 다루기 때문에 참여하는 사람들은 성숙한 마인드셋과 대화를 해야 합니다. 이 때, 스크럼 마스터가 적합한 주제, 적절한 퍼실리테이션 도구 제공, 팀원 중재, 의사결정 방식 제안, 팀 외부자 참여 막기 등으로 스크럼 팀이 투명하게 대화하고, 필요한 결론으로 이끌어 내는 중요한 역할을 합니다. 팀원들은 변명, 책임 회피, 비난을 하지 않고, 문제 인식, 필요한 정보 제공, 합리적인 의사결정, 성숙한 자세로 대화를 하여 다음 스프린트 부터는 개선하거나 해결 노력을 할 수 있는 액션 아이템을 결정합니다. 회고 동안 나누는 대화를 통해서 정서적으로 서로를 공감하고 이해가 깊어질 수 있는 분위기를 조성하는 것이 중요합니다.
스프린트 회고는 실제 업무 현장에서 종종 무시되어 하지 않는 경우가 있습니다. 또는 스프린트 리뷰와 통합되어 리뷰와 회고 모두 본연의 목적이 불분명하게 스프린트 완료만 축하하기도 합니다. 스프린트 회고는 스크럼 프레임워크가 작동하는 중요한 이벤트 입니다. 프로덕트 개발 업무에만 집중하여 회고를 하지 않으면서 팀으로 일을 계속하게 되면, 문제는 없는 것처럼 보이지만 실제로는 문제가 드러나지 않고 속에서만 존재합니다. 드러나지 않은 문제들은 팀을 분열시키고 증폭되어 오해가 커지면서, 결국에는 팀이 목표를 달성하는데에 큰 문제가 발생하거나 팀원들이 기업을 떠나는 현상으로 나타나게 됩니다.
스프린트 회고를 스프린트 리뷰와 분리하고, 스프린트 회고에서 건강하게 대화하기 위한 팀 선서를 만들어 보세요. 또한 개인의 성격과 관계없이 의견이 잘 나올 수 있도록 내용을 시각화하는 다양한 도구나 회고 틀을 사용해 보면서 팀 고유의 문화를 만들어 나가는 노력이 병행되어야 합니다. 가장 중요한 것은 회고 자체뿐 아니라 회고에서 결정한 개선 액션 아이템을 실제로 실천하여 적용하는 것입니다.
6. 스크럼 5가지 가치
스크럼 팀은 정신적으로 5가지 가치를 가져야 합니다. 스크럼 팀은 높은 수준의 팀 의식, 사기, 결과물의 품질을 지향합니다. 그런 상태를 지속적으로 유지하고 향상시키기 위해서는 행동을 뒷받침하는 마인드셋이 갖추어져야 현실적으로 가능한 일입니다.
집중 Focus
스크럼 팀은 팀의 목표에 집중하고, 스프린트 과정과 이벤트 내에서 헌신적으로 참여합니다.
열린마음 Openness
스크럼 팀은 변화나 새로운 시도에 개방적인 태도를 갖습니다.
존중 Respect
팀원들은 다른 팀원들의 역할과 전문성, 의견을 존중하여 경청하고 함께 협력합니다.
용기 Courage
스크럼은 개인이 가지고 있는 정보로부터 새로운 발견을 하는 것 Bottom-up intelligence 을 지향합니다. 개인은 용기를 가지고 필요한 의견을 말해야 합니다. 또한 스크럼 팀은 변화와 어려운 목표 등을 달성해야 하는 만큼 적극적인 도전 정신을 지향합니다.
약속 Commitment
자율경영 팀이 되기 위해서는 타인이 개인을 관리하기 전에 개인 스스로 책임있게 임무를 수행하는 것이 방법입니다. 스크럼 팀은 자신이 할 일, 완료할 일을 약속하고 반드시 완료하기 위해 전념합니다.
스크럼 프레임워크가 제시하는 가이드를 따르는 행동은 쉽습니다. 그렇기에 스크럼을 하는 팀이 스크럼을 따르기는 하지만 스크럼이 의도한대로 제대로 작동하지 않는 경우도 있습니다. 그런 경우에 팀은 문제의 원인이 스크럼 프레임워크에 있다고 여기게 됩니다. 하지만 팀은 스크럼 가치를 함양하고 있는지 생각해 볼 필요가 있습니다.
7. 애자일 지향 조직에 스크럼 프레임워크가 주는 효용
스크럼 프레임워크는 위에 있는 사항만 알고도 시작을 할 수 있을 정도로 실제적이고 간단한 일 하는 방식 입니다. 많은 경우 애자일 팀으로 애자일 방식으로 일을 하고 싶은데 어떻게 하는 것인지 모르는 경우가 많습니다. 이런 팀에게 스크럼은 쉽게 실천할 수 있는 틀을 제공합니다. 스크럼 위에서 팀이 목표, 영향력있는 결과 Outcome / Impact, 정신적인 가치를 가지고 지속적인 개선을 반복한다면 애자일을 실현하는 팀으로 발전할 수 있습니다. 스크럼이 제공하는 리듬을 체득하고 경험을 통해 가이드가 제공하지 않는 속 내용은 팀 고유로 만들어 가보세요.
← 이전 주제
다음 주제 →
Copyright 2022. ⓒ TeamSparta All rights reserved.
