스크럼 그대로 따라하면 망하는 이유
애자일을 우리팀에 맞게 재구성하는 테일러링 기법
모든 프로젝트는 다르다
우리가 스타트업에 새로 합류한 프로덕트 매니저(PM)라고 상상해 봅시다. 에너지 넘치지만 몇명 없는 팀원들과 함께 새로운 모바일 앱을 두 달 안에 출시해야 하는 상황입니다. 팀원들은 애자일(Agile)이라는 말을 들어본 적이 있지만 매일 스탠드업 미팅이나 스프린트를 해본 적은 없습니다. 이 상황에서 개발팀이 애자일의 스크럼 방식을 100% 그대로 따라 하면 어떻게 될까요?
첫 주가 지나고 나면 이런 말들이 쏟아집니다.
"매일 미팅만 하다 하루가 끝나요. 개발은 언제 하죠?"
"우리 프로젝트에서 굳이 리뷰랑 회고가 필요한가요? 전 시간이 아까운데요."
모든 팀과 프로젝트는 각기 다른 배경과 특징이 있기 때문에 어떤 개발 방법론이 좋다고 해서 그대로 적용하는 건 비효율적입니다. 이때 필요한 것이 바로 '테일러링'입니다. 테일러링은 개발 방법론을 각 프로젝트와 팀에 맞게 조정하는 과정을 말합니다.
스크럼을 그대로 따랐다가 망한 사례
대형 이커머스 회사의 사례를 들어보겠습니다.
지은(가명)씨의 팀은 대규모 리디자인 프로젝트를 맡게 되었고, 애자일 스크럼 방식을 처음 도입하기로 했습니다. 이 프로젝트는 여러 부서가 함께 협업해야 하고 개발자, 디자이너, 마케터가 모두 같은 타임라인을 준수해야 했습니다.
이런 상황에서 지은씨의 팀은 스크럼을 그대로 따라 하면서 아래와 같은 문제에 봉착합니다.
매일 스탠드업 미팅, 스프린트 계획, 리뷰, 회고 등으로 팀원들이 정작 작업할 시간이 부족해집니다.
디자이너와 마케터가 빠르게 돌아가는 스프린트 주기에 적응하지 못해서 작업이 계속 늦어졌습니다.
빠른 반복 주기를 돌리다 보니 고객 피드백을 충분히 반영하지 못한 기능들이 급히 출시되었습니다.
테일러링으로 프로젝트를 되살린 사례
같은 상황에서 테일러링을 적용해 성공한 사례도 있습니다.
스타트업의 PM인 민규(가명)씨는 지은씨와 유사한 상황에서 앱 개발 프로젝트를 맡았습니다. 민규씨는 스크럼 방식을 그대로 따르기보다 팀의 상황에 맞게 조정했습니다.
매일 하던 스탠드업 미팅을 주 2회로 줄이고 중요한 진행 상황만 공유하는 간단한 회의로 변경합니다.
스프린트 주기를 3주로 늘려 팀원들이 작업에 집중할 수 있는 시간을 확보합니다.
디자이너와 마케터는 스프린트 리뷰와 회고에 참석하지 않아도 되고, 대신 디자인과 마케팅을 위한 피드백 세션은 따로 마련합니다.
이렇게 팀의 상황에 맞게 테일러링한 결과로 프로젝트는 예정했던 타임라인에 맞춰 무사히 마무리되고 팀원들의 스트레스도 훨씬 줄어들었습니다. 고객 피드백을 충분히 반영한 기능들이 문제 없이 출시되면서 고객으로부터 긍정적인 반응도 얻습니다.
프로덕트 매니저가 알아야 할 테일러링의 방법
테일러링은 프로젝트가 성공하기 위해 불필요한 절차는 과감히 빼고 꼭 필요한 부분만 강조하는 과정입니다. 테일러링을 제대로 하고 싶다면 이렇게 진행해 보세요.
1. 프로젝트의 특징 파악하기
맡은 프로젝트의 특성과 요구사항을 파악하는 단계입니다. 우리는 이 단계에서 이런 질문을 할 수 있습니다.
어떤 제품을 개발하는가?
고객의 요구사항은 무엇인가?
팀의 규모는 얼마나 되는가?
만약 새로운 모바일 앱을 개발한다고 가정해 볼게요. 이 앱에서 사용자는 건강 데이터를 기록하고 분석할 수 있습니다. 이때 프로젝트 특징은 이렇게 정리할 수 있습니다.
- 사용자: 20~40대 직장인
- 주요 기능: 데이터 입력, 그래프 시각화, 알림 기능
- 프로젝트 제약: 6개월 내 출시해야 함, 5명으로 구성된 소규모 개발팀
2. 표준이 될 프로세스를 고르고 적절한지 확인하기
회사나 팀에서 사용하고 있거나 혹은 알고 있는 표준적인 개발 프로세스(워터폴, 애자일, 스크럼 등) 중 우리 프로젝트에 맞는 것을 선택하고 그 프로세스가 적절한지 확인합니다.
만약 앱 출시 기한이 3개월 정도로 짧다면 유연한 방법론인 애자일 방법론을 고릅니다. 단, 팀원들이 애자일 방법론으로 일해본 적이 있는지 확인하고, 만약 없거나 아직 잘 모른다면 애자일 관련 워크숍을 진행해서 모두가 이해할 수 있도록 합니다.
3. 프로세스를 큰 틀에서 수정하기 (상위 수준 커스터마이징)
선택한 프로세스를 프로젝트 특성에 맞게 큰 틀에서 수정합니다. 예를 들어 단계의 순서를 바꾸거나, 없애거나, 추가할 수 있습니다.
앞에서 이어지는 모바일 앱 예시에서는 애자일 방법론을 기본으로 하되 아래와 같이 상위 수준에서 바꿀 수 있습니다.
- 스프린트 주기: 2주 → 1주 (짧은 출시 일정에 맞춤)
- 스프린트 플래닝 미팅 시간: 4시간 → 2시간 (업무 시간 절약)
4. 프로세스를 세부적으로 수정하기 (세부 커스터마이징)
앞서 상위 수준에서 설정한 틀을 기반으로 이제 세부적인 활동들과 사용할 도구를 맞춥니다. 예를 들어 회의는 얼마나 자주 할지, 문서화는 얼마나 구체적으로 할지, 도구는 무엇을 사용할지 등을 생각할 수 있습니다.
- 회의: 매일 스탠드업 미팅 진행, 단 10분으로 제한
- 도구: Jira를 사용해 태스크 관리, Notion을 사용해 문서화
- QA 프로세스: 테스트 자동화 도구를 사용해 QA 효율화
5. 테일러링 결과를 문서화하기
위에서 조정한 프로세스를 문서화하여 팀원 전체가 참고할 수 있도록 합니다. 문서화를 통해 소통을 명확하게 하고 일관적으로 소통할 수 있습니다.
"우리 프로젝트는 스프린트를 1주 주기로 반복합니다."
"Jira에서 태스크를 관리하고, QA는 매 스프린트 마지막 날에 진행합니다."
(이 문서는 Google Docs 또는 Notion 등에 저장해 팀원들과 공유됨)
방법론은 문제를 해결하기 위한 도구이지 그 자체가 목적이 아닙니다. 목표는 프로젝트를 성공시키는 것이지 '스크럼을 완벽하게 따랐다'가 아닙니다. 여러분이 PM이라면 다음 프로젝트에서는 테일러링을 적극적으로 팀에 적용해 보세요. 팀원들의 피드백에 귀 기울이고 프로젝트가 매끄럽게 진행되는 모습을 보며 PM으로서 한층 더 성장할 수 있을 겁니다. 이번 아티클도 여러분의 업무에 유용했길 바랍니다. 2025년 첫 아티클입니다. 새해 복 많이 받으세요! :)
IT PM/PO/서비스 기획자를 위한
파이온티어 단톡방 바로가기
