스크럼 가이드
[코드스테이츠 PMB 9기] 프로덕트 오너, 스크럼 마스터, 스프린트
오늘은 [스크럼 가이드]를 읽고 정리하는 시간을 갖었습니다.
스크럼 가이드는 아래 링크로 이동하시면 다운로드 받으실 수 있습니다.
스크럼 TEAM
스크럼 팀은 적은 인원으로 구성됩니다. 스크럼 마스터 한 명, 프로덕트 오너 한 명 그리고 개발자들로 구성되는 경우가 많습니다. 팀원이 너무 많으면 민첩성이 떨어지고, 효율적으로 소통하기 어렵기 때문입니다. 이러한 이유로 팀이 커질 경우 다수의 스크럼 팀으로 재구성하기도 합니다. 팀 내부에는 상하구조가 없고 한 가지 프로덕트 목표에 동시 집중합니다.
스트럼 팀을 구성하는 전문가 중 프로덕트 오너와 스크럼 마스터를 보면 다음과 같습니다.
• 프로덕트 오너 : 스크럼 팀의 결과물인 프로덕트 가치를 극대화하는 책임을 갖습니다.
수행 방법은 조직, 스크럼, 개인에 따라 다를 수 있지만 프로덕트 백로그 관리하는 것에도 공통적인 책임이 있습니다. 프로덕트 목표 세우고 명쾌하게 소통하는 것이 중요합니다.
• 스크럼 마스터 : 스크럼 확립에 책임이 있는 사람으로서 스크럼 팀과 조직의 구성원이 스크럼을 이해하고 실천할 수 있도록 도와줍니다. 스크럼 마스터는 프로덕트 오너를 도와 프로덕트 백로그 관리 위한 기술 찾을 수 있도록 돕고, 프로덕트 계획 수립과 이해관계자와의 협업을 지원합니다.
스크럼 EVENT
스크럼 과정을 개략적으로 보면 계획을 세우고, 스프린트를 하고, 회고를 하는 순서로 진행됩니다.
① 유저스토리를 우선순위에 따라 백로그에 저장하고, 스프린트 계획을 세우게 됩니다.
② 스프린트는 1, 2 주에서 4주까지 진행되며 칸반보드와 유사한 스크럼 보드에 아까 저장한 백로그를 수행하게 됩니다.
③ 스프린트를 진행하는 동안 데일리 스크럼을 매일 진행하며 팀원들 간 이슈를 공유합니다. 목표 대비 진척을 점검하고, 변경사항이나 앞으로의 업무까지 정보를 공유합니다.
④ 스프린트가 끝나면 결과물인 프로덕트를 점검하는 스프린트 리뷰를 진행합니다. 스프린트 리뷰에는 스크럼 팀 외 주요 이해관계자들이 참여하여 프로덕트를 점검하고 피드백을 공유합니다. ⑤ 마지막으로 스프린트 회고를 통해 스크럼 팀 내부 리뷰를 진행합니다. 이는 프로덕트 중심이 아닌 스프린트를 진행하며 경험했던 내용을 공유하는 자리입니다. 이 회고를 통해 다음 스프린트에 반영해 개선해나가는 거죠.
스크럼 Output
프로덕트 백로그와 스프린트 백로그가 있습니다.
프로덕트 백로그가 프로덕트 향상 목표로 업무를 우선순위에 따라 정렬한 목록이라면, 스프린트 백로그는 스프린트 목표를 달성하기 위해 프로덕트 백로그에서 선택된 할 일 목록입니다. 스프린트는 프로덕트 백로그를 달성하기 위해 설정된 백로그로 구성됩니다.
SPOTIFY에서 일했던 프로덕트 오너가 작성한 글을 요약하고자 합니다
글의 내용은 스포티파이가 잘하고 있다는 것보다 스포티파이의 애자일 시스템에서 발견한 배울 점이 주를 이루고 있습니다. 실제 조직에서 애자일을 실천하는 것은 아는 것과 다르다고 생각하게 되었습니다. 실제 상황에서는 다양한 일들이 일어나기 때문에 애자일하게 일하는 조직도 언제나 문제를 직면하게 되고, 어떻게 해결하여 그 조직만의 특별한 애자일 문화를 만들어 나가는지가 중요한 것 같습니다.
아래는 스포티파이에서 애자일 할 때의 어려움과 경험에 관한 아티클 요약입니다. 인사이트를 가져갈 수 있을 것 같아 번역하여 정리했습니다.
1. 잘못된 문제를 해결한 매트릭스 매니지먼트
한 명의 개발 엔지니어 매니저는 갈등 조장
A product—design—engineering team typically contains more engineers than designers or product managers. Having a single engineering manager for the engineers on the team creates an accountable escalation path for conflict within the team
프로덕트 매니저는 동급의 개발 리드가 있어야해. PM은 우선순위 작업, 개발 리드는 실행
Product managers should have an equivalent peer for engineering. Product managers should be accountable for the prioritization of work. Engineering managers should be accountable for the engineers’ execution, which includes being able to negotiate speed and quality tradeoffs with the product manager
2. 팀 자율성에 집착
자율성 위에 얼라인먼트
Autonomy requires alignment. Company priorities must be defined by leadership. Autonomy does not mean teams get to do whatever they want
크로스 팀 협업 과정•단계 정의 필수
Processes for cross-team collaboration must be defined. Autonomy does not mean leaving teams to self-organize every problem
성공에 대한 정의와 인식이 일치하고 공유되어야 함. 상호 의존적인 크로스 팀에서 우선순위 정할 때 중요
How success is measured must be defined by leadership so people can effectively negotiate cross-team dependency prioritization
자율성은 책임•의무가 중요. 팀은 작업을 완료할 의무가 있다
Autonomy requires accountability. Product management is accountable for value. The team is accountable for delivering ‘done’ increments. Mature teams can justify their independence with their ability to articulate business value, risk, learning, and the next optimal move
3. 협업은 가정된 역량이었다
협업을 위한 애자일 프로세스는 지식과 연습이 필요
Collaboration is a skill that requires knowledge and practice. Managers should not assume people have an existing comprehension of Agile practices
큰 회사 경우, 팀 내 혹은 팀 간 협업을 위한 가이드 플래닝 지원이 필요
When a company becomes big enough, teams will need dedicated support to guide planning within the team and structure collaboration between teams. Program management can be accountable for the planning process. Dedicated program managers enable teams in a manner similar to how dedicated product managers and engineering managers do with their respective competencies
4. 근거없는 믿음은 바꾸기 어렵다
내부 프로세스가 혁신적인 경우는 드물다. 과거에서 혁신의 영역을 발견할 수 있다
Most businesses can only sustain a few areas of innovation. Internal process rarely is a primary area of innovation that differentiates a company in the marketplace. Studying the past allows businesses to pick better areas for innovation
이해를 위해 조율하기. 생산성 높이기 위한 배움이 생소하다면 새로운 기준으로 그 가치를 평가해야해
Optimize for understanding. Every new thing someone must learn in order to be productive in your organization should be evaluated on its value
비즈니스 유닛, 부서, 팀, 매니저들의 조직 구조와 역할, 책임에 대해 커뮤니케이션 해야해
Business units, departments, teams, and managers more effectively communicate organization structure roles and responsibilities than Spotify’s synonyms and are not attached to a way of working that failed their creator
마치며
애자일에 대해 공부하면 할수록 흥미로운 정보를 많이 확인할 수 있었습니다. 향후에는 애자일 실행 케이스에 대해 알아보면 좋을 것 같습니다. 효율적으로 일한다는 게 무엇인지, 작지만 민첩하고 빠른 프로덕트 팀을 리드하기 위해선 어떻게 해야하는지 특히 커뮤니케이션 측면에서 고민해 볼 수 있었습니다.
