우리 팀에 맞는 딜리버리 방법론 설계하기(Design a fit-for-purpose delivery methodology for your team)
팀이 경직된 Scrum이나 Waterfall을 넘어, 자신들의 프로젝트 맥락에 맞는 맞춤형 딜리버리(delivery) 접근 방식을 설계해야 할 때 이 프롬프트를 사용하세요.
방법론을 수입하지 말고, 설계하라
Scrum. SAFe. Shape Up. Kanban. 제품 업계에는 각자 인증 프로그램, 컨설턴트, 열렬한 지지자를 가진 딜리버리 방법론이 넘쳐납니다. 문제는 이 프레임워크들이 나쁘다는 것이 아닙니다. 문제는 팀이 그것들을 통째로 가져다 쓰고, 왜 자기들 상황에 맞지 않는지 의아해한다는 점입니다.
문제
모든 딜리버리 방법론은 특정한 맥락을 위해 만들어졌습니다. Scrum은 2주 단위로 소프트웨어를 만드는 소규모 동거 팀을 전제로 나왔습니다. SAFe는 여러 팀을 조정해야 하는 대기업을 위해 설계됐습니다. Shape Up은 6주 사이클, 소규모 팀, 높은 자율성을 가진 Basecamp의 특정 문화에서 탄생했습니다.
누군가의 맥락을 위해 설계된 방법론을 그대로 가져오면, 그들이 전제한 팀 규모, 커뮤니케이션 패턴, 의사결정 권한, 리스크 허용도를 함께 물려받게 됩니다. 그런데 그 가정은 당신의 현실과 맞지 않을 수 있습니다.
2023 State of Agile 보고서에 따르면 Scrum을 사용하는 팀의 65%가 이를 상당히 수정해서 쓰고 있으며, 가장 흔한 수정은 ceremony를 없애거나 줄이는 것입니다. 팀은 직관적으로 mismatch를 감지하지만, 자신들 상황에 맞는 방법론을 의도적으로 설계할 프레임워크는 없는 경우가 많습니다.
McKinsey의 2022 organizational agility 연구에 따르면 맞춤형 delivery process를 설계한 기업은 기존 방법론을 그대로 채택한 기업보다 delivery speed에서 35%, 팀 만족도에서 28% 더 높은 성과를 냈습니다. 자기 방법론을 직접 설계하는 행위 자체가, 팀이 자신의 제약과 가치를 더 깊이 이해하게 만들기 때문입니다.
이 프롬프트의 작동 방식
이 프롬프트는 책에서 하나를 골라 채택하는 대신, 첫 principles에서 출발해 딜리버리 방법론을 설계하도록 돕습니다. 먼저 팀의 실제 맥락을 맵핑합니다.
- 팀 토폴로지(Team topology): 규모, 분산 여부, 스킬 구성, 의사결정 권한
- 업무 특성(Work characteristics): 예측 가능성, batch size, dependency 패턴, risk profile
- 조직 제약(Organizational constraints): 보고 cadence, 컴플라이언스 요구사항, 이해관계자 기대치
- 문화적 가치(Cultural values): 팀이 속도, 품질, 예측 가능성, 혁신 중 무엇을 최적화하는지
이 맥락을 바탕으로, 프롬프트는 확립된 프레임워크 전반에서 현재 상황에 맞는 practices만 골라 방법론을 조립합니다. 결과물은 "Scrum을 써라"나 "Shape Up을 써라"가 아닙니다. 각 practice를 왜 포함하는지 rationale이 붙은 맞춤형 프로세스입니다.
언제 사용할까
- 새 팀을 만들 때 실제 팀 맥락에 맞는 working agreement를 세우고 싶을 때
- 기존 방법론이 망가진 것처럼 느껴질 때 무엇이 왜 안 맞는지 진단하고 싶을 때
- 팀 retrospective 이후 현재 프로세스에 대한 불만이 수면 위로 올라왔을 때
- 스케일링 시점에 한 팀용 프로세스가 여러 팀에는 더 이상 맞지 않을 때
흔한 함정
- 위원회식 설계(Designing by committee). 너무 많은 목소리가 들어오면 방법론은 Frankenstein 프로세스가 됩니다. 설계 팀은 작게 유지하고, 넓은 팀에는 테스트하세요.
- 프로세스를 과도하게 복잡하게 만들기. 최고의 방법론은 단순합니다. 설명하려면 flowchart가 필요한 프로세스는 이미 너무 복잡합니다. 2023 Atlassian Team Health 설문에 따르면 sprint당 반복 ceremony가 5개 미만인 팀은 8개를 넘는 팀보다 만족도가 42% 높았습니다.
- 설계를 다시 보지 않기. 맥락은 변합니다. 새 팀원, 새 제품 단계, 새 조직 구조가 생깁니다. 방법론은 분기마다 리뷰하세요.
- 프로세스와 문화를 혼동하기. 서로 신뢰하지 않는 팀은 stand-up meeting을 아무리 늘려도 해결되지 않습니다. 문화 문제는 프로세스로 덮지 말고 직접 다루세요.
참고 자료
- Basecamp. (2022). *Shape Up: Stop Running in Circles and Ship Work that Matters*. https://basecamp.com/shapeup
- McKinsey & Company. (2022). Organizational Agility Report. https://www.mckinsey.com/capabilities/people-and-organizational-performance/our-insights/
- Digital.ai. (2023). 17th Annual State of Agile Report. https://digital.ai/resource-center/analyst-reports/state-of-agile-report/
Sources
Prompt details
Ready to try the prompt?
Open the live prompt detail page for the full workflow.