넥서스

스크럼은 한 팀을 상정하고 만들어진 틀입니다. 개발자 열 명 안쪽이 한 목록을 보고 한 주기를 돌 때 규칙이 맞물립니다. 그런데 팀이 셋 넷으로 늘면 이상한 일이 벌어집니다. 팀마다 스크럼을 제대로 돌리는데 합쳐 놓으면 아무것도 완성되지 않습니다.

실제로는 이런 장면으로 나타났습니다. 세 팀이 각자 2주 스프린트를 돌고 마지막 날 결과물을 합치려 했는데, 로그인 팀이 바꾼 세션 처리 방식 때문에 결제 팀 화면이 열리지 않았습니다. 보여 줄 자리는 하루 앞인데 고치는 데만 나흘이 걸렸습니다. 세 팀은 셋 다 우리가 맡은 건 끝냈다고 답했습니다.

셋 다 맞는 말이었다는 점이 문제였습니다. 각 팀의 일은 끝났고 합치는 일은 아무의 일도 아니었습니다. 마지막 날에 몰아서 합치니 충돌은 늘 고칠 시간이 없을 때 드러났습니다.

넥서스는 합치는 일에 주인을 붙이고 시점을 앞당기려고 나왔습니다. 스크럼을 만든 쪽이 2015년에 내놓은 확장 규칙이고, 기존 역할과 회의를 그대로 둔 채 팀 사이를 잇는 층만 얹습니다.

팀들을 하나의 제품 백로그에 붙여 두고, 합치는 일을 맡는 사람들을 따로 묶고, 회의마다 팀 대표가 모이는 자리를 한 겹씩 앞에 두는 순서로 돌립니다. 제품 백로그는 앞으로 만들 후보를 우선순위대로 모아 둔 목록이고, 팀마다 자기 목록을 따로 두지 않는 것이 출발점입니다.

1. 넥서스 통합 팀을 만듭니다. 제품 책임자 한 명, 스크럼 마스터 한 명, 각 팀에서 뽑힌 몇 명이 들어갑니다. 지는 책임은 하나입니다. 스프린트가 끝날 때 합쳐진 결과물이 실제로 나오게 하는 것입니다.
2. 스프린트 전에 팀들이 모여 백로그 항목을 훑습니다. 정하는 것은 크기가 아니라 순서와 담당입니다. 결제 화면이 인증 모듈을 필요로 하면 그 사실을 항목 옆에 적고 인증 쪽을 먼저 가져갈 팀을 정합니다.
3. 계획 회의는 두 겹입니다. 팀 대표들이 먼저 이번 주기에 함께 무엇을 낼지 한 문장으로 정하고, 그다음 각 팀이 흩어져 자기 계획을 세웁니다.
4. 매일 팀 대표들이 15분 모입니다. 묻는 것은 진행 상황이 아니라 합친 결과물이 지금 깨져 있는지, 어제 생긴 의존성이 무엇인지입니다. 이 자리가 끝난 뒤 각 팀이 자기 데일리 스크럼을 합니다.
5. 주기 끝의 검토는 팀별로 나누지 않습니다. 각자 발표하는 대신 합쳐진 것 하나를 두고 한 번에 봅니다.
6. 회고도 두 겹입니다. 대표들이 먼저 팀 전체에 걸친 문제를 고르고, 각 팀이 자기 회고에서 다루고, 다시 대표들이 모여 무엇을 고칠지 정합니다.

이 절차는 합치는 일을 마지막 날로 미루지 않으려고 있습니다. 주기 끝에 나와야 하는 것은 팀별 결과물 셋이 아니라 쓸 수 있게 합쳐진 인크리먼트 하나이고, 완료 정의도 팀마다 따로 두지 않고 하나만 둡니다. 로그인 팀은 테스트를 돌리고 결제 팀은 돌리지 않으면 합친 것의 품질은 낮은 쪽을 따라갑니다.

팀이 셋에서 아홉 사이이고 그 팀들이 같은 제품을 만들 때 맞습니다. 뒤쪽 조건이 더 셉니다. 팀마다 다른 제품을 맡으면 합칠 것이 없고, 같은 코드와 배포 단위를 공유할 때 값을 합니다.

전제가 하나 더 있습니다. 각 팀이 이미 스크럼을 굴리고 있어야 합니다. 넥서스가 새로 만드는 것은 통합 팀 하나와 앞에 붙는 회의 몇 개뿐이라, 한 팀 단위가 흔들리면 층을 얹어도 같은 문제가 커진 채로 반복됩니다.

기술 조건도 봅니다. 매일 합쳐 두라는 규칙은 합치는 데 반나절이 걸리는 환경에서 지켜지지 않습니다. 코드를 올리면 자동으로 빌드되고 테스트가 도는 상태가 아니면, 매일 모여도 "아직 못 합쳤습니다" 를 확인하는 자리가 됩니다.

한계도 분명합니다. 아홉 팀을 넘으면 넥서스 여러 개를 다시 묶어야 하는데, 그 규모에서는 대개 SAFe처럼 계획 층까지 규정한 무거운 체계를 함께 검토합니다. 제품 책임자 한 명이 아홉 팀이 쓸 목록 하나를 감당해야 하는 부담도 남습니다. 그가 따라가지 못하면 팀들은 각자 목록을 만들고, 목록이 갈라지는 순간 넥서스는 이름만 남습니다.

"결제랑 알림이 같은 테이블을 건드려요. 넥서스 데일리에서 먼저 얘기하죠."

팀 사이에 걸린 문제라 팀 안에서 못 푸니 대표들이 모이는 자리로 넘기자는 말입니다.

"이번 리뷰는 팀별로 나누지 말고 합친 걸로 한 번만 봅시다."

세 팀이 만든 것이 실제로 붙어 돌아가는지 그 자리에서 확인하겠다는 뜻입니다.

"팀이 셋인데 넥서스까지 필요할까요? 대표 회의만 둬도 될 것 같은데요."

합칠 일이 얼마나 자주 생기는지 보고 더 가벼운 방식으로 시작하자는 제안입니다.

페이지덱은 개발팀이 셋입니다. 문서 편집, 공유와 권한, 결제와 관리자 화면을 각각 맡습니다. 세 팀이 같은 앱을 고치다 보니 한 팀이 바꾼 것이 다른 팀 화면에서 터지는 일이 잦아, 지현이 목록 하나를 관리하고 태오가 통합 팀 대표로 들어가는 방식을 6개월 전에 시작했습니다.

태오는 매일 아침 9시 50분에 다른 두 팀 대표와 15분을 씁니다. 나오는 말은 짧습니다. 어제 올린 것 때문에 빌드가 깨졌다거나, 다음 주에 권한 모델을 바꾸니 붙일 것이 있으면 이번 주에 붙이라는 정도입니다. 이 15분이 없던 시절에는 같은 말이 마지막 날에 나왔습니다.

스크럼을 대체하는 새 프레임워크로 읽는 경우가 많습니다. 이름이 따로 있고 회의 이름도 새로 붙으니 다른 방식처럼 보입니다. 하지만 규정하는 것은 팀 사이를 잇는 층뿐이고, 각 팀 안에서는 원래 하던 스크럼이 그대로 돌아갑니다. 새 방식으로 받아들인 조직은 팀 회의를 없애고 넥서스 회의로 갈아 끼우는데, 그러면 팀 안에서 매일 맞추던 것이 사라지고 대표들만 사정을 압니다.

통합 팀을 전담 조직으로 만드는 것도 흔한 오해입니다. 합치는 일에 주인을 붙이라고 했으니 그 일만 하는 팀을 두는 것이 자연스러워 보입니다. 그런데 이 팀은 대개 각 팀에서 개발하던 사람이 겸합니다. 떼어 내면 합치는 일이 다시 남의 일이 되고, 팀들은 자기 것만 만들어 던집니다. 통합 팀은 마지막 날 남의 코드를 붙이며 야근하는 부서가 되고, 원인을 아는 사람은 그 자리에 없습니다.