애자일 팀과 프로덕트 오너의 대응 전략에 대해서 이야기해보겠습니다. 애자일 팀과 프로덕트 오너(PO)의 대응 전략에 대해서 알아보는 것은 매우 의미 있는 일입니다. 애자일 팀은 전통적인 프로젝트 팀과는 다릅니다. 애자일 팀은 애자일 프로세스의 사상을 적용하여 스크럼 마스터와 프로덕트 오너(PO), 그리고 개발팀이 하나가 되어 결과물을 만들어 냅니다. 애자일 프로젝트에서의 핵심인 애자일 팀과 프로덕트 오너의 케이스 별 대응 전략에 대해서 자세히 알아보도록 하겠습니다. 애자일 팀은 프로적트 오너와 협력해서 프로젝트를 진행합니다.
애자일 팀과 프로덕트 오너의 이해
프로덕트 오너(PO)는 반복 계획 도중에 다음 반복에서 얼마나 많은 작업을 완료해야 하는지에 대해서 개발 팀에 전달할 수 없습니다. 반복 계획 중에서 프로덕트 오너의 역할은 백로그 항목의 우선 순위를 정하는 것입니다. 그런 다음에 애자일 팀은 다음 반복 타임 박스에서 백로그의 최우선 순위 항목 중 몇 개를 완료할 수 있는지를 결정합니다. 따라서 다음 반복에서 완료할 수 있는 작업의 양은 프로덕트 오너(PO)나 스크럼 마스터가 아니라 애자일 팀이 결정합니다. 데일리 스탠드업 미팅에서 팀 코치는 즉각적인 후속 조치를 위해서 문제를 듣고 기록합니다.
데일리 스탠드업 미팅에서 스크럼 마스터나 팀 코치의 역할은 빠른 후속 조치를 위해서 팀의 진행 상황에 대한 장애를 듣고 기록하는 것입니다. 해당 회의는 일반적으로 매일 같은 시간과 장소에서 개최되기 때문에 일반적으로 일정이 필요하지 않으며 팀 구성원이 서로 돌아가며 이야기하기 때문에 촉진이 필요하지 않습니다. 애자일 프로젝트에서 애자일 팀의 팀원이 자신의 동료들과 함께 작업을 추정하고 있으면 이는 반복 계획을 진행하고 있는 것입니다. 가장 처음 사용자 스토리를 추정하는 단계는 상위 수준의 계획 수립인 비전 수립 단계입니다. 이 때 추정은 프로젝트 전체의 크기와 릴리즈를 구분하기 위한 수준의 추정입니다.
릴리즈 계획 수립에서도 추정을 하는데 이 때의 추정은 반복을 구분하기 위한 추정으로 이전 추정 보다는 상세화 되었지만 작업 수준의 상세 추정이라고 할 수는 없습니다. 애자일 작업 단위가 점차 큰 단위에서 작은 단위로 세분화되고 마지막 책임 순간에 추정됩니다. 작업은 가장 작은 애자일 단위이기 때문에 작업이 완료되기 직전의 마지막 계획 단계까지 이러한 작업 항목이 추정되지 않을 것이라는 논리를 추론할 수 있습니다. 애자일 프로젝트에서 새로운 리스크가 식별 되었을 때 프로덕트 오너는 분명하게 보이는 위치에 리스크를 추가하고 다음 데일리 스탠드업 회의 후에 논의하는 것이 가장 좋은 첫 단계입니다.
애자일 프로젝트를 진행하고 있던 중간에 새로운 리스크가 식별 되면 애자일 팀은 주제 전문가에게 그 가능성과 영향을 평가하도록 요청해야 합니다. 리스크 대응에 대한 순서는 식별, 분석 , 대응 방안 수립, 시행입니다. 리스크가 발견되었다는 것은 리스크가 식별 되었다는 의미입니다. 그 다음은 리스크를 분석하는 것입니다. 리스크는 아직 발생하지 않은 일이라는 것을 알아둘 필요가 있습니다. 리스크를 분석하였는데 리스크가 사소한 것으로 판명 되면 리스크 기반 스파이크를 하지 않을 것이기 때문에 분석이 끝나야 리스크 기반 스파이크를 할 수 있습니다. 스파이크는 애자일에서 사용하는 개념입니다.
애자일 팀의 케이스별 대응 전략 알기
에픽은 유저 스토리보다 더 큰 개념으로 아직 덜 분할 된 상태의 기능이나 사용자 스토리를 의미합니다. 우선 순위가 높아서 바로 실행 되어야 할 스토리였다면 에픽으로 놓아두지 않고 더 세밀하게 분할했을 것입니다. 애자일 프로젝트에서의 요구 사항 계층 구조는 에픽과 기능들로 구성되어 있습니다. 제품 백로그에서 에픽은 스토리의 바닥이나 바닥 근처에 위치 합니다. 애자일 팀에서 유저 스토리를 분할하고 있으면 이것은 스토리를 한 번의 반복으로 완성할 수 있는 크기로 분할하는 것입니다. 애자일 팀은 타임 박스라고 하는 개념을 사용합니다. 타임 박스는 작업이 정해진 최대 시간 이상을 사용할 수 없는 것을 의미합니다.
애자일 프로젝트는 타임 박스로 활동하는 것입니다. 활동에 타임 박스가 있다는 것은 최대 지속 시간이 지정되어 있다는 것을 의미합니다. 가치에 더 집중하기 위해서 사용하는 방법이며 타임 박스에서 작업은 정해진 최대 시간 이상을 사용할 수 없게 됩니다. 애자일 프로젝트에서 계획을 수립하는 방법은 여러 수준으로 계획하고 애자일 팀 팀원들에게 반복 계획을 작성하도록 하는 것입니다. 애자일 프로젝트에서 계획 결과는 이해 관계자와 가장 눈에 잘 띄는 방법을 사용하여 공유될 수 있습니다. 애자일 프로젝트에서 계획 수립은 이해관계자 회의에 의해 결정됩니다. 회의 결과는 정보 상황판 처럼 눈에 잘 보이도록 만들어서 모든 이해 관계자들에게 공유합니다.
애자일 프로젝트가 전통적인 프로젝트처럼 프로젝트 관리 계획서를 공식적으로 만들어서 공유하거나 시스템을 통해서 공유하지 않는다는 것이 중요합니다. 인수 테스트는 일방적으로 사용자 스토리에 대해 제품 백로그에서 우선 순위를 정하기 시작될 때 작성합니다. 유저 스토리를 작성하면서 인수 기준과 인수 테스트 기준을 기술하게 됩니다. 점진적 상세화가 될 수도 있지만 인수 테스트 기준을 작성하는 것이 바람직합니다. 제품 백로그에서 우선순위를 정할 때 좀 더 명확한 근거를 가지고 우선순위를 정할 수 있습니다. 리스크 식별은 가능한 모든 이해 관계자가 참여하여 식별하는 것이 좋습니다. 하지만 리스크 대응 방법은 애자일 팀과 협의 해야 합니다. 리스크 정의는 불확실한 사건이나 상황을 의미하며 이슈나 문제는 이미 벌어진 사건입니다. 항상 리스크 관리 대장이나 정보 상황판과 같은 보드에 리스크를 등재하고 프로덕트 오너는 애자일 팀과 협의를 하여 대응 방안을 수립하는 것이 좋습니다.
스파이크는 애자일 팀이 가능하면 빨리 문제를 해결하기 위해서 사용하는 핵심 도구입니다. 스파이크는 애자일 팀이 타임 박스를 이용하여 조사를 진행할 때까지 예측할 수 없는 스토리로 볼 수 있습니다. 스파이크는 접근 방식을 탐색하거나 문제를 조사하거나 프로젝트 리스크를 줄이기 위한 짧은 노력입니다. 이를 타임 박스라고도 합니다. 프로젝트 중에 언제든지 스파이크를 진행할 수 있지만 개발 노력이 시작되기 전에 프로젝트 시작할 때 수행되는 간단한 탐색 반복이나 개념 증명 노력의 형태를 취하는 경우가 많습니다. 구조적 스파이크는 개념 증명에 전념하는 짧은 시간 노력입니다. 애자일 팀에서 사용하려고 하는 접근 방식이 프로젝트에 적합한지를 확인할 때 사용합니다. 리스크 기반 스파이크는 애자일 팀이 프로젝트에 대한 문제나 위협을 줄이거나 리스크를 없애기 위해서 조사를 하는 짧은 타임 박스 노력입니다.
프로젝트의 리스크가 있는 부분을 조사하기 위한 짧은 실험은 리스크 관리를 위한 핵심 도구입니다. 리스크 기반 스파이크는 프로젝트의 진척이 더 진행되기 전에 프로젝트 초기에 익숙하지 않거나 새로운 기술을 테스트하기 위해서 주로 사용됩니다. 애자일 프로젝트에서 문제 해결에 대해서 문제가 발생하면 즉시 수정하거나 백로그에 추가하는 것이 가장 올바른 접근 방법입니다. 애자일 접근 방식에서는 문제 해결 보다는 예방을 중요하게 생각합니다.
하지만 예방을 했음에도 불구하고 문제가 발생하면 즉시 해결하는 것을 원칙으로 합니다. 즉시 해결하려고 노력하는 것은 애자일 사상과 관련되어 있는 것입니다. 애자일로 진행하는 프로젝트의 개발 팀원이라고 하였을 때 개발 반복 기간 동안 어렵고 까다로운 문제를 마주하게 되면 가능한 빨리 팀원들과 문제를 공유하고 해결에 대한 도움을 요청해야 합니다. 애자일 팀은 자율 구성팀이며 집단적 문제 해결을 좋아합니다. 애자일 프로젝트가 아주 잘 진행되고 있다면 애자일 팀이 릴리즈 계획을 앞당길 수 있는 기회를 제공할 수 있게 됩니다. 회고는 일반적으로 반복 검토 후 각 반복의 끝에 개최되는 회의이며 프로젝트의 수행 방법과 애자일 팀의 팀워크를 점검하고 개선할 수 있는 관행이라고 볼 수 있습니다.
애자일 팀의 케이스별 상황에 대한 이해
애자일 프로젝트에서 많이 사용하는 번 다운 차트의 목적은 남은 작업을 시간에 따라 표시하는 것입니다. 번 다운 차트는 프로젝트에서 진행해야 할 작업을 추적하여 그래프로 나타낸 것입니다. 번 다운 차트의 진행선은 작업이 완료됨에 따라서 남아 있는 작업량이 줄어드는 것을 반영하기 때문에 오른쪽으로 갈수록 아래로 향하게 됩니다. 번 다운 차트의 가장 일반적인 용도는 프로젝트 작업을 완료하는 팀의 진행률을 측정하고 남은 예상 시간과 남아 있는 예상 스토리 포인트를 확인하는 것입니다. 번다운 차트는 프로젝트에서 진행해야 할 작업을 추적하여 그래프로 나타낸 것입니다. 대표적인 번 다운 차트는 스토리 포인트 번 다운 차트입니다. 일부 반복 기반 프로젝트는 번다운 차트를 사용하여 반복 안에서 시간이 자나감에 따라서 프로젝트가 진행되는 위치를 표시해줍니다.
스토리 포인트 번 다운 차트는 스토리 포인트를 제공할 계획인 반복 안의 번 다운 차트를 보여주는 것입니다. 리팩토링을 위해서 자원을 사용하지만 기능이 만들어지거나 작업이 완료되지 않습니다. 애자일 프로젝트에 대한 일정은 일반적으로 스토리 포인트 추정과 속도 적용으로 설정됩니다. 애자일 프로젝트에서 일정은 고객의 요구 사항을 제품 백로그에 전부 기재한 다음 유저 스토리에 대한 스토리 포인트를 추정합니다. 추정이 완료되면 팀의 추정된 속도를 적용하여 몇 번의 릴리즈와 반복 동안 제품 백로그에 있는지 유저 스토리를 완료할 수 있는지 계산하여 프로젝트의 일정을 산정합니다. 팀의 속도와 일정은 단순한 추정이며 프로젝트가 진행될수록 더 정확한 속도와 일정을 산정할 수 있습니다.
이러한 작업은 상위 수준 계획 수립에서 발생하고 나중에 릴리즈 계획을 수립하거나 반복 계획을 수립하게 되는데 이 때 일정이 변경될 수 있습니다. 애자일 프로젝트에서 일정 관리를 하기 위해서는 스토리 포인트라는 개념과 속도라는 개념을 알고 있어야 합니다. 애자일 프로젝트에서 상위 수준의 추정 방법이 전략적 수준을 의미합니다. 애자일 프로젝트에서 상위 수준의 추정은 먼저 제품 백로그 항목을 정하고 스토리 포인트와 같은 추상적인 측정치를 사용하여 선호도를 추정하고 플래닝 포커, 티셔츠 규모 산정 방식 등으로 추정합니다. 애자일 프로젝트에서 제품 백로그 항목을 추정하는데 사용하는 스토리 포인트는 사용자 스토리에 대한 크기의 상대적 측정입니다.
제품 로드맵은 제품 릴리즈와 각 릴리즈에 포함될 중요한 구성 요소들을 시각적으로 보여주는 그림입니다. 프로젝트 이해 관계자에게 중요한 릴리즈 시점과 제공될 것으로 예정되는 기능을 빠르게 보여줄 수 있는 커뮤니케이션 툴입니다. 해당 접근 방식을 통해서 애자일 팀은 기능을 중요도와 순서에 따라 스토리 맵에 배치한 다음 고객의 우선순위와 예상 용량을 균형감 있게 조정하고 각 릴리즈에서 인도할 계획을 간략하게 설명할 수 있게 됩니다. 제품 로드맵은 각 릴리즈를 통해 인도될 기능과 테마에 대한 상위 수준의 표현이라는 점을 알아야 합니다.
애자일 팀 특징과 구성에 대한 이해
애자일 팀 특징과 구성의 경우 애자일 프로젝트 만의 독특한 특성을 가지고 있습니다. 애자일은 적응형 접근 방식의 대표적인 방법론입니다. 애자일 개발 방식에는 애자일 프로젝트만의 애자일 모델, 기법, 결과물들이 있습니다. 애자일 방법론은 기존의 전통적인 소프트웨어 개발 방법론의 문제점들을 개선하기 위해서 등장한 개발 방법론입니다.
기존의 워터폴 개발 방식의 문제점을 개선하기 위해서 등장한 새로운 접근법인 것입니다. 프로세스와 도구 보다는 개인과 개인 간의 상호작용을 중요시 하고 보고와 정리를 위한 포괄적인 문서를 만들기보다는 실제 작동하는 소프트웨어를 만드는 것이 집중하며 계약 협상에 앞서서 고객사와의 협업을 강조하는 문화를 가지고 있습니다. 그리고 계획 준수에 앞서서 변화에 대한 대응을 중요하게 생각합니다. 그럼 애자일 팀의 특징과 구성에 대해서 더 자세히 알아보도록 하겠습니다.
애자일 팀 특징과 구성에 대해 알기
애자일 팀의 특성에 대해서 이야기해보겠습니다. 애자일 팀의 경우 변화하는 환경에 지속적으로 적응하고 건설적인 피드백을 수용할 수 있는 일반 전문가로 구성된 자율 구성팀과 같은 집중과 협업을 극대화할 수 있는 팀 구조가 가장 효과적입니다. 자율구성팀은 중앙의 통제 없이 구성원들이 팀 목표 달성을 위해서 리더십을 발휘하여 자율적으로 운영되고 협업 할 수 있는 교차 기능 팀입니다.
애자일 팀 구조는 협업을 통해서 작업 활동의 빠른 통합이 쉽고, 의사소통을 개선하고 지식을 공유하고 향상 시키는 등 유연한 작업 할당이 가능한 장점이 있습니다. 애자일 팀은 가변성이 크고 변화의 속도가 빠른 프로젝트에서 성공할 수 있는 방법론입니다. 이러한 환경에 유리한 구조입니다. 애자일 팀은 중앙 집중식 업무 처리와 의사결정에 시간이 많이 발생하지 않도록 하는 것이 핵심 포인트입니다.
애자일 팀을 구성하는 것인 애자일 프로젝트를 진행하기 위해서 매우 중요합니다. 그리고 애자일 팀은 특유의 특징과 특성을 가지고 있기 때문에 애자일 팀의 구성원이 되기 위해서는 애자일의 사상과 애자일 문화에 대해서 이해하고 있어야 합니다. 애자일 팀을 구성하는 핵심적인 역할자들인 프로덕트 오너, 스크럼 마스터, 개발팀에 대해서는 확실하게 알아둘 필요가 있겠습니다. 애자일 팀 구성은 고유한 역할들이 부여되어 있는 구성원들로 구성되어 있습니다. 애자일 팀 구성은 기본적으로 프로덕트 오너, 스크럼 마스터 개발 팀으로 구성됩니다.
애자일 팀 프로덕트 오너의 역할
프로덕트 오너(PO)는 사용자와 이해 관계자들을 대표하여 비즈니스 요구 사항과 시스템 제품 개발의 방향성을 제시하는 역할을 맡게 됩니다. 제품은 곧 비즈니스 단위로 구분된 시스템 영역이나 플랫폼을 의미합니다. 프로덕트 오너는 개발 팀과 함께 제품 백로그를 만들고 관리하며 프로젝트 팀이 낭비 없이 최대 가치를 제공할 수 있는 방법을 이해하고 인지할 수 있도록 지원하게 됩니다. 프로젝트 오너(PO)는 지속적인 제품에 대한 피드백을 제공하며 개발되어야 할 기능들에 대한 방향들을 설정하게 됩니다.
프로덕트 오너는 비즈니스 백그라운드를 가지고 있어야 하며 분야 별 전문성을 가지고 있어 이를 제공할 수 있어야 합니다. 프로덕트 오너는 비즈니스에 대한 높은 이해도를 바탕으로 IT 지식까지 포괄할 수 있어야 하는 중요한 역할입니다. 그래서 애자일 프로젝트가 성공하기 위해서는 역량 있는 프로덕트 오너를 영입하는 것이 중요합니다. 프로덕트 오너는 사용자와 이해관계자들을 대표해서 활동하게 됩니다. 그리고 개발자들과 개발팀을 비즈니스 관점에서 이끌면서 IT(Information Technology)에 대한 높은 이해도를 가지고 있어야 합니다. 애자일 팀의 핵심 성공 요인은 강력한 제품 소유권이라는 점도 알아둘 필요가 있겠습니다.
애자일의 개발팀에 대한 역할 이해
개발팀은 교차 기능과 자율구성팀입니다. 자율구성팀은 팀 목표를 달성하기 위해서 구성원들이 직접 리더십을 발휘할 수 있는 팀입니다. 애자일 팀에는 비즈니스 분석, 개발, 테스트 담당자 등 다양한 역할 담당자로 구성됩니다. 팀 안에서는 작업 프로세스, 산정치와 결과를 자체적으로 계획하고 관리합니다. 애자일 팀의 개발팀은 전문성과 다양한 스킬에 대한 광범위한 경험을 보유한 일반 전문가나 T자형 인력으로 구성됩니다.
애자일 프로젝트에서 개발팀은 집중력과 생산성을 고려하여 3명에서 9명 정도 수준의 소규모 인력 구성이 가장 적합합니다. 애자일의 개발팀은 민첩하고 빠르게 움직일 수 있는 소규모 팀이 되어야 합니다. 애자일 개발팀은 동일한 장소에 배치되어야 하고 의사소통이 원활한 근무 환경을 만들어야 합니다. 따라서 애자일 팀을 운영할 때 역학 관계를 개선하고 지식 공유가 가속될 수 있는 환경을 만들어야 합니다. 애자일 개발팀은 모두 전담 팀원들로 팀을 구성하고 멀티 태스킹을 최소화하면서 조직의 사일로를 극복할 수 있도록 해야 합니다.
애자일 팀의 구성 방법 세부 설명
애자일 팀은 다방면의 인재와 전문가들이 혼합된 팀으로 구성하는 것이 좋습니다. 이러한 전문가들은 전문 지식을 제공하고 다방면 인재는 역할 분담의 유연성을 제공합니다. 애자일 팀은 작업을 수행할 수 있는 담당자들을 팀원들이 결정하는 자율 관리 형태로 장려 되어야 합니다. 애자일 팀은 긴밀한 협업을 할 수 있도록 팀원들에게 대인 관계 기술과 감성 지능 기술을 매우 중요하게 다룹니다.
성공적인 애자일 팀의 팀원들은 페어링, 스와밍, 집단 동일 작업 등을 통해 협업 하여 공동 작업을 할 수 있도록 해야 합니다. 페어링은 2명의 팀원이 한 조가 되어 동일한 작업에서 협업 하는 기법입니다. 스와밍은 여러 명의 팀원들이 한 가지 특정 장애를 해결하는데 집중하는 기법입니다. 집단 동일 작업은 여러 팀원들이 특정 작업 항목에 동시에 집중하면서 서로의 기여도를 조율하는 기법입니다. 개발팀은 작업과 문제 해결을 가속화하고 팀 전체 역량이 균등해질 수 있는 효과를 만들어 낼 수 있습니다.
스크럼 마스터의 역할 이해하기
스크럼 마스터는 애자일 프로젝트의 프로젝트 매니저의 역할입니다. 하지만 애자일 프로젝트의 프로젝트 매니저는 일반적인 워터폴 개발 방식의 프로젝트에서의 프로젝트 매니저 역할과는 매우 다릅니다. 애자일 프로젝트에서 프로젝트 매니저인 스크럼 마스터는 팀 관리가 아니라 팀과 경영진을 지원하는 지위와 역할로 전환됩니다. 스크럼 마스터는 애자일 팀을 코칭하고 지원하고 협업을 촉진합니다. 스크럼 프로세스를 유지하는 일을 담당하고 프로젝트 팀이 실무와 규칙을 준수 하는지를 확인합니다. 애자일에 미숙한 팀원이나 이해 관계자들에게 애자일에 대한 교육을 제공합니다. 이는 변화 관리에 해당합니다.
스크럼 마스터는 장애물을 제거해주고 작업 진행을 보증하도록 지원합니다. 스크럼 마스터는 여러 가지 리더십 유형 중 섬김형 리더십 형태의 리더십을 구사합니다. 애자일에서는 팀에게 권한을 위임하고 부여하는 접근 방식으로 운영되기 때문에 스크럼 마스터는 섬김형 리더십을 강조합니다. 섬김형 리더십은 팀 성과를 최대화하기 위해서 팀원들의 니즈와 발전을 이해하고 해결하는데 집중함으로써 팀 서비스를 통해 리딩하는 방식입니다. 섬김형 리더는 팀원들의 참여와 협의를 위해 프로젝트 목표를 정의합니다. 그리고 팀원들이 모두 성공할 수 있는 환경이 조성될 수 있도록 팀을 격려하고 각 팀원들에게 프로젝트 작업 전반에 걸쳐서 기여하도록 요청합니다.
스크럼 마스터와 애자일 프로세스
스크럼 마스터는 완벽한 애자일 프로세스를 계획하지 않고 결과를 얻도록 유도합니다. 스크럼 마스터의 섬김형 리더십은 촉진자로서의 섬김형 리더입니다. 프로젝트 매니저가 섬김형 리더의 역할을 할 때 강조점은 조율 관리에서 협업 촉진으로 역할이 바뀐다는 것입니다. 결과 산출을 위해서 팀의 참여와 이해, 그리고 업무 공유를 독려하게 됩니다. 프로젝트 팀 내부나 프로젝트 팀 간의 협업과 대화를 유도합니다.
예를 들어, 팀 내부나 팀 간의 병목 현상을 드러내고 의견을 나눌 수 있도록 지원하며 팀에서 확인되는 병목 현상을 해결해주는데 집중하게 됩니다. 섬김형 리더십에서는 조직적인 장애물을 제거해주는 것이 중요합니다. 애자일 선언문에서 첫 번째 가치는 프로세스나 도구 보다 개인과의 상호작용을 강조하고 있습니다. 시간이 많이 걸리고 병목의 원인이 되며 팀이나 조직의 민첩성을 저해하는 프로세스에 대해서는 다시 검토하고 간소화할 수 있도록 지원합니다. 만약 프로젝트에 방대한 산출물이 요구될 경우 관련자들과 협력하여 개선해야 하며 적절한 산출물을 만드는 방향으로 검토하고 평가해야 합니다.
애자일을 적용하는 이유와 방법
애자일을 적용하는 이유와 방법은 이해 관계자들에게 교육하고 사업 가치와 편익을 설명하는데 있습니다. 섬김형 리더십은 업무 지원부나 시설팀의 협조를 받아서 애자일 팀의 팀 작업 공간을 확보하는 것이 중요합니다. 또한 스크럼 마스터는 부서의 부서장과 같은 기능 관리자 역할자들의 지원과 협력을 받아 팀원들이 프로젝트 업무에만 집중할 수 있도록 팀원들을 보호하고 지원할 수 있습니다.
스크럼 마스터는 프로덕트 오너와 개발팀이 협업을 통해 유저 스토리를 함께 개발하고 백로그를 작성할 수 있도록 유도합니다. 스크럼 마스터는 프로젝트 팀을 지도하고 멘토링 하며 격려합니다. 프로젝트 팀원들을 교육하고 커리어를 개발하도록 지원하는 것도 하나의 중요한 역할입니다. 프로젝트 팀 안에서 팀의 성공을 축하하고 외부 그룹과의 건설적인 활동을 지원하고 연결합니다. 스크럼 마스터는 정량적인 리스크 분석과 같은 기술적 프로젝트 관리 활동으로 팀을 지원하는 것도 중요합니다.
스크럼 오브 스크럼에 대한 이해
스크럼 오브 스크럼은 메타 스크럼으로 알려져 있습니다. 스크럼 오브 스크럼은 하나의 대규모 스크럼 팀 대신 3명에서 9명의 팀원으로 구성된 2개 이상의 스크럼 팀이 작업을 조율할 때 활용할 수 있는 역할입니다. 각 팀의 대표는 다른 팀 대표와 함께 매일 또는 일주일에 2회에서 3회 회의를 진행합니다. 데일리 스탠드업 미팅과 비슷한 방식으로 완료된 작업, 향후 수행할 작업, 장애와 이슈 등을 논의합니다. 애자일 팀 간 작업을 조율하고 장애를 제거하여 모든 팀의 효율을 최적화 하는 것을 목표로 진행됩니다. 스크럼 오브 스크럼은 더 어려운 역할입니다. 애자일의 경험이 많은 사람이 할 수 있는 역할이기도 합니다.
스크럼 마스터라면 스크럼 오브 스크럼에도 많은 관심을 가져야 할 것입니다. 스크럼 마스터의 단계 보다 더 높은 경지에 있는 역할이기 때문입니다. 스크럼 마스터는 자신의 역할에 대해서 인지하고 팀원들을 지원하면서 애자일 프로젝트가 잘 진행될 수 있도록 나름대로의 적극적인 역할과 활동을 해야 합니다. 스크럼 마스터는 방임하는 역할이 아닙니다. 프로젝트가 잘 진행될 수 있도록 적극적으로 도와주는 역할임을 인지해야 할 것입니다. 스크럼 오브 스크럼도 마찬가지입니다. 스크럼 마스터가 마치 워터폴 프로젝트의 프로젝트 매니저처럼 활동해서도 안됩니다. 그래서 전통적인 워터폴 프로젝트를 하다가 애자일 프로젝트를 경험하는 사람들은 지금까지 경험해보지 못한 새로운 경험을 하게 됩니다.