스크럼을 오용하는 상황을 짚어보는 글입니다. 아래 대목을 읽다가 번뜩 제가 백로그 관리를 잘못하고 있다는 걸 깨달았어요. (참고로 저희는 스크럼을 하고 있지 않습니다. 형식에 얽매이지 않고 신뢰와

스크럼을 오용하는 상황을 짚어보는 글입니다. 아래 대목을 읽다가 번뜩 제가 백로그 관리를 잘못하고 있다는 걸 깨달았어요. (참고로 저희는 스크럼을 하고 있지 않습니다. 형식에 얽매이지 않고 신뢰와 자율 기반으로 목표를 달성할 수 있는 방법을 찾고 있습니다.) ___ 10년 이상 스크럼을 경험하며 주변에서 스크럼을 사용한다고 주장하는 회사들을 가까이 지켜본 결과 다음과 같은 공통점을 발견했습니다. - 로드맵은 조직이 달성할 목표가 아니라 무엇을 할 것인지 정의하고 있다. - 스크럼 팀은 문제를 해결하는 대신 기능을 제공하는 데 초점을 맞추고 있다. - 제품 관리자는 해결할 가치가 있는 문제를 찾아내는 대신 요구사항 수집에 에너지를 쏟고 있다. ___ 이 내용에서 아래 항목이 유독 눈에 들어왔습니다. > "스크럼 팀은 문제를 해결하는 대신 기능을 제공하는 데 초점을 맞추고 있다." 백로그에 "BFF 서버 개발환경 빌드/배포 파이프라인 구축"이라는 티켓을 넣어두었는데, 티켓에 제목을 이렇게 "해결책"으로 적으면 이걸 보는 동료는 달성해야 할 목표나 문제 보다는 "해결책"에 집중하더라고요. 이런 제목은 해결사의 자율이 들어갈 틈이 별로 없어 보이는 느낌을 줍니다. 그러다보니 플래닝 자리가 내 머릿속에서 다 그려진 해결책을 동료에게 실행해달라고 요청하는 자리가 되어버리곤 했어요. 제 생각을 덜 담을 수록 동료의 생각이 들어올 자리가 커진다는 걸 최근에 깨닫고 있습니다. 그래서 해결책(추가할 기능)이 아닌, 해결해야 할 문제로 제목을 바꿔 적었습니다. "최신의 개발버전을 고객이 언제든 볼 수 있는 환경 만들기"