LeSS

스크럼은 한 팀을 염두에 두고 만든 규칙입니다. 우선순위를 정하는 사람 하나, 만들 것을 모아 둔 목록 하나, 2주짜리 주기 하나가 한 팀에 붙습니다. 제품 하나를 여러 팀이 만들면 이 짝이 통째로 복제되고 답이 여러 개가 됩니다.

페이지덱이 개발 조직을 셋으로 나눈 직후가 그랬습니다. 팀마다 우선순위를 정하는 사람을 두자 목록이 세 개가 됐고, 고객이 가장 자주 불평하던 문서 열기 속도 문제는 어느 목록에서도 위쪽에 없었습니다. 세 목록 모두 자기 기준으로는 옳았는데, 회사 전체에서 무엇이 가장 급한지 답할 자리가 사라진 겁니다.

흔한 해법은 팀 위에 층을 하나 얹는 것이었습니다. 조율 회의를 만들고 그 회의를 맡는 역할을 만들고 거기에 낼 문서를 정합니다. 그러면 팀 안에서 하던 결정이 위로 올라갑니다.

LeSS는 반대쪽을 골랐습니다. 팀 위에 얹을 층을 만들지 않고 한 팀이 쓰던 규칙을 여러 팀이 그대로 나눠 쓰게 합니다. 책임자도 하나, 목록도 하나, 주기도 하나로 두고 늘리는 것은 팀 수뿐입니다. 규정을 더해 규모를 감당하는 대신 구조를 걷어내 감당할 규모를 줄인다는 발상입니다.

팀을 나누기 전에 공유할 것부터 하나로 모으고, 그다음에 회의 순서를 짭니다.

1. 공유 자산을 하나로 둡니다 — 프로덕트 오너는 우선순위를 최종 결정하는 한 사람이고, 제품 백로그는 앞으로 만들 후보를 순서대로 모아 둔 목록입니다. 둘 다 팀 수와 관계없이 하나입니다. 무엇을 끝났다고 부를지 정한 완료 정의와 스프린트 일정도 같아서, 다섯 팀이 같은 날 시작해 같은 날 끝냅니다.
2. 스프린트 플래닝 1부를 다 함께 엽니다. 팀마다 두어 명씩 나와 프로덕트 오너와 함께 목록 위에서부터 어느 팀이 무엇을 가져갈지 정합니다.
3. 플래닝 2부는 팀별로 나눠서 합니다. 가져온 항목을 어떻게 만들지 짜는 자리라 팀 안에서 끝나고, 한 기능에 두 팀이 물리면 한 방에서 같이 짭니다.
4. 주기 중 조율은 회의를 늘리지 않고 사람이 직접 합니다. 같은 부분을 건드리는 팀끼리 상대 팀의 데일리 스크럼에 한 명을 보내 듣고 옵니다. 매일 열리는 15분짜리 자리라 비용이 거의 없습니다.
5. 스프린트 리뷰는 하나로 엽니다. 팀별로 따로 보여 주면 이해관계자가 다섯 번 앉아야 하므로, 한자리에 부스를 나눠 놓고 관심 있는 곳을 돌아보게 합니다.
6. 회고는 두 겹입니다. 팀 회고가 그 팀의 일하는 방식을 보고, 전체 회고가 팀 사이의 문제와 조직 차원의 걸림돌을 봅니다.

새로 만드는 역할은 없습니다. 조율 전담 관리자를 두지 않고 스크럼 마스터 한 명이 세 팀까지 맡습니다. 대신 팀을 나누는 기준은 바꿉니다. 화면 팀과 서버 팀으로 갈라 두면 기능 하나에 세 팀이 물리므로, 한 팀이 화면부터 서버까지 끝내게 묶습니다.

제품 하나를 두 팀에서 여덟 팀까지가 함께 만드는 상황에 맞습니다. 목록 하나로 순서를 매길 만큼 한 제품이어야 해서, 결제 시스템과 사내 도구처럼 고객이 다른 것을 섞으면 기준 자체가 없습니다. 여덟 팀을 넘어가면 요구 영역을 몇 개로 나누고 영역마다 책임자를 두는 큰 판으로 넘어가지만, 그때도 제품 백로그는 하나로 남습니다.

한계는 셋입니다.

1. 책임자 한 사람에게 걸리는 부하가 큽니다. 다섯 팀이 한 목록에서 가져가려면 그 사람이 다섯 팀 분량의 일을 다 이해해야 하고, 이 사람이 밀리면 다섯 팀이 함께 밀립니다.
2. 조직을 다시 묶는 일이 먼저입니다. 부품별로 나뉜 팀을 기능별로 다시 짜고 중간 관리 역할도 바뀌어야 하는데, 조직도를 그대로 두면 이름만 바뀐 채 팀별 목록이 살아남습니다.
3. 규정집이 얇다는 말은 스스로 정할 것이 많다는 뜻입니다. 층마다 회의와 산출물이 이름까지 정해진 SAFe와 달리 빈칸이 많아, 따라갈 지침을 원하는 조직에는 그 빈칸이 부담입니다.

옆의 선택지와 견주면 위치가 분명해집니다. 스크럼 오브 스크럼은 팀 대표가 모이는 회의 하나만 더하고, 넥서스는 여러 팀의 결과물을 합치는 과정에 초점을 둡니다. LeSS는 손대는 범위가 그보다 넓은 대신 더하는 쪽이 아니라 걷어내는 쪽입니다.

"백로그는 하나예요. 팀별로 목록을 따로 만들면 그건 LeSS가 아닙니다."

팀마다 자기 목록을 쌓으면 이 방식의 전제가 무너진다는 지적입니다.

"플래닝 1부에는 팀마다 두 명씩만 들어오세요. 세부는 2부에서 각자 합니다."

전체가 모이는 자리에서는 분배만 하고 설계는 팀으로 돌려보낸다는 뜻입니다.

"그건 회의 만들지 말고 두 팀이 직접 붙어서 푸세요."

조율할 일마다 정기 회의를 만드는 쪽을 막는 말입니다.

페이지덱의 첫 주기가 이렇게 돌았습니다. 규원이 팀별 책임자를 두지 않기로 정하자 지현이 세 목록을 하나로 합쳤고, 플래닝 1부에서 세 팀 대표가 위에서부터 항목을 가져갔습니다. 문서 열기 속도 문제가 맨 위에 있어 두 팀이 함께 붙었고, 세부는 각자 2부에서 짰습니다.

가장 힘들었던 것은 회의가 아니라 목록이었습니다. 지현이 세 팀의 일을 다 알지 못한 채 순서를 매기니 위쪽 항목이 주기 중간에 바뀌었고, 그래서 팀마다 한 명씩 모여 목록을 다듬는 자리를 매주 두었습니다.

팀이 적을 때 쓰는 SAFe의 작은 버전으로 읽는 경우가 많습니다. 확장 체계라는 자리에 나란히 놓이니 규모만 다르다고 보기 쉽습니다. 다른 것은 감당하는 규모가 아니라 방향입니다. SAFe는 층과 주기를 더해 큰 조직을 감당하고, LeSS는 팀 위의 구조를 걷어내 감당할 것 자체를 줄입니다. 작은 버전으로 알고 들여오면 위에서 정리해 줄 층을 기다리게 되는데 그런 자리가 없어서 결정이 멈춘 채 주기만 돌아갑니다.

규칙이 적으니 도입도 쉽겠다고 읽는 것도 흔합니다. 규정집 두께만 보면 그래 보이지만, 그것이 성립하는 이유는 팀을 나누는 방식과 관리 역할을 먼저 바꿔 두기 때문입니다. 그 개편을 건너뛰고 회의 이름만 가져오면 플래닝 1부에 열다섯 명이 앉은 채 결정은 예전처럼 팀 밖에서 나고, 팀별 목록도 그대로 남습니다.