ScalingAgile@LEGO #4 — 빅룸 플래닝3
LEGO DS에서 henrik kniberg와 Eik Thyrsted Brandsgård가 수행했던 빅룸 플래닝 사례를 소개합니다.
빅룸 플래닝이란 다양한 팀이 서로 의존성을 가지고 일할때 큰 방에 모여 함께 계획을 세우고 논의하는 활동입니다.
Scaled Agile Framework의 PI Planning이 본래의 이름입니다. 여기서 Henrik와 Eik는 본래의 방식에 여러부분을 변경해서 적용하고 있습니다.
원문을 총 6편의 글로 분리해서 올립니다. 원문은 아래 경로에서 보실수 있습니다.
리스크 보드
계획이 진행됨에 따라 팀은 “새 라이선스가 제때 제공되지 않을 것”과 같은 잠재적인 문제와 같은 약속을 지킬수 없는 상황을 유발할 수 있는 리스크을 찾아내기 시작합니다. 이들은 방 전체에 흩어져 있는 리스크 게시판, 각 프로젝트 또는 주요 이니셔티브당 게시판에 게시됩니다.
일부 리스크는 적절한 사람들과 이야기함으로써 그 자리에서 해결되는 반면, 다른 리스크는 에스컬레이션되어 첫날의 마지막에 경영진 리뷰를 위해 이사회에 남겨져 있어야 합니다.
과거에는 리스크가 무시되거나 너무 빨리 경영진에 위임되는 경향이 있었습니다(병목 현상으로 전환). 아래에서 위로 전달되는 방식으로 리스크를 시각화함으로써 팀은 스스로 소유권을 갖고 실제로 도움이 필요한 리스크만 에스컬레이션하는데 훨씬 더 능숙해졌습니다.
때로는 리스크를 완화하는 데 드는 비용이 엄청나고 영향에 비례하지 않으므로 리스크를 수용하는 것이 좋습니다. 리스크을 인정하고 수용하면 좌절감이 사라지고 팀이 마음의 평화를 얻을 수 있으므로 걱정하는 대신 딜리버리에 집중할 수 있습니다.
의존성 보드(다른말로 프로그램 보드)
곧 한쪽 벽에 걸려 있는 정말 거대한 보드를 발견합니다. 그 보드 앞에는 항상 윙윙 거리고 사람들이 있기 때문에 일종의 무게 중심처럼 보입니다. 첫날에 빈상태로 시작하지만 첫날이 끝날 즈음에는 서로 연결된 스티커 메모가 엉켜서… 어… 빨간 실?! 스티커, 가위, 실, 무슨 일일까요?
우리는 그것을 “의존성 보드”(때로는 “프로그램 보드”)라고 부릅니다. 누가 언제 누구로부터 무엇을 필요로 하는지 보여줍니다. 자세히 보세요….
각 열은 팀이고 각 행은 스프린트(2주)입니다. 메모는 파란색에서 분홍색까지 종속성을 나타냅니다. “THIS(파란색 스티커)를 전달하려면 THAT(핑크색 스티커)가 필요합니다.” 어떤 스프린트가 누구에게 전달될 것인지에 대해 많은 토론과 협상이 있음을 알 수 있습니다.
아무도 의존성 보드를 소유하지 않는 것 같습니다. 퍼실리테이터는 처음에 그것을 벽에 걸어두지만, 그 다음에는 팀이 완전히 스스로 조직화하여 서로에 대한 종속성을 시각화하고 보드를 상호 소통하는 프로토콜의 한 형태로 사용하여 누가 누구와 이야기해야 하는지 파악합니다. 보드는 분산된 협업을 가능하게 하는 중앙 집중식 도구입니다.
- “그래서 팀은 제공할 계획인 모든 기능을 보드에 게시합니까?”
- “아니요, 종속성이 있는 기능만 게시합니다. 우리는 모든 것을 게시판에 넣어 봤지만 너무 어수선해져서 누구도 그것을 이해할 수 없었습니다. 우리는 정말로 중요한 것이 의존성이라는 결론을 내렸고, 그래서 우리는 그것에 초점을 맞췄습니다. 독립적인 기능은 각 팀 보드에서 볼 수 있지만 여기에서는 볼 수 없습니다.”
명백한 병목 현상(CIT 컬럼, Corporate IT)을 발견하고 병목 현상을 가장 효과적으로 활용하는 방법에 대한 활발한 토론과 장기적으로 병목 현상 요인을 줄이는 방법에 대한 몇 가지 대화를 볼 수 있습니다.
- “그게 다 뭐야?” 진행자에게 묻는다.
- “글쎄요, CIT는 실제로 DS와 별개의 조직이기 때문에 처음에는 플래닝 프로세스의 참석하지 않았습니다. 그러나 처음 몇 번의 PI 플래닝 이벤트 후에 CIT가 우리의 가장 중요한 종속 항목이라는 것이 분명해졌습니다. 사람들은 그것에 대해 많이 많이 이야기하기 시작했습니다. 그래서 우리는 의존성 게시판에 CIT를 위한 칼럼을 추가하고 해당 조직의 대표를 PI 계획 이벤트에 초대하기 시작했습니다.”
- “도움이 되었나요?”
- “그래, 엄청난 변화를 가져왔어요! 덜 비난하는 게임이 되었고 더 많은 협력이 이루어졌습니다. ‘우리와 그들’이 아니라 더 많은 ‘우리와 우리’가 되었습니다.”
CIT와 DS 직원은 이사회 앞에서 서로 얼굴을 맞대고 이야기하며 귀중한 병목 현상을 최대한 활용하는 방법(물론 시간이 지남에 따라 병목 요소를 줄이는 방법)에 대해 논의합니다. 그다지 좋아 보이지 않았지만 게시판의 사람들은 “예전에는 훨씬 더 나빴습니다! 당신은 우리가 만든 모든 개선 사항을 볼 수 있습니다! 종속성을 줄이기 위해 사물을 클라우드로 옮기는 것과 같습니다. 시간이 걸리긴 하지만.”
종속성 보드의 맨 아래 행은 눈에 띄게 비어 있습니다. 이를 IP(“혁신 및 계획”)라고 합니다. 그 스프린트는 계획되지 않은 혁신, 처음 세 스프린트의 오버플로 및 다음 PI 계획 회의, 교육 및 기타 발생할 수 있는 모든 것과 같은 기타 “작업”을 위한 공간을 남겨두기 위해 예비로 유지됩니다.
엔지니어는 “이제 약속을 훨씬 더 잘 이행할 수 있게 되었습니다. 용량 데이터(스토리 포인트 등)가 있으므로 과도하게 커밋할 가능성이 적습니다. 그러나 또한 IP 스프린트는 일종의 버퍼 역할을 하므로 무언가가 폭발하게되면 복구할 공간이 있습니다. 그러나 가장 중요한 것은 약속을 머리에 두지 않고 논의하고 협상하는 것입니다.”
- “그렇다면 혁신은 어떻습니까? IP 스프린트의 I가 혁신이 맞죠?”
그가 웃는다.
- “그 부분은 보통 실제로 동작하지 않을때가 많습니다. 하지만 초창기보다는 지금이 나은 상황입니다. 지난 PI에 우리는 IP 스프린트 동안 해커톤을 했고, 그 중 멋지고 유용한 것들이 많이 나왔습니다!
어떤 팀은 항상 IP 기간 동안 혁신을 위한 시간을 내었고 이번에는 성공하지 못한 팀이 부러워할 것입니다.”
또 다른 점은 당신의 호기심을 자극합니다.
- “회의 후 의존성 보드는 어떻게 되나요?”
- “우리는 그것을 말아서 사무실로 가지고 가서 거기 벽에 테이프로 붙입니다.”
- “그 다음엔?”
- “일주일에 한두 번 Scrum of Scrum을 합니다. 각 팀의 스크럼 마스터가 이사회에 모여 리스크와 종속성을 논의하고 해결되는 대로 표시합니다.”
그는 당신에게 사진을 보여줍니다 :
- “인도의 팀은 어떻습니까? Billund의 벽에만 있는 보드에 어떻게 접근합니까?”
- “아직 고민하고 있는 상태에요…”
- “차기 PI 플래닝을 하게 되면? 이 게시판은 어떻게 되나요?”
- “버려집니다.. 각 PI 계획에서 새로운 종속성 보드를 만듭니다. 우리에게 신선한 관점을 제공하고 역사에 얽매이지 않고 보드의 형식과 구조를 실험할 수 있습니다.”
플랜 초안 박람회
혼란스러워 보이는 세부 계획을 몇 시간 동안 진행한 후 진행자는 무대에 올라 플랜 초안 박람회 시간이 되었음을 알립니다. 진행자가 긴 회의를 회의 형식을 다시한번(지금쯤이면 대부분의 사람들에게 친숙함)을 요약하면 혼란스러움이 가라앉습니다.
- “서로 7.5분씩 4회 진행합니다. 세션마다 팀원 한 명이 팀 보드에 남아 다른 사람들에게 계획을 발표하고 나머지는 다른 팀의 프레젠테이션을 볼 수 있습니다.”
그는 큰 7.5분 타이머를 시작하고 프레젠테이션이 시작됩니다. 각 플래닝 보드 주위에 소그룹이 형성되어 해당 팀을 위한 계획(그들이 제공하려는 내용과 그 이유)을 듣고 토론합니다.
종속성과 위험이 논의되고 경우에 따라 새로운 문제가 발견됩니다. 당황하지 마세요. 내일 문제를 해결할 시간이 있습니다.
- “왜 7.5분인가요? 왜 4회 세션인가요?”
- “우리는 다양한 타이밍으로 많은 실험을 했고 이것이 지금까지 가장 잘 작동합니다. 지루하거나 세부적으로 어려움에 빠지지 않고 무언가를 배울 수 있는 충분한 시간입니다.”
7.5분 후 벨이 울리고 두 번째 세션이 시작됩니다. 사람들은 그들의 계획을 듣기 위해 다른 팀으로 이동합니다. 등등 총 4개의 세션, 즉 30분입니다.
“좋아요, 그럼 각자 4개의 팀을 선택하여 방문하여 계획에 대해 알아볼 수 있습니까?”
- “정확히.”
- “하지만 큰 그림은 어떻습니까? 모든 팀의 계획을 듣는 것이 좋지 않겠습니까?”
- “몇몇 사람들에게는 그렇습니다. 하지만 대다수는 그렇지 않습니다. 따라서 가장 관심 있는 4가지를 선택하게 합니다. 더 알고 싶다면 내일 브레이크아웃 동안 더 많은 팀을 방문할 수 있습니다.”
- “이것이 당신이 항상 해오던 방식입니까?”
- “아니. 과거에는 라운드 로빈 방식으로 계획 초안 공유를 수행했습니다. 모두가 앉고 한 번에 한 팀이 일어나서 전체 회의실에 계획을 발표하는 동안 진행자는 카메라를 보드에 대고 큰 화면으로 스트리밍했습니다. 우리가 올바른 도구를 찾으면 꽤 매끄럽습니다. 하지만 엄격한 타임박스에도 불구하고 20개 정도의 팀을 모두 둘러보는 데 최소 1시간이 걸렸습니다.”
- “으악”
- “맞아요. 그 부분을 흥미롭게 만들기 위한 우리의 최선의 노력에도 불구하고, 그것은 완전히 지루했습니다! 몇몇 사람들은 주의 깊게 듣고 있었지만 대부분의 사람들은 전화기를 멍하니 쳐다보거나 테이블에 머리를 대고 누워서 제발 종료를 기다리고 있었습니다! 사람들은 다른 팀, 특히 그들이 의존하는 팀이 하는 일에 관심을 갖습니다. 하지만 그것은 3~4개의 다른 팀과 마찬가지로 모든 팀이 무엇을 하는지 알 필요가 없습니다. 그래서 우리는 계획을 모든 사람에게 강요하는 것을 중단하고 대신 끌어오기 기반 시스템을 수행하기로 결정했습니다. 공정한 모델이 훨씬 더 잘 작동했습니다! “
당신은 이리저리 방황하며 프레젠테이션을 듣습니다. 사람들은 자신의 계획, 종속성, 기술, 위험 등에 대해 논의합니다.
진행자는 다시 지나가며 다음을 지적합니다.
- “방 안의 높은 에너지 레벨이 보이시나요? 이것이 우리의 주요 피드백 루프이며, 우리가 옳았다는 것을 알려줍니다. 에너지 수준이 낮고 사람들이 힘들어 하기 시작하면 우리가 무엇을 하든 잘못된 것이며 형식을 조정해야 합니다. 그래서 에너지를 발생시키는 부분은 그대로 두고 지루한 부분은 버립니다. “
실제로 2명의 진행자가 한 쌍으로 작업하고 무대에서 교대로 작동한다는 것을 알 수 있습니다. 그는 다음과 같이 설명합니다.
- “우리는 항상 이 이벤트를 짝을 이루어 진행합니다. 그렇게 하면 한 사람은 한 걸음 물러나서 에너지 수준을 관찰하고 개선에 대해 생각하면서 촉진할 수 있습니다. 짝으로 활동하는 것은 또한 우리 중 한 명이 아플 경우에 대비하여 약간의 중복성을 제공하고 더 쉽게 새로운 조력자를 수용할 수 있습니다.”
매니지먼트 검토 및 리스크 해결
첫날이 끝나면 대부분의 사람들은 떠나고 관리자는 뒤에 남습니다. 관라자들의 검토의 시간!
리스크 보드는 큰 의존 보드 근처에 일렬로 모여 있고 관리자는 반원으로 모여 있습니다.
모든 사람은 플랫폼에서 일어나는 일의 영향을 받으므로 거기서 플랫폼부터 시작합니다. 플랫폼 제품 소유자는 계획을 요약하고 어려운 절충안 결정을 내립니다.
- “나쁜 소식이네요. 이 PI 동안 A와 B를 모두 제공할 수 있는 능력이 없습니다.”
두 가지 이니셔티브 모두 정말 중요하며 둘 중 하나를 수행하지 않으면 더 큰 영향을 미치므로 논쟁이 매우 뜨겁습니다. 진행자는 상황을 예의바르고 집중할 수 있도록 도와줍니다. 관리자들은 어떤 옵션이 있는지, 각각의 장단점에 대해 논의하고 마침내 A의 우선 순위를 결정하고 B를 연기하기로 결정합니다. 여러 팀은 이를 기반으로 내일 계획을 조정하고 재정렬해야 합니다.
다음으로, 그들은 각 리스트 보드를 처리해갑니다. 여전히 보드에 남아 있는 리스크는 조직의 다른 부분과 관련이 있거나 팀의 통제 범위 밖에 있기 때문에 팀이 스스로 해결할 수 없는 리스크들입니다. 이 관리자 그룹은 이제 오너쉽을 가져와서 무엇을 할지 결정합니다. 그게 그들이 집에 가지않고 인센티브를 받는 이유입니다.
리스크 게시판에 열이 있습니다. 한 관리자는 다음과 같이 설명합니다.
- “ROAM 프레임워크는 이 대화에 매우 유용합니다. 우리는 한 번에 하나의 위험을 검토하고, 이에 대해 논의하고, 결정을 내리고, 해결됨, 소유됨, 수락됨 또는 완화됨(‘ROAM 보드’)의 4개 열 중 하나로 이동합니다. 따라서 집에 갈수 있는 종료 기준은 매우 명확합니다. 보드의 모든 리스크를 논의하고 로밍(ROAMed)해야 합니다!”
각 리스크를 처리한 후, 그들은 내일 아침 모든 사람을 위해 요약할 사람에 결정합니다.
당신은 서번트 리더십에 관해 읽었던 책을 기억하고 이 모든 설정이 관리자를 서번트 리더십 패턴으로 밀어넣는다는 것을 깨닫고 있을 겁니다. 팀은 관리자가 책임을 지고 문제를 해결하는 데 도움을 주어 신뢰를 구축하는 것을 봅니다.
그리고 진행자는 이를 확인합니다.
- “매니지먼트 리뷰는 꽤 혼란스럽고 에너지 소모가 많았습니다. 처음에는 리스크 게시판이 전혀 없었기 때문에 대화가 구조화되지 않고 시간이 오래 걸리고 결정을 놓치거나 잊어버리는 경우가 있었습니다. 나중에 위험 게시판을 도입했을 때 너무 많은 위험이 에스컬레이션되었습니다. 점차적으로 팀은 소유권을 더 잘 갖게 되었고(물론 관리자가 권장), 더 적은 위험이 에스컬레이션되었기 때문에 관리자는 더 많은 권한을 갖고 오너쉽을 가질 마음이 생겼습니다.
